This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: TR1 Math


> My assignment is in place.  I am in the middle of making corrections as 
> suggested by you and Paolo.

Sorry for the confusion. Paolo has confirmed that you are ready to go.
Just trying to make sure everything is ok....

> > Also, what is the plan WRT GSL? Is there a plan for cooperation, or is
> > this just going to be a separate code base? Insights appreciated.
> >   
> The GSL is a great piece of work and I am looking at it as I go.  The 
> GSL is in C and only supports double precision.  I chose to use template 
> functions to support the three floating point types that TR1 calls for.  
> I like the idea of having a single generic algorithm.  With this 
> decision I think there will be just to many differences to support any 
> real immediate sharing.  Maybe as I add attributions to the commentary I 
> could note corresponding functions in GSL as appropriate.  I think I'll 
> do this.

Ok. This sounds reasonable to me. Thanks for the explanation.

> OTOH perhaps if the GSL folks want to make three versions of everything 
> we could import the relevant part of the GSL library in a scheme much 
> like libgcc-math and our functions would call these.  Obviously this is 
> a ways off because I've seen no such movement in GSL.  It might however 
> be the long term best structure if, as I've heard suggested, the C 
> standard follows C++ and adds these functions to its library.

Yep. There is on-again, off-again talk with Walter Brown about this
approach. However, no movement.  So, since you've got something, let's
start there, and if in the future things grow together, we'll
re-evaluate.

> > Can you elaborate?
> >   
> I'm hoping to build a test application or set of applications that will 
> compare the results of TR1 versus GSL.
> These would do a lot of spot checking of these functions and could also 
> be used for timing trials.  This could be one way that GSL and TR1 could 
> share work.  If a discrepancy is observed we could sort it out and pass 
> the info on.  To be honest though, I expect GSL to correct *me* rather 
> than the other way around most of the time ;-).

Got it, thanks. This sounds like an excellent way to proceed to me. It
looks like you can break the tests down into regression and performance
type tests, which follow a similar breakdown in te existing libstdc++
testing strategy.

It does seem as if you are paying attention to GSL,
which is what I was wondering.

-benamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]