Re: RFC: "new_math.zip" 2

From: Daryle Walker (darylew_at_[hidden])
Date: 2001-08-26 00:21:24

on 8/24/01 11:27 AM, Hubert HOLIN at Hubert.Holin_at_[hidden] wrote:

> --- In boost_at_y..., darylew_at_m... wrote:
>> It's at:
>> 
>> http://groups.yahoo.com/group/boost/files/new_math.zip
>> 
>> It does:
>> 
>> 1. Adds a forwarding header to the math sublibrary
> 
> I see this a yet one more maintenance hazard. It lessens
> modularity ("I only need sinc, I don't care about atanh..."
> situations). It also can not (should not) replace the actual
> documentation. I fail to see what it gains us. I am not in favor of it.

Forwarding headers have been mentioned before; I read of some people wishing
that the I/O sub-library wasn't the only part of the Standard library to
have a forwarding header, <iosfwd>.  It lets a user reference the name of a
class without needing the full definition, or the multitude of headers that
definition needs to #include.  Granted, you can only use a type name for
pointers or for function and/or template declarations, but that may be just
all one needs.  That forwarding ability came in handy for this header, as it
could use the <iosfwd> header to get the names of the stream types, for
declaring the I/O operators, without getting all the locale stuff, etc.

I want the granularity of forwarding headers to be at the level of the top
sub-libraries, so we don't get a lot of little forwarding headers.  The
original person who suggested the idea only wanted (template) class/struct
forward declarations.  I added the idea of forwards for function
(templates).  Maybe we can reduce it to just classes.

>> 2. Adds a main documentation directory and index.html
> 
> I am neutral about this one. It would have to work with the
> roster one-liner page, though...

What page is that?  Is it "BOOST_ROOT/libs/libraries.htm"?  As Boost gets
larger and does more sub-library dividing, we would probably have to change
the structure of the page.

>> 3. Since I couldn't compile sinc.hpp and sinhc.hpp as is,
>> I converted them to the function-calling-a-functor model.
>> (Hopefully partial specialization of class templates is more
>> widespread than template-based template parameters
>> for function templates.)
> 
> The technique used has merit, but lead IMHO unecessary code
> duplication and lessening of modularity. As I understand, this is a
> work-around for a compiler deficiency. What I would rater do, as I do
> not forsee that use of sinc on octonions to be in *such* great demand
> ;-) , is conditionalize the test to exclude it for that particular
> version of the compiler. At any rate, that's what I am doing (among
> other things) for Gcc and the Comeau in the update I am working on at
> the moment.

We would have to add a new <boost/config.hpp> macro.  The block would have
to go in the sinc header and the math forwarding header.  How many compilers
can handle template-based template parameters, considering how many
compilers have quirks in how they implement (or not) the more common
template features?

I've also mentioned that the function-calling-a-functor model is more
flexible.  I think a lot of people feel that class template (partial)
specialization is more stable than function template (or function)
overloads.  The FCAF model doesn't need Koeing lookup, which may be a good
or bad thing, depending on your opinion.  (Look about discussions about
using and extending swap.)

Right now, both options will work the same for:
    float, double, long double
    complex, quaternion, octonion of the above types
    complex, quaternion, octonion of any other base type

The question is what happens to types not in the above.  In the current
model, any type that looks like a template with only a type-based template
parameter gets treated like a complex, and all other template types and
regular types get treated like reals.  In model I introduced, all types not
(partially) specialized get treated like the reals.  I think my model is a
safer default.

I also isolated the real and complex routines to detail function templates
that specializations of the function objects can call.

(By the way, you should copy the check I did of std::numeric_limits being
specialized before using any of the other members.)

>> 4. Adjusted docs for special functions to match
>> (and rediscovered why I don't like HTML editors).
>> 5. Fixed up the quaternion-rotation example
> 
> I did not find the fixed file. What was the problem?

It still referred to quaternion & friends being in the boost namespace,
instead of boost::math.

>> It differs from version 1 in that it's made after the Boost 1.24.0
>> release.
>> 
>> I still have to fix up the HTML some more.
>> 
>> Questions:
>> 
>> 1. Does it work at least for the platforms previous versions did?
>> 2. Does it work for new configurations (besides mine)?
>> 3. Should these changes be incorporated?
> 
> I believe these changes should not be incorporated.

> Thanks for the comments

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com