Re: proposal for new m-file function

[Martin Helm]

Am 22.03.2012 15:37, schrieb Ben Abbott:
> On Mar 22, 2012, at 10:12 AM, Martin Helm wrote:
>
>> Am 22.03.2012 13:17, schrieb Ben Abbott:
>>> On Mar 22, 2012, at 6:31 AM, Martin Helm wrote:
>>>
>>>> Am 22.03.2012 10:43, schrieb Carlo de Falco:
>>>>> 2012/3/22 <address@hidden
>>>>> <mailto:address@hidden>>
>>>>>
>>>>>   Message: 2
>>>>>   Date: Wed, 21 Mar 2012 20:33:01 -0400
>>>>>   From: Ben Abbott <address@hidden <mailto:address@hidden>>
>>>>>   To: octave maintainers mailing list <address@hidden
>>>>>   <mailto:address@hidden>>
>>>>>   Subject: proposal for new m-file function
>>>>>   Message-ID: <address@hidden
>>>>>   <mailto:address@hidden>>
>>>>>   Content-Type: text/plain; charset="us-ascii"
>>>>>
>>>>>   A user's question about fixed points piecewise-linear fitting led
>>>>>   to the development of a function looks to be a good fit for
>>>>>   Octave's core.
>>>>>
>>>>>
>>>>>    
>>>>> https://mailman.cae.wisc.edu/pipermail/help-octave/2012-March/050900.html
>>>>>
>>>>>   The idea was to fit a piece-wise polynomial to a set of data.
>>>>>   After some discussion between myself and Martin Helm, the attached
>>>>>   ppfit.m was produced. The name was chosen to match the existing
>>>>>   ppval().
>>>>>
>>>>>   The function provides a least-squares fit of a 1D interpolation
>>>>>   with specified break positions to a set of data.
>>>>>
>>>>>   Demos and tests are included.
>>>>>
>>>>>   Any concern about adding this to Octave's core ?
>>>>>
>>>>>   Ben
>>>>>
>>>>>
>>>>> googling for the name 'ppfit' I found this function:
>>>>>
>>>>> https://www.assembla.com/code/zaxxon_scripts/subversion/nodes/trunk/project/scripts/ppfit.m
>>>>>
>>>>> which seems to do the same as yours with the additional option of
>>>>> returning a spline with N continuous derivatives
>>>>> Would it be possible to add that option to your code?
>>>>> The license of the linked function looks like BSD so it should be no
>>>>> problem to get the code from there.
>>>>> c.
>>>> Wouldn't it be much cleaner to add that additional fitting options
>>>> (quadratics and higher order splines) to interp1 (without breaking
>>>> matlab compatibility of course)?
>>>> I think that is the place where such functionality should naturally
>>>> live. I could look at it over the weekend and propose a patch for it.
>>> Ok. I'll wait on your changeset.
>>>
>>> Is it possible for interp1 to return the available methods and whether the 
>>> underlying interpolants are linear functions ?
>>>
>>> Ben
>>>
>>>
>> What do you have in mind, is something like interp1("methods") which
>> returns some cellarray for example with the method names and a flag
>> indicating linear/nonlinear an option?
> Something like below?
>
>       [methods, linear] = interp1 ("methods")

Yep
>> For the linearity there is of course the question in which way linearity
>> is seen:
>> (1) The interpolation being a linear operator as a function of the node
>> values for every given set of nodes or (2) the calculated interpolant
>> (in a piecewise sense)?
> The first.
Ok

>       
>> The first one is what I referred to when we talked about why for
>> pchip/cubic the simple linear system for calculating the least squares
>> solution fails and the nonlinear solver is essential, the second would
>> only be true for option "linear" anyway. The first one is what makes
>> most sense IMHO as an additional information.
>> I hope I did now not misunderstand your suggestion.
> Agreed. I plan to use the information to determine if fsolve() is needed or 
> not.

That is what I had in mind as your use case.
>> In any case if enhancing interp1 with additional features not existing
>> in the corresponding matlab function is not what is wanted it is of
>> course also a possibility to write an extra wrapper function (interp1e =
>> interp1 enhanced?) which provides the additional features if that is the
>> preferred way to handle that in octave.
>>
>> I am not too familiar with the precise philosophy in octave here if ML
>> compatibility also means = restricted to what ML provides for that
>> function or if a generalization to provide a superset of features is ok.
> Octave's functions are permitted (encouraged?) to have additional 
> functionality. But that functionality should not break compatibility (Octave 
> should run Matlab code). We don't make any effort to ensure Matlab runs 
> Octave code.
Sounds good.

> Ben
>
Expect the patch latest on Sunday, I will post it to this thread.