Friday, January 13, 2006

First draft of Numerical Math Consortium "standard"

The Numerical Mathematics Consortium has already published a first draft- a list of the first 250 areas of functionality to be covered by their plan for a standard.

http://www.nmconsortium.com/upload/NMC%20Technical%20Specification%20v1.0%20_DRAFT.pdf

This 'draft' is clearly meant more as PR than a serious design document. Nevertheless one can get clues as to their direction:

There is no reference to handling data of higher dimensions than a matrix.

There seems to be a bias towards special cases rather than general. eg there is 'log base 2', 'log base 10', 'atural log' but there is no' log to base n'. One could construct this from the others, but why have three when one could do? Conversely, for power there is 'real power' which would cover all cases, but then there is also a special case for 'power of 2'.

There is some confusion about whether the standard will define tasks or algorithms. Most of it appears to define tasks eg Bessel makes no mention of what algorithm to use, that is left to the implementation, the same for most of the 250 functions. However for numerical integration we find 'Numerical Integration (2D)'
'Numerical Integration (3D)', 'Numerical Integration (Adaptive Labatto)'
'Numerical Integration (Adaptive Simpson)', 'Numerical Integration (Trapezoidal Method)'. So here we have specific algorithms listed as well as the general task. To what level of detail will the 'standard' attempt to define the algorithm? Any step down this route will lead to trouble for implementors.

The 'power of 2' example is about algorithms too. It is there because power of 2 lends itself to a special case algorithm that is faster and more robust than a general power algorithm. Why not leave the handling of special cases to the implementor to decide? A cheap implentation could decide to ignore special cases, a good implementation could detect and branch on special cases.

All this becomes a bit clearer when you look at the 'example' function mappings. While these claim to be illustration examples only one discovers that every one of the standard commands is shown to have a direct mapping to a single function in Matlab. This is most strange when you consider that MathWorks are not on the committee. Is the whole standard going to be a Matlab clone in disguise? Is the real purpose to set up Matlab code importing?

Its too early to judge, but the only thing that has impressed me so far, is the speed at which they are working.

[See also previous comment "Numerical math consortium - the new openmath?"

No comments: