Boost logo

Boost :

From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2006-08-17 08:35:56

John Maddock <john <at>> writes:

> Hubert Holin wrote:
> > In theory, the DLMF project should come to fruition this year
> > (, 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
> 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!

Hubert Holin

Boost list run by bdawes at, gregod at, cpdaniel at, john at