Le 2012-10-03 à 09:39, JuanPi <ajua...@gmail.com> a écrit : > 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? >
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 Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
