Re: [OctDev] [PKG] lssa

[JuanPi]

On Thu, Oct 4, 2012 at 5:03 AM, Benjamin Lewis <address@hidden> wrote:
> Le 2012-10-03 à 09:39, JuanPi <address@hidden> a écrit :
>
>> 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?
>>
>
> Hi JuanPi,
>
> A lot of the naming conventions have resulted from following the original 
> code, which was written in a combination of R and C code; I'm thinking this 
> was a mistake in a few areas, and I agree with renaming NUMCOEFF to NUMFREQS. 
> I'm leery of giving it a default parameter, but 10 makes sense. (Possibly 
> more, though; in the data set I was working with for testing, I regularly 
> used 100 frequencies/octave.)
>
> The NUMOCTAVES concept is drawn directly from the musical idea; a 
> doubling/halving of the frequencies. I would probably say that 10 could again 
> be used as a starting value for this, but it depends greatly on the data set 
> involved. I'm not sure imposing a minimum frequency is a good idea, 
> especially not to maintain compatibility with the original code that was used 
> as a basis for implementing this package.
>
> On the other hand, I do agree with your choice for an estimated default 
> MAXFREQ value.
>
> I'll try out these changes tomorrow morning.
>
> Ben

Hi Ben,

The minimum freq is not an imposition, it is just a value you
calculate to be able to estimate a reasonable number of octaves. For
the calculation I gave I was assuming that maxFreq gets dividide
succesively by 2 untill you reach minFreq. It is just an estimation to
get a reasonable value nothing more.

We should made a Wiki entry discusing all the knowledge you have gain
and showcasing the package in a not uniformly sampled data (I have
some visual tracking data which is highly non regularly sampled) vs
interpolation+FFT.

Looking forward to testing more of your package, really interesting!

JPi


-- 
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/