On Thu, Oct 4, 2012 at 5:03 AM, Benjamin Lewis <ben...@gmail.com> wrote: > 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
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 Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
