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:
- 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.
- 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?
- 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.
- 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).
- 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:
- 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.
- 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>]
- 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