On Wed, Oct 3, 2012 at 3:14 PM, Benjamin Lewis <ben...@gmail.com> wrote: > Le 2012-10-03 à 05:41, JuanPi <ajua...@gmail.com> 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 Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
