Monday, September 11, 2006

Numerical Mathematics Consortium explains its problems

Last time I wrote about the Numerical Mathematics Consortium project to create a standard for numerical math algorithms, I was impressed with the work rate, though still sceptical about its direction.

A new document released by the consortium this week, reveals a much less impressive rate of progress as the committee hits the swamp of problems that the project needs to resolve.

The document summarizes and illustrates some of the problems quite neatly, but doesn't present a compelling case for their solutions which seem pragmatic but quite arbitrary.

In the 8 months since agreeing the nearly 200 functions to standardize, they have so far agreed the standard for just 10. The document claims that we should expect and increased rate, though we should only expect biannual reports of the progress. So I think we can conclude that this project will take years not months.

An early compromize is a bad omen for the future- There are already two levels of 'standard' (required and optional). This is exemplified by whether a particular function needs to support both real and complex numbers. Real support might be required but complex support could be optional. It is suggested that other features of range or type might be also options for different functions.

Since the claimed purpose was algorithm portability, what sense does optional support make? The only way to expect portability will be to restrict yourself to required support functionality. And so the usefulness of this standard contracts down to the lowest common denominator between the partner systems. But who wants to buy expensive software, to then deliberately restrict ones usage to a small subset of the functionality?

If they had set a level 1 and level 2 support, and required that ALL of the extras in the higher level must be supported, to claim that level, I might see some sense in it. But as it stands, they may end up being hundreds of separate places where a "standard" algorithm will fail when moved to another system that supports the "standard".

Politically speaking, this kind of decision may be inevitable. If you have some functionality in your product, you want to convince the other members of the committee to include it in the standard. If you don't have that functionality, you want to exclude it, so that you are not forced to build it. Put a group of such vested interests in a room, and you either fail to agree or find some compromize.

1 comment:

Serge Steer INRIA said...

As a participant to this first version, i agree with some of your remarks.

In my opinion, the only way to be able to produce a standard which can be really used, is to have a large number of contributors to do this work.

We started the work, now the NMC consortium needs to be reinforced.