RE: [boost] Re: C++ Standard Library proposal - Math functionsforStatistics

From: Powell, Gary (powellg_at_[hidden])
Date: 2003-04-15 10:23:22

Here is my take on the committee discussion on Walter's additions, "special fns" which included a number of Bessel functions:

First we looked at whether these additions would be of benefit to the whole of the C++ user communities. And decided that it isn't but that the sub group who are interested is still a large enough number of people to make it worthwhile.

Second, we asked the library vendors how hard would it be to implement all these fns. And they said, hard, but not too hard, but that they would get back to us soon. And since this stuff is only going into a Technical Release, they felt that if they started and abandoned the project they wouldn't be penalized.

Third, we looked at the commercial vendors options, and found that the interfaces varied and made code written to them non portable.

Fourth, and we were lucky here, Walter had another ISO standard which defined the interfaces to the fns which we could cite as why we went with the interface we did.

So after this long winded bit, I challenge any proposal to the standard library must meet the first 3 criteria for likelihood of acceptance.

Now recognize that the committee does not have expertise in all areas of math and science, so we rely in part on experts who are willing to come to the meetings and answer questions. It really helps.  Also a boost reference implementation also makes point 2 moot. A large group of boost users can satisfy point 1. (And will help identify whether we have the correct interface. There is nothing like standardizing too soon.) And probably that we are even talking about it in boost means that there is either no good interface of many and thus standardization of the interface would be a good thing.

Now I am not a voting member and the above statements are my observations after having attended a number meetings. They are not any guarantee of future actions by the committee.

And an unwritten proposal has no chance of acceptance. While a written one which has defects will be sent back to the author for fixing. If the author is willing this work can be done the week of the committee meeting.

Notice, there is no mention about C vs C++/template/exception interface. Each library is judged on its own. Do what is best for your library and for the good of the language as a whole.

   Yours,
   -Gary-

-----Original Message-----
From: Hubert Holin [mailto:Hubert.Holin_at_[hidden]] 
Sent: Tuesday, April 15, 2003 6:09 AM
To: boost_at_[hidden]
Subject: [boost] Re: C++ Standard Library proposal - Math functionsforStatistics

Somewhere in the E.U., le 15/04/2003

   Bonjour

In article <AHEJIHEOOOBMJPAGPLIPOEFGDNAA.boost_at_[hidden]>,
 "Paul A. Bristow" <boost_at_[hidden]> wrote:

> C compatibility is deemed very highly desirable by many, even BS Himself!

      No disagreament here.

> Even if a C++ exceptional version is better as well as more Politically 
> Correct.

      There is a question of balance, obviously. Would we be happy if we 
only had C strings? Being able to invoque a C library should not 
preclude the creation of a (more suitable) C++ one. In the present case, 
is it realy worth it to do more than rubber stamp C99's libraries 
(inclusion by reference), if the philosophy which would underline C++'s 
libraries would ignore the many advances of our languages?

> But there may be more than one way to achieve that, and any case, for most
> functions the hard bit is the algorithm, its size, speed, accuracy, accuracy 
> at
> limits, and testing.

      Balance again. The C math libraries are mostly one-size-fits-all 
kind of things. Why not say we just included (by reference) C's math 
libraries and mandated (in a new namespace) C++ libraries where more 
control could be exercised (extremely precise but crawling versus 
lightning fast but sloppy, for instance)?

> There seems to an argument that using templates & exceptions will make it 
> less
> likely to become a C++ Standard. It may be regrettable but true.
> 
> So I would not discourage you at all.  But do look at the prior art first.

      Agreed, prior art is a must.

      Discouraging me is another matter. Why should I go ahead with an 
implementation? If there is not the remotest possibility of it being 
standardized, and even worse if it could hamper standardization of 
usefull tools, there would be no point in going forward. There is no 
need for a proof-of-concept if it is known the concept is already 
dismissed. If there is standardization aroud C-like libraries, the 
commercial outfits will see to it that there are implementations, which 
would most likely not be based on mine. As for the free platforms, what 
benefit would they derive from implementations I would propose, if they 
knew it would not be standard (and most likely not complete before a 
long time, as I can only implement so many functions in my vanishing 
spare time, and I certainly lack the perpective a full academic team 
could provide)? Would anybody find that work usefull?

      So, again I must ask, is someone interested in what I could put 
forward, or should I just forget it all?

> Moshier's Cephes is the best C implementation (and best book) I have found 
> (but
> unsuitable licence), but there are many contributions in F*****N which 
> actually
> work well (and perhaps better).
> 
> NIST have an on-going project to update A&S too (but a book, not code).

      Yes, I am monitoring their progress, thru their public website.

> Paul
> 
> PS Kolmogorov-Smirnov statistics could indeed usefully be added.
> 
> Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
> [phone]   Mobile [phone]
> Mobile mailto:pabristow_at_[hidden]
> mailto:pbristow_at_[hidden]

[SNIP]

   Bon courage

         Hubert Holin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost