[PKG] lssa

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[PKG] lssa

JuanPi
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.

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

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [PKG] lssa

Benjamin Lewis
Le 2012-10-03 à 05:41, JuanPi <[hidden email]> 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
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [PKG] lssa

JuanPi
On Wed, Oct 3, 2012 at 3:14 PM, Benjamin Lewis <[hidden email]> wrote:

> Le 2012-10-03 à 05:41, JuanPi <[hidden email]> 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/

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [PKG] lssa

Benjamin Lewis
Le 2012-10-03 à 09:39, JuanPi <[hidden email]> a écrit :

> On Wed, Oct 3, 2012 at 3:14 PM, Benjamin Lewis <[hidden email]> wrote:
>> Le 2012-10-03 à 05:41, JuanPi <[hidden email]> 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
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [PKG] lssa

JuanPi
On Thu, Oct 4, 2012 at 5:03 AM, Benjamin Lewis <[hidden email]> wrote:

> Le 2012-10-03 à 09:39, JuanPi <[hidden email]> a écrit :
>
>> On Wed, Oct 3, 2012 at 3:14 PM, Benjamin Lewis <[hidden email]> wrote:
>>> Le 2012-10-03 à 05:41, JuanPi <[hidden email]> 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/

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev