[boost] Re: [Ann] Proposed Boost.TR1 library: firstcompleteversion now available.

From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2005-04-15 06:35:14

Somewhere in the E.U., le 15/04/2005

   Bonjour

In article <020701c540e4$ef150320$17120952_at_fuji>,
 "John Maddock" <john_at_[hidden]> wrote:

> >> I also need to sort out with Hubert Holin, what I'm going to do with the 
> >> new
> >> complex number code (add it to his special functions library, or 
> >> something
> >> else).
> >
> >      I believe integration is the simplest route. How would you want to
> > proceed?
> >
> >      I can update the code documentation fairly rapidly, but the
> > "background" (mathematical) part may take some time, especially if I try
> > to produce explanatory figures. At any rate, if we are to feature-freeze
> > in 48 hours, the former may just be possible but certainly not the later.
> > I believe text explaining that some of the functions in the "Special
> > Functions" library are actually part of the TR1 should not prove to be
> > too confusing, and relevant passages of the TR1 could perhaps point to
> > the "Special Functions" library documentation for additional information
> > (not instead of the information you already provide).
> 
> Yes, the idea is that the TR1 docs just point to the relevent Boost docs. 
> I'm not sure how much theoretical background is needed for these, I like 
> your graphs for the real number versions very much, but I've never seen 
> complex number graphs that really work well for me: the mathworld site makes 
> a brave attempt to illustrate these, but IMO it doesn't convey that much 
> information to me.

      OK, I'll try to see if I can come up with something more inspiring 
:-)  .

> >      The body of code you produced is far greater (in more ways than
> > one ;-)  ) than what I have done, so perhaps it would be simpler if you
> > merged my code into yours rather than the other way around. One sticking
> > point perhaps would be that of the namespace these things live in, as I
> > believe my implementations should be moved to ::std::tr1 as well, as per
> > 8.16.4 of the TR1, and this raises the possibility of name conflicts.
> > The sinus cardinal and hyperbolic sinus cardinal should preferably stay
> > in ::boost::math, as they have not been introduced into the TR1, and
> > quaternions and octonions depend upon them (though I could update that
> > as well, of course). If I get around to adding valarray support for some
> > of these functions, they would live in ::boost::math as well.
> 
> I think it should all be in boost::math, and then pulled into std::tr1 with 
> using declarations (like the rest of the proposed TR1 implementation), and I 
> don't think we can refactor all this in time for the 1.33 release if it

      Yes, we should assume the release will be on schedule, so time is 
too short.

> sticks to schedule.  So... right now I've got some existing docs to update 
> in time for 1.33, how about I prepare a patch for the match lib after that 
> and we can take it from there?

      Sounds fine with me. In the mean time, I'll also try to deal with 
the "long double" deficiency already identified that some platforms 
suffer from, though that only affects the tests, not the library proper 
(I don't know if that will make it for 1.33).

> Regards,
> 
> John.

   Merci

         Hubert