[PD] better tabread4~

[Matt Barber]

An idea on naming:

It should be possible to exhaust all the different schemes for
interpolations involving a given number of points, and it should be
possible to do so hierarchically.  For four points, e.g., we have:

3rd degree polynomial, setting:

A)  x[-1], x[0], x[1], x[2]   (Pd's Lagrange default - match point values).
B)  x[0], x[1], x'[0], x'[1]   ("third order Hermite" example in SC3,
current [tabosc4c~] - match inner point values and first derivatives)

5th degree polynomial, setting:

C)  x[-1], x[0], x[1], x[2], x'[0], x'[1]   (match all points, first
derivatives at inner points)
D)  x[0], x[1], x'[0], x'[1], x''[0], x''[1]  (match inner points,
first derivatives, second derivatives)

7th degree polynomial, setting:

E) x[-1], x[0], x[1], x[2], x'[0], x'[1], x''[0], x''[1]  (match all
points, first and second derivatives at inner points)

(missing any?)

For polynomial interpolation using four points, if the above is right
there are 5 ways to do it, and they are ordered first by degree of
polynomial, then from fewest to greatest number of derivatives
matched.  I tend to agree with other posters who suggested that this
kind of organization might best lend itself to one object with
interpolation type specified by an argument or message.


The argument could follow one of a couple standards:  1) a numeral or
letter in order, as above, or 2) a descriptive argument.  The
descriptive argument could work something like this:

[tabread4~  array]  -- default to cubic Lagrange
[tabread4~ array 3] -- explicit cubic Lagrange
[tabread4~ array 3d] -- cubic, C1
[tabread4~ array 5dd] -- fifth-degree, C2

etc.

[tabread4~ array 3dd] -- cubic, C2 -- doesn't exist, object doesn't
create -- might post a list of available options.

The d or dd could be replaced with whatever, as long as it was
descriptive of the level of continuity.


Cons first:
1)  No matter what, the argument will be somewhat opaque, and some
people (myself included) would probably have a hard time easily
remembering what the arguments mean, which ones are available, and
why.

2)  List of possible arguments grows a great deal with the number of
points in the interpolation.  Also, the first and second derivatives
have more numerical approximations with a larger set of points -- one
would assume you'd go with the most accurate.  Do the third, fourth,
etc. derivatives ever get used to derive the polynomial?

3)  Having them organized hierarchically by type might imply to some
users that they are also ordered by quality (Lagrange worst,
7th-degree best), while this might not be the case at all.

4)  We haven't proven that an exhaustive set is even desirable.  Also,
it's unclear which should be the default from a theoretical standpoint
(though obviously the current standard should be default for
historical purposes).

5)  This would force the user to apply an array name if they wanted to
set the interpolation.  Same with the class method "set."  Also,
having a numeral or a symbol to call the interpolation (3 vs. 3d)
might make things tough to implement -- this could be changed.


Some Pros:

1)  This scheme could be imported directly into Pd (vanilla) with very
little cost, since the default would just be the normal Pd
interpolation; this, provided Miller approved such an expansion of
something relatively low-level.  It would necessitate no change in the
implementation of array methods (cosinesum, etc.) since all of these
would be 4-point.  It would also move the choice of "best" from
programmers to users; the benchmarks could be referenced in the
documentation and suggestions could be made for different applications
(giving both a "what's it do" and a "what's it for" kind of
documentation), and give users of vanilla access to a wider selection
of interpolation.

2)  The external library of other interpolations could be organized
around how many points used ([tabread2~] for linear, [tabread6~] for
6-point).  Naming becomes easier and more explicit.  Objects which
mimic array methods could be made for any of the various
interpolations -- [arraycosinesum array size interpolpoints <list of
harmonic amps>]

3)  The formulas themselves could be tucked into functions for easy
use in other external libraries, but you might not want to introduce a
function call for every interpolation into the main tabread, tabosc,
and vd object classes.


I'd welcome any comments.

Thanks,

Matt