RE: [boost] Re: Math Functions: Basic building blocks...

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-09-27 17:24:10

Hi Eric,

I've just reviewed standard_functions.hpp:

First:
~~~

I'm not sure if it is a good idea to leave the default implementations
empty.

If I want to use a given UDNT (user defined number type), then the first
thing I have to do is to specialize all those traits and functions for which
I can give a meaningful specialization.
Now, suppose that my BigFloat doesn't support, say, 'cos()'; but I need to
use it in some algorithm and I get the compiler error that cos() isn't
specialized for BigFloat.
I have two choices: forget about using BigFloat or write myself (the
BigFloat user, not the BigFloat implementer) the specialization.
However, I think that chances are that most of the times I will end up
writting my own specialization, becuase it is unlikely that I can forget
about BigFloat for this job (or I wouldn't have chosen it in the fist place)

Now, how would I write such a specialization?
I haven't wrote it when I set up everything to work with BigFloat, so most
likely I will just write a code that converts BigFloat to some native fp
type, for instance 'double', and then back to BigFloat.

Thus, I think that all the functions should have a default implementation
that converts to double and from there back to the proper type.

This is the approach I've taken in 'generic_math.h', and it proved useful in
my experience (I've been working with UDNTs for a couple of years now)

Second:
~~~~~~

I think that the functions should take "T const&" instead of "T const".
For a built-in type, pass by value is OK, but this is targeted to arbitrary
types, not just built ins.

Third:
~~~~

In:

template<>  TYPE FUNC< TYPE >(const TYPE x) \
  { return boost::numeric_cast<TYPE>(::std::STDFUNC(x));  };

The numeric_cast<> here is unnecesary.
STDFUNC is passed to the macro such that it has the signature TYPE
(*f)(TYPE);
If it didn't, then another conversion would be required from TYPE to the
function argument.

Everything else seems good to me.

Regards,

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com