P.J. Plauger said:
At a quick glance, I'd say you're violating my copyright in the
most blatant and irresponsible manner. If the infringing stuff
isn't off the internet in short order, I will be taking legal
action.
I'm going back to your original response for my remarks and questions.
At first I thought, "Oh, this is like SCO's suit against IBM". I
wondered what could possibly be in math.h which isn't obvious.
Wow.
I even
wondered whether you were THE P. J. Plauger, or whether the post was a
forgery.
I glanced at a couple of functions from the library, and the
implementations seemed straightforward. I assumed the constants came
from the Remez algorithm, which any competent graduate student could
implement and apply--or, as you note in a later post, you can use
Maple; in any case, I don't consider these to be very secret or
private. Surely they should be regarded as derivative of others' work.
There is an enormous literature on implementing mathematical functions
to the minimum number of ulps, even in extra-high precision [e.g. David
Bailey, the Gnu Multi-Precision Library]. Most of the algorithmic
stuff is open-literature (implementations may be copyrighted, or more
usually "copylefted"), and are far deeper and more extensive than
anything I see in math.h. Such a literature is one of the advantages
of an academic establishment.)
Us greedy capitalists read the literature too, y'know.
But as the dialogue progressed, e.g. with _Dint, I began to realize
that some serious infringement HAD taken place.
Thanks.
Now I begin to worry
about the SCO lawsuit; I surely hope Linus Torvalds documented his
work.
I think the issue is only loosely related, but what the hell, that's
his problem.
In particular, I was impressed by your defense of copyright as opposed
to software patents (which I have always found offensive--almost as
offensive as patenting sections of the human genome). I have no
argument that a small company like Dinkumware has to protect its
sources of revenue.
Thanks again.
But as a mathematician and USER of software, I have to wonder what's
the point of isolating possible machine dependencies so precisely.
Every compiler I've ever used has come with its own math.h, and very
often I've adopted the chip maker's version to replace the standard
libraries (ESPECIALLY implementations of BLAS and LAPACK, which are
enormously more intricate). It's easy enough to write a script to
detect what platform the program is being compiled for, and to use
highly-optimized libraries for the particular platform.
If the platform has them, perhaps.
So what would be the advantage, to me, of using Dinkumware's products?
Perhaps if I were a developer trying to get my product out on 18
different processors, I could see it; but even then, I'd HAVE to use a
compiler specific to each processor, and surely these will come with
their own libraries. Of course, these often have bugs (and the
perambulations in code necessary to circumvent bugs are notorious).
So I repeat, what's the point? (Understand, I've only ever developed
on the P4, the AMD64, and the PPC, so I may not fully appreciate the
difficulties.)
Evidently. You cited the most obvious -- bugs. We've developed what
I believe to be the best math testing harness in the business (and
in academia as well, from what I've seen so far). We've used it to
test all sorts of math libraries out there, and we've found all
sorts of problems. Don't get me wrong, the basic double math library
required by C89 is generally pretty good when you get it from the
likes of Microsoft, IBM, or Sun. But beyond that obvious quality
circle lies a mishmash. The evidence to date is that we test other
people's code way more than they do. That's particularly true of
open source. (It's a lot more fun to write new code and spread it
around the world with your name on it than it is to write tests
and run them.) We also use these tests to develop our own math
functions, of course, so we know they're good.
But if you don't care whether your math functions return correct
answers, it's fine to use whatever comes with your compiler.
Then there's the matter of completeness. We provide a complete
set of C99 math functions in all four IEEE precisions -- 24-bit,
53-bit, 64-bit, and 113-bit. Those compilers that pretend to
supply 24-bit float usually just wrap 53-bit double, so you get
no performance boost as you might expect. We've found a couple
of compilers that claim to support 64-bit long double, but
reliably deliver only 53-bit results. At the other extreme,
some 113-bit functions try way too hard, evidently because
their authors didn't know when to stop adding terms. We use
our tests to ensure a proper balance between accuracy and speed.
But if you're content to use just the C89 double math functions,
and you don't care about performance, you may not need anything
better.
What we offer, by contrast, is the assurance that you can use
our library on a variety of popular platforms, all the functions
you need are there, and they work right everywhere. To pull that
off we've had to be pretty inventive, over many years. You may
believe that the academic literature is a ready source of all
the information you need to knock out a decent math library,
but we know better. For one thing, it's still a big step from
most academic papers to good working code. For another, many
of the techniques we've tried from the literature over the past
several years have proved to be unstable, inaccurate, or simply
wrong.
We're just starting to build the competitive analysis part of
our web site to go with our new product launch. Soon you will
be able to see a few comparisons between our new library and
what comes with different compilers. And we'll provide a few
essays on the lesser known pitfalls of numerical computing.
Maybe then you'll see the point in licensing yet another
library when you already have one you've been using for years.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com