help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Finding peaks/max in a graph


From: mavram
Subject: Re: Finding peaks/max in a graph
Date: Tue, 20 Jul 2004 19:02:41 +0300
User-agent: Mutt/1.5.5.1+cvs20040105i

On Sun, Jul 18, 2004 at 01:22:39PM -0600, Joe Koski wrote:
> 
 
> Since I did not write the original emd.m routine, I can't legally give you
> the modified routine (I can't give you what isn't legally mine), but I can
> tell you what I did to get emd.m to work with Octave.
> 
> First, Rilling used the "end" key word in vectors in several places to
> indicate the last element of a vector. I went through, and wherever Octave
> complained, I inserted something like end_array = length(array); in a line
> before the statement and edited end to end_array (or whatever). You have to
.... 
> Good Luck!
> 
> Joe Koski

Dear Mr Koski,
Thanks very much for the prompt and helpful answer.
I started working on the meanings of "end" in Rilling's code and I found
out that in most cases, the way you used to circumvent it, is still
actual. Although "end" is already defined in Octave, its use in 
expressions like   lmax = fliplr(indmax(1:min(end,NBSYM))); is not
recognized by it.
It seems to me that the use of lM and lm in the program is very
consistent, so that replacing end by lT in such assignments might be
enough. Same for indmin and lt. But this is still to be checked.
        A very special thank you for the indications about the spline 
functions, with which I am not yet familiar.
        I did not decide yet about the graphics. In general I prefer the 
liberty given by statements like figure(1); plot... , over the subplot scheme...
But this is a minor point.
        I was surprized by your reticence to send me your modified routine. 
In my years of formation, in the first half of the 20-th century, a result
published by an academic institution could be used by anyone, and shared
with a coleague UNLESS EXPLICITELY STATED OTHERWISE. You were expected,
of course, to give proper credit to the author, but nothing more. Only
if you wished to PUBLISH a revised version, it was customary to submit
him the text and ask for his permission, to make sure you do not
attribute him things that he did not meant. Rilling et al.'s paper was
published with the obvious goal of sharing their findings with others and I
saw nothing to the intent of limiting their use. THERE WAS NOTHING
EXPLICITELY MENTIONNING THAT THIS IS FREE, EITHER, AND HERE THERE MAY BE
DIFFERENCES BETWEEN THE CUSTOM OF 50 YEARS AGO AND NOW.

There is a practical aspect to this point: Judging by the flood of
papers that followed Huang & al's publication in the Proc. Royal Soc.
London A, Vol. 454, pp. 903-995, 1998, trying to use this new technique
in every conceavable field, I expect, that lacking functions to carry
it, would put Octave in an inferior position. "Translating into octave" 
the algorithms implemented in emd.m and putting this to the disposal of
all octave users would be a convenient starting point. The question is
if this is legally feasible and how to do it.

The most qualified people to answer this question are, probably those
heavily involved in the development of octave. I CC therefore a copy of
this letter to Paul Kienzle (he seemed interested enough in the subject
to comment on your answer to me). I shall welcome, of course any other
opinion.

Cheers, Avraham



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]