comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: Need help with Wavelet Workbench
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Need help with Wavelet Workbench [message #14830] Wed, 07 April 1999 00:00
jab7981 is currently offline  jab7981
Messages: 1
Registered: April 1999
Junior Member
On 7 Apr 1999 14:11:34 GMT, steinhh@ulrik.uio.no (Stein Vidar Hagfors
Haugan) wrote:

>
> In article <370b52f7.335334@news.frontiernet.net>
> jkbishop@frontiernet.net (Jonathan Bishop) writes:
>

>> When I put the 32768 point set in,
>> the data set gets truncated to 16384 points because
>> fix(alog(n_elements(x_work))/alog(2))) evaluates to 14 instead of
>> 15. alog(n_elements(x_work))/alog(2)) is given as 15.0000. Can
>> someone explain this so even a mechanical engineer can
>> understand?
>
> IDL> print,alog(32768)/alog(2),form='(g15.10)'
> 14.99999905
>
> It would be wiser in this case to use round() instead of
> fix() -- or use the logb() function I posted recently!

I thought of that, but naive use of round will make it think a dataset

of 32767 points is 2^15 points, then an array subscript will be out of
range. A kludge like round(100.*alog(...)/alog(2))/100 would at
least work here. I'll pass on using logb, though
something along those lines might be needed if WWB is overhauled
to use long data sets; I'll just comment out the check and be
careful, now that I know the cause.

The result is that WWB only works for datasets < 32768 in length
rather than <= 32768 in its original form.

>
> Regards,
>
> Stein Vidar

--
Jonathan Bishop
Re: Need help with Wavelet Workbench [message #14835 is a reply to message #14830] Wed, 07 April 1999 00:00 Go to previous message
steinhh is currently offline  steinhh
Messages: 260
Registered: June 1994
Senior Member
In article <370b52f7.335334@news.frontiernet.net>
jkbishop@frontiernet.net (Jonathan Bishop) writes:

> I'm trying to use Wavelet Workbench on a long (48000 pt) signal. I
> think that two separate problems are occuring.
>
> I upsampled the data set to 65536 points (by zero padding in frequency
> space). I hacked wreaddat, wdyadlng, wdyad, and wfwtpo to use long
> integers in some places. The result is that I can now plot the
> scalogram for my data set (wreaddat, wintwave, wdoscog are the
> programs I'm calling). However, the plot of the scalogram looks like
> only the first half of the data set is being used. The coarser scales
> have some variation just beyond the half-way point (bleed-over from
> the convolution process?), but the more detailed scales show a solid
> color in the upper half of the time axis. Anyone have any ideas what
> is going on?

My initial guess would be that there's still some problem
with the use of integer vs long... Other than that, I
haven't a clue.

(I should mention that I've no insight into the programs
that are discussed here, I'm only guessing)

> So far, I have tried upsampling again to 2*65536 points (whatever
> that is). The result is that the convolution-by-FFT process in
> wmfilt takes forever (I didn't wait for it to finish; it was taking at
> least 10 times as long as the 65536 point set, as verified by
> printed status statements). I don't understand why, but would
> the FFT process be the problem with the 65536 data set?

What's the algorithmic complexity of a full wavelet
decomposition? I'm sure it's not simply log2(n)... An
individual FFT is of order log2(n), however, but doesn't
the wmfilt procedure do a lot (order n at least?) of them?
Since it's printing out it's status as it churns away, I
assume it's not just one gargantuan fft operation that's
taking so long...

Other than that, execution time may not be as expected
when a problem grows, owing to a problem that's larger
than the processor cache size, or due to swapping.

> When I put the 32768 point set in,
> the data set gets truncated to 16384 points because
> fix(alog(n_elements(x_work))/alog(2))) evaluates to 14 instead of
> 15. alog(n_elements(x_work))/alog(2)) is given as 15.0000. Can
> someone explain this so even a mechanical engineer can
> understand?

IDL> print,alog(32768)/alog(2),form='(g15.10)'
14.99999905

It would be wiser in this case to use round() instead of
fix() -- or use the logb() function I posted recently!

Regards,

Stein Vidar
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Re: Problems with JULDAY and CALDAT
Next Topic: Re: how to use the map_set in this situation ???

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 19:51:57 PDT 2025

Total time taken to generate the page: 0.00682 seconds