Re: [boost] TR1 Mathematical Special Functions

From: AlisdairM (alisdair.meredith_at_[hidden])
Date: 2006-08-08 14:44:45

Gennaro Prota wrote:

> Frankly this surprised me too. First of all, none of the vendors which
> also supply a standard library (note: with this I'm deliberately
> excluding EDG) seem to care so much about quality as the above
> statement seem to imply; they do all sorts of silly errors, which go
> from macro-guarding <cassert>, to making numeric_limits<> members
> non-ICEs. And this is just 101; let us not speak about *serious
> errors* (of the kind which can make a perfectly conforming program
> crash under your eyes). A recent post in "[string_cvt] help with VC
> 7.1 is needed" should tell enough about the amount of testing many
> vendors put in their compilers (I wonder what they really do when they
> delay a release for one year or so). And, after all, why not going
> with a N1426bis ("Why we can't afford special math functions") which
> explains in depth why a whole company cannot do what 3 persons alone
> have done excellently, and for years?
> 
> Sorry for being harsh, but it seems to me excluding something from the
> standard just because one vendor didn't want to face it is sacrificing
> the majority of users for the sake of a commercial minority.

Personally I think you are being very harsh to dismiss the level of
testing that goes into shipping a major commercial compiler and
library.  Simply working with my own code I have to accept that no
non-trivial codebase is going to be bug free.  And I don't have to
support legacy users relying on the bugs in my older implementations,
which they expect me to support for years to come...

The issue is raised exactly because commerical vendors are VERY aware
of the cost of validating that kind of library, including finding
someone with sufficient mathematical background to verify the tests
themselves are valid!

And note that QA is only one concern, among several vendors.

I still would very much like to see the whole of TR1, including math
functions, adopted in the next library.  I believe most of the Library
working group are quite satisfied with what has been delivered with
TR1, and any vendor who has implemented it for the TR would really like
to see that work pay off in the main standard as well.

We are still several years away from a new standard though, and there
is time for things to change.  An effective Boost implementation that
can be packaged for free would go a long way to lowering the barrier of
adoption, but is by no means enough in itself.

-- 
AlisdairM