From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2006-08-17 08:35:56
John Maddock <john <at> johnmaddock.co.uk> writes:
> Hubert Holin wrote:
> > In theory, the DLMF project should come to fruition this year
> > (http://dlmf.nist.gov/about/), which can only help both in terms
> > of techniques to use and, one can dream, in interest in the subject.
> I think everyone has been waiting for that to come to completion for so
> long, it's hard to know whether there has been any progress or not (the web
> pages don't appear to have changed for years, based on a casual glance).
I share the feeling... I see that the page I point to has last been changed
Oct 22, 2005, which is not *that* long ago for a project of this scope,
bust still, any new news would be welcome... Especialy so as there are
no new activities reported about the project, and no ongoing seminar.
> > As far as the TR1 stands, I still feel the lack of genericity
> > enshrined by
> > the C-style naming conventions of the special functions is a glaring
> > error. Still, having no standard support for usefull functions is
> > worse than bad support (that could be built upon), IMHO.
> If you have any comment on the interfaces we're working on here
> http://www.johnmaddock.co.uk/toolkit then feedback would be most welcome.
I'll take a closer look, but they seem to be exactly what I believe is needed.
A minor point, that I noticed so far: I believe it would be preferable if
"boost::math::isnan(z);" did not cause a compiler error if isnan is a native
macro but that "isnan(z);" did (the reasoning being that "more qualification
should be safer").
> > So, whatever you can contribute will be most welcome. I should point
> > out that some requests have been made to have interval computations
> > (as opposed to
> > only pointwise computations), which AFAIK have still gone completely
> > unanswered, but which do have practical applications; perhaps this
> > would be a good place
> > to contribute (among so many...).
> Paul Bristow has been pushing me towards Boost.Interval support as well.
> It's really a question of time etc (as always).
Yes, time is always in so short supply! In this case, in addition,
I am not aware of a good reference upon which to build an
implementation, as there are problems which do not appear
with pointwise computing (discontinuities of both types...).
> Thanks for the comments, John.
You are welcome!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk