help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OctDev] [PKG] lssa


From: JuanPi
Subject: Re: [OctDev] [PKG] lssa
Date: Wed, 3 Oct 2012 15:39:58 +0200

On Wed, Oct 3, 2012 at 3:14 PM, Benjamin Lewis <address@hidden> wrote:
> Le 2012-10-03 à 05:41, JuanPi <address@hidden> a écrit :
>
>> Hi there,
>>
>> I am exploring the lssa package, looks really handy. however I am
>> finding difficult to understand the use.
>>
>> I started testing lsreal and the last three input arguments are a
>> little puzzling ( MAXFREQ, NUMCOEFF, NUMOCTAVES).
>> Questions:
>>
>> - Can't this arguments be estimated form the data by default and given
>> as optional in case the user wants some specifics?
>> - Is there an example of use of the function? A demo would be very very 
>> handy.
>> - The doc string should contain a minimum explanation of what is
>> maxfreq (at least in what units should be given (rad/s? Hz? normalized
>> as in butter?), numcoef (i expected the result to be this length, but
>> octave I was wrong), numoctaves.
>>
>> If I get the grip of these functions I can help writing demos.
>>
>> Thank you very much for your support.
>>
>
> Hey;
>
> Thank you for trying out lssa. Some background on the functions is in order 
> to explain the arguments you're wondering about, I think:
>
> The ls* functions in the lssa package implement the Lomb-Scargle transform, 
> which is a non-invertible transform which tests independent frequencies 
> against the provided data set; its operations expect radian input, but beyond 
> that, the MAXFREQ term is essentially rad/(pick the unit that matches from 
> your data). The transform (in the case of lsreal and lscomplex) operates over 
> NUMOCTAVES octaves, testing NUMCOEFFS evenly-spaced frequencies per octave. 
> I've got a demo in the works on Octave-Forge, I'll put some time into 
> expanding it, and once it's ready I'll prepare another release of the package 
> together (although it does feature an application of the functions, it 
> doesn't use all of them yet, I don't think.)
>
> In response to the first question, then, I don't think the arguments can 
> really be estimated without possibly running the function first; I'd be happy 
> to get some input on that, though.
>
> Thanks for your feedback on the package!
>
> Ben

Hi Ben,

NUMCOEFF (which from your explanations is more like NUMFREQS. Also
NUMCOEFF is not happy cause the values of the transform are called
coefficients... according to my sources! So it seems NUMCOEFF is the
size of the output of the function...which is not). This is a free
parameter, I agree and the user must provide it, though it could still
have a default value, let say 10 (or whatever).

Can't the MAXFREQ parameter be estimated form the smallest time
interval? something like
maxFreq = pi/min(diff(t))
Also the minimum frequncy could be minFreq = pi/(t(1)-t(end))

If it can be done, then you could get NUMOCTAVES (again an octave is
not that well defined, I assume you mean halving or doubling the
frequencies) as
numoctaves = round (log (maxFreq/minFreq) / log (2))

What do you think?


-- 
JuanPi Carbajal
-----
"It is one thing not to be able to perform a certain feat, but quite
another to prove that it cannot be done." - Henry Ernest Dudeney
-----
http://ailab.ifi.uzh.ch/carbajal/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]