This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: FW: Special functions in TR1
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: Theodore dot Papadopoulo at sophia dot inria dot fr
- Cc: Edward dot SmithRowland dot ctr at jsc dot mil, wb at fnal dot gov, libstdc++ at gcc dot gnu dot org
- Date: Wed, 7 Dec 2005 11:46:58 -0600
- Subject: Re: FW: Special functions in TR1
- References: <458D5B19F9E9AC4782761A24CF571F22016CB377@emsanp2.disanet.disa-u.mil> <1133377762.4792.189.camel@mururoa>
I would encourage you to work on this, or at least explore options and report back.
Another person who has expressed interest in the FSF implemenation of
special functions is Walter Brown. I've cc'd him. Walter, do you have
an update or any thoughts about this?
He might have some opinions about the GSL/libstdc++ integration, which
he expressed intrest in some time ago.
-benjamin
> > 6. The GSL methods and variables should probably not be in the global
> > namespace - we would want to put them into a namespace that wouldn't collide
> > or be visible: std::tr1::__gsl?
>
> > Is anyone else thinking about this?
>
> Well, I gave some thought on this a few months ago. I even implemented
> the simple algorithms for some of the functions (but these certainly
> have some numerical problems for some of the inputs). Then, I had a look
> at gsl's implementations....
>
> Personnaly, I would find much more interesting to re-write (and
> simplify) the gsl routines and take advantage of C++, instead of
> importing them. Typically, templates can be used to commonize most of
> the float/double/... paths and exceptions (I do not remember if TR1
> allows them but it should) are a much nicer way to signal problems
> instead of error codes.
>
> That being said I do not have advanced much further than that....
> But if we have similar ideas, maybe I can help...