Re: Review Request: Special functions, Quaternions, Octonions

From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 2001-04-16 09:33:54

Paris (U.E.), le 16/04/2001

        Hi

--- In boost_at_y..., Daryle Walker <darylew_at_m...> wrote:
> on 4/10/01 8:58 PM, Hubert HOLIN at Hubert.Holin_at_B... wrote:
> 
> > I would like to request a review of the following three
> > libraries:
> > 
> > 1) Special functions
> > 
> > 2) Quaternions
> > 
> > 3) Octonions
> > 
> > There is a simple (and necessary) dependency between the
> > three: "Octonions" depends upon "Quaternions" which in turn depends
> > upon "Special functions".
> > 
> > To the best of my knowledge, I have striven to abide by the
> > guidelines but one: limitation to 80 columns proved to be too
> > impractical, for all files except the tests.
> 
> I can think of ways to compact your code.  I want to test my ideas out
> first, though.

                Any suggestion welcome...

> > The libraries work correctly with Metrowerk's CodeWarrior
> > compiler, MacOs version, and so should also work with their Wintel
> > stuff. It is anticipated that it should work also with the Comeau
> > compiler. There might be some problems with gcc (locale deficiency, or
> > missing overloads for abs and sin & co), and I would welcome
> > suggestions as to how to get around them (I do not currently have
> > access to that compiler). I could not care less, however, about what
> > M$VC++ might have to say about these libraries...
> > 
> > These libraries have independent (though cross-referenced)
> > documentation and are implemented thru three separate files (each a
> > single header). They are currently packaged as the file
> > "spefquatocto_sc1.tgz", which resides in the Vault.
> 
> I like math stuff, so I tried these out on my CodeWarrior compiler on the
> Mac OS.  I think you have version 6(.1), while I'm using 5.3, because
> there's some code I can't handle.

                This is correct.

> In "special_functions.hpp", I got unimplemented feature and internal
> compiler errors when processing the second versions of sinc_pi and sinhc_pi.
> With the problems various compilers have with templates, I don't think it's
> a good idea to depend on the rarest template feature, template-based
> template parameters.  That code also has the problem of possibly be
> inappropriate for some types; it's OK for your quaternion and octonion
> template classes, but what about stuff like rational, which would also

                I believe these functions are mostly meaningless for 
rationals. They should be meaningfull for quaternions built upon fixed 
point classes however, though this has not been tested (for lack of 
contributed fixed point classes (I could perhaps contribute one btw)).

> match.  I think something like my workaround, special versions of those
> functions, could be better.

                I believe ensuring compilers are compliant is a better (if 
more costly) strategy.

> In "quaternion.hpp", you needed the actual definition of
> basic_ostringstream, which needed a <sstream> #include.  As I said above, I

                I'll investigate this tomorow, but this did not turn up in my 
test. This might be a deficiency of the 5.3 compiler (or the correct 
hearder got included idependently in my tests...).

> added specialized version of sinc_pi and sinhc_pi.  The "octonion.hpp"
> header needed those same solutions.
> 
> In "quaternion_test.cpp" and "octonion_test.cpp", I corrected the explicit
> instantiation to lines like:
> 
> //=========================================================================
> /*template*/    class ::boost::quaternion<int>;
> 
> /*template*/    class ::boost::octonion<int>;
> //=========================================================================

                This does not mean the same thing! I want to explicitely 
instanciate, and you declare a specialisation (with, perhaps, a syntax 
error, as I believe in this case "class ::boost::quaternion<int>" 
should be prefixed by "template<> ").

> I don't know if this is right, but the compiler doesn't complain because the
> instantiation is never used.

                This is perfectly normal.

> The test runs came out OK; there was no difference between your supplied
> output results and the ones I got.
> 
> -- 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com

                        Hubert Holin
                        Hubert.Holin_at_[hidden]