Re: [OctDev] [PKG] lssa

[Benjamin Lewis]

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