Re: Math Functions

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2001-09-10 13:35:36

Dr. Paul Bristow wrote:

>> I think you are missing the forest for the trees ...

> I fear creating a forest for the users to get lost in!

I certainly agree with you there!  Any interface that makes it too hard
for the average user is, in my opinion, one of those bad interfaces I
don't want to see.  But a good interface (as opposed to an argument list
of (double, double, double, int, double*) ) can make it much EASIER to
learn the use of a library.

> If you look at how the vast majority of people will use these
> functions, double is what is needed.

I agree that this is how the majority of people will use these now and
in the near future.  However, I certainly hope that the future will see
this change!  The results of most numerical/scientific computation can
only substantially improve, IMNSHO, if we users move AWAY from these
error prone methods, to heavier use of unit/dimension libraries,
interval types, and similar techniques.  I'm certainly as guilty of not
using many of the available techniques to reduce errors in my own code,
mostly because there is no "known-good" infrastructure of code built up
to support this paradigm.  Currently, you have two choices: use doubles
or design, code, and debug this entire mythical infrastructure.  I
certainly know which I continue to choose!  That's why I'm hoping that
boost can develop libraries that are easy to use and provide rapid
return on learning time, improving the state of the art.

> Bear in mind that the 'state-of-the-art' algorithms for the incomplete beta,
> for example, by Didinato and Morris struggle to give 14 decimal digits,
> so a long double accuracy is going to be some way off

I certainly don't disagree; I'm not in fact at all concerned with
providing long double versions of anything.  I don't think I've written
code for a research project where I wanted more than two or three deimal
digits at the end of the day (I'm a particle theorist, so I'm luck when
I have DATA to compare my results to!)  I'm more concerned with things
like interval and unit types and similar things; I don't really ever see
a need for me to use a long double in any computation I can see doing!

> Float would suffice for most,
> but the work in producing two versions for float and double is
> massive and in my view not worth it compared to 'floating' the double.

And I don't disagree, but there are others who might have the need. 
There is nothing obligating anyone to provide a particular
implementation, and if a user needs one that isn't available, then they
can provide it.  But if there is a general interface to plug that
implementation into, then everyone else can immediately benefit from the
work that person does implementing the version they need.  If there is
nothing lost in a more general, templatized interface that can expand to
serve more users, I don't see a good reason NOT to provide that
interface, if we can find it.   

I'm not suggesting that you should feel obligated to provide an
implementation that matches some whiz-bang interface that we come up
with.  And I certainly don't intend to demean any contribution of code
that anyone wants to make to boost; it would certainly be more code than
I've contributed  :-)   Any math code that is contributed to boost is
wonderful, and could relatively easily be used as an implementation
detail of any developed interface.

I just saw the opportunity for interested parties to spend some effort
developing the interface that I've been hoping for and which isn't
available anywhere: a simple, powerful, extensible mathematical function
interface that facilitates the implementation of fairly general
algorithms.  This currently does not exist in any form that I've seen. 
In essence, numerical C++ (with some small exceptions like blitz and
mtl) is still stuck in the FORTRAN IV days in terms of ease of use and
power.  (And without the primitive array types and parallel processing
primitives, well behind the state of the art in Fortran 90!)  I hope we
can do something to help change that.

> So I am as yet unconvinced at the importance of the the 'interface'
> beyond defining things as, for example,

> double function(double);

Well, I hope I've made it clear that I DO see the importance, and hope
that we can help move the state of the art beyond where it stands.

> The algorithms are the hard bit, I believe.

Certainly DERIVING the algorithms is very hard; I'm certainly not
qualified to be of much assistance in this area.  But I think that
implementation of an existing algorithm, even if time consuming and
error prone, should be classified as "trivial" compared to derivation of
the result or of designing a robust, extensible interface to that
algorithm.  Which again, is not intended to imply that implementation
isn't an important step;  it's just not the fun part  :-)  This is also
not to say that the chosen implementation isn't important!  A good
interface with a terrible implementation will see less use than a good
implementation with a terrible interface.  I just don't know of a
fundamental stumbling block to providing both.

-- 
-------------------------------------------------------------------------------
Kevin Lynch				voice:	 [phone]
Physics Department			Fax: [phone]
Boston University			office:	 PRB-565
590 Commonwealth Ave.			e-mail:	 krlynch_at_[hidden]
Boston, MA 02215 USA			http://physics.bu.edu/~krlynch
-------------------------------------------------------------------------------