Re: [boost] Math Constants Library formal review results

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-05-20 18:55:45

At 10:05 PM 5/19/2001, John Max Skaller wrote:

(see below)

John is likely right in his reading of the committee, but on the other hand 
this is Boost and we don't have to be as restrictive.  We can accept a 
library with three forms of something if we want, and then only end up 
proposing one of those forms for eventual standardization.  Or we could 
propose one form (macros) to the C committee, and another to the C++ 
committee.

Usually it is a lot better not to confuse users with several forms of the 
same thing.  But if there are powerful arguments for each of the forms, I 
don't see a great deal of harm in Boost supplying them all, as long as the 
documentation delineates the rationale and gives users guidelines for 
choosing.

--Beman

 >Ed Brey wrote:
 >>
 >> > "John Max Skaller" <skaller_at_[hidden]> wrote:
 >> > >
 >> > > 4. You do NOT need to satisfy all users.
 >>
 >> Nor is it even possible.  One group of unhappy users will be those who
 >> want a single interface.
 >
 >	This may be the most important group: the committee :-)
 >
 >> Having the C (macro) interface and the C++
 >> interface will make those users unhappy.  However, given a willingness
 >> to forsake them, it might be possible to make everyone else 
happy.  Once
 >> you've opened the door to multiple interfaces, you might as go all the
 >> way and make as many interfaces as you need to cover all the
 >> (conflicting) requirements.  Give pi to those who want
 >> qualification-free (including parentheses) names.  Give pi() to those
 >> who want inlining and constant-folding.  Give BOOST_PI to those using 
C.
 >
 >	I understand this is technically possible.
 >But the issue isn't technical. My feeling is:
 >
 >	1. I think having a library of physics constants in
 >	   the Standard is a really good idea
 >
 >	2. I'm not at all sure the committee will buy anything
 >	   that isn't simple and obvious.
 >
 >In particular I think that 'ease of teaching' is probably the
 >critical requirement: the library should be designed for
 >first year physics students. Expert numerical analysts
 >are able to provide exactly what they want independently,
 >and probably will anyhow. If we can give them a certified
 >value of the largest possible precision, it leaves them
 >the task of fiddling with rounding/conversion issues,
 >which is their domain of expertise -- but relieves
 >them of the task of typing in the digits correctly.
 >
 >I think we could look to 'valarray' here: the committee knows
 >work is needed, and _no one_ is willing to claim enough expertise
 >to do the work.
 >
 >My fear is that a proposal that is too complicated is likely
 >to be rejected because it is too difficult to understand.
 >Bjarne has indicated that making the library _simpler_
 >as well as extending the things that can be done with it
 >is an important criterion when considering library
 >extension/change proposals.
 >
 >To put this another way: a physics constant library
 >is only useful to a small group: we'd like to provide
 >more support for that group, but not at the cost
 >of making the library a lot more complex.
 >
 >--
 >John (Max) Skaller, mailto:skaller_at_[hidden]
 >10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
 >checkout Vyper http://Vyper.sourceforge.net
 >download Interscript http://Interscript.sourceforge.net
 >
 >To unsubscribe, send email to: <mailto:boost-unsubscribe_at_[hidden]>
 >
 >
 >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/