Wednesday, December 21, 2005

Numerical math consortium - the new OpenMath?

In the news recently is the numerical mathematics consortium,
http://www.nmconsortium.org, which is attempting to define an open
standard for numerical math. But how does it expect to succeed where
OpenMath, http://www.openmath.org/ has so far failed?

When you look at the expertise of the NMC in numerical math an odd picture
emerges:

MathSoft make a computationally light-weight product, MathCAD. Their
real innovation and experience is in the interface design, not in numerical
algorithms.
MapleSoft have no real experience in numerical computation either, instead
buying in their numerical libraries from NAG.
National Instruments is a major company but one who have never developed
numerical software, instead purchasing MatrixX after Mathworks were
forced to sell it.

Only INRIA have any real experience. Being academic collaborators on
other open source consortia, they might be expected to join in any such
an effort.

Absent are obvious significant experts in numerical math- Mathworks,
Wolfram Research, NAG etc.

Now look back at OpenMath. It was arguably the symbolic version of the
NMC. The main contributors were NAG, makers of Axiom, then a recent
addition to the symbolic computation market, contributors to computer
algebra systems GAP, Reduce and MAGMA, all fading even then and
MapleSoft, a significant company but not leading in their field.

Just as MapleSoft once gathered minor players in computer algebra around
them in the hope of competing with Mathematica, now it seems National
Instruments are gathering minor numerical math partners in the hope of
taking on Mathworks (who they are in unrelated conflict with) and Wolfram.

Will it work this time? The commercial forces are bigger, but
ultimately, it can only work if they make a standard that is any good,
and since the experience comes from INRIA, who contributed to the
bloated un-implementable OpenMath standard, it could be another good idea
which will take a decade to go nowhere.

Tuesday, December 20, 2005

Mupad - what went wrong?

A sad tale of politics at http://fuchssteiner.info/ explains why Mupad has
been withdrawn. The bottom line is that the Paderborn University, which has
funded the development of MuPad for many years, has had enough and closed the
project.

If MuPad Pro is to survive SciFace, the company that marketed MuPad and MuPad
Pro, and which developed the additional MuPad Pro interface will need to fund
itself. According to Dr Fuchs, the company was almost bankrupt in August
BEFORE the funding was removed. August is a tough time for companies which
sell to academics, due to the holidays, and unfortunately for SciFace, it
comes round every year. Can SciFace become viable within 8 months? It rests on
whether the 93% of the users who have, im the past, opted for the free MuPad
can be persuaded to pay for MuPad Pro. Without the resources to produce a
compelling upgrade, this seems unlikely.

It is hard to judge the rights and wrongs of the bitter dispute that Dr Fuchs
has had with Paderborn University but ultimately the problem was structural.
The entire viability of a product, the technology and the investment of the
user base rested on the generous support of one contributor. And what did
Paderborn University get out of it? Prestige? a skills base? pleasure in the
knowledge of their generous donation to the world? Intangible and evidently
unconvincing return.

Is there a lesson? Only one current product comes close to the same economic
model - SciLab, but there some significant differences. The lesson is more
general- before you lock yourself into a technology today, count how many
people you are relying on to fund and provide you support tomorrow. If its a
commercial company, count the paying users, if it is open source, count the
contributors (both programming and finance support).

Safety in numbers.

Friday, December 16, 2005

Math documents, XML and hidden traps


I took a closer look at the file formats of the three main computational
products that have a document system: MathCAD, Maple and Mathematica.

MathCAD and Maple are both sporting new XML formats, Mathematica has a
LISP like functional text format and option to save in XML.

With XML so widely supported, this seems like good news for portable
technical information. But beware, danger lurks below the surface.

While the first half of the MathCAD file is nice, understandable text like

<math optimize="false" export="false" disable-calc="false">
<ml:define>
<ml:id subscript="15">z</ml:id>
<ml:apply>
<ml:id>Z</ml:id>
<ml:sequence>
<ml:real>1</ml:real>
<ml:real>5</ml:real>
</ml:sequence>
</ml:apply>
</ml:define>
</math>

which one could import into another system and manipulate, index, search
etc. Suddenly half way down you find entries like

<binaryContent>
<item
item-id="1">iVBORw0KGgoAAAANSUhEUgAAAHgAAAAvCAIAAACnjZnKAAAAAXNSR0IArs4c6QAAAARnQU1B

AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA
AkVJREFUeF7tmdtyBCEIRJP//+jJZbYmFmCDLBKsYp9S2RGaI7au83ld10d/Egh8g67zueut
oydQSa2qGnTg1KJQDbpBywQeb1cBtXWoiKYPjNuJurU0aD/ocWSDjuGIo6iUf87QGULMOU7c
DI2aG7S5C...

A similar trick is played in the Maple file- images and typesetting in
some encrypted binary format.

Only the Mathematica formats are entirely open text although you would
need to map the LISP syntax

Cell[BoxData[
SqrtBox["2"]], "Input"]

to XML version

<Cell class='Input'>
<BoxData>
<List>
<SqrtBox>
<String>2</String>
</SqrtBox>
</List>
</BoxData>
<Style>
<String>Input</String>
</Style>
</Cell>

Unless you remember to use Save As XML as your standard format.

So why follow XML semantics but obscure the contents?

The first part is easy- XML is a buzz word and everyone wants to say
they support it, and with open source code available to manipulate it,
it cuts R&D costs.

I think the obscuring is for different reasons between the two
offenders. MathSoft also sells a document management tool. How can you
hope to sell that against better, and probably cheaper, XML management
tools? Easy, make the contents choke the XML tools so only your tool can
do the job.

For Maplesoft, who have no tools to handle the documents apart from the
creator, the reason is, I suspect, very traditional. By locking the
content into an un-intelligible form, it makes it hard for users to
migrate to something else.

Well done Wolfram for staying away from the oldest customer exploiting
tricks in software. But please make the XML the default method soon.

Thursday, December 15, 2005

Mathematica Personal Grid Edition

Wolfram have announced a product aimed at the new generation of quad core
computers
http://www.wolfram.com/news/personalgrid.html

This looks like a mini version of their GridMathematica product and will run
four copies of Mathematica on your computer, one as a master and three as slaves.

GridMathematica is a well designed product. The interesting question is
whether the market is there for small scale grid computing, given that some
parts of normal Mathematica (mostly numeric linear algebra) will already use
all four cores automatically.

I doubt that it exists now, but it will only grow and Wolfram is the only one
targetting multi-core technical computing at the moment.

Opening comment

As a user of many different scientific computing products, I have learned a lot about the various strengths and weaknesses of the packages. This site will be a place for news and comments on scientific computing.