TR1 Mathematical Special Functions
Is there anyone working on adding a boost-license compliant implementation of these to boost.TR1? I'm looking at the possibility of doing some work on this as part of a directed study. What is the status of the TR1 math special functions in regards to standardization, etc.? As I recall, there were problems in the TR1 specification as far as error boundaries go. Joel Eidsath
Joel Eidsath wrote:
What is the status of the TR1 math special functions in regards to standardization, etc.? As I recall, there were problems in the TR1 specification as far as error boundaries go.
Special math have been "standardized" as part of Libary TR1, which is now an official ISO standard - i.e. the work is finished bar processing the defect reports. For C++0x, all of TR1 has been adopted, with the exception of the special math functions. There was a major concern with cost of the feature outside the Library group. And note that cost goes beyond simply implementing the library - at least one vendor mentioned that if they were given an implementation free of charge they still could not afford it, due to increased testing/QA costs. -- AlisdairM
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of AlisdairM | Sent: 06 August 2006 08:02 | To: boost@lists.boost.org | Subject: Re: [boost] TR1 Mathematical Special Functions | | Joel Eidsath wrote: | | > What is the status of the TR1 math special functions in regards to | > standardization, etc.? As I recall, there were problems in the TR1 | > specification as far as error boundaries go. | | Special math have been "standardized" as part of Libary TR1, which is | now an official ISO standard - i.e. the work is finished bar | processing the defect reports. | | For C++0x, all of TR1 has been adopted, with the exception of the | special math functions. There was a major concern with cost of the | feature outside the Library group. And note that cost goes beyond | simply implementing the library - at least one vendor | mentioned that if | they were given an implementation free of charge they still could not | afford it, due to increased testing/QA costs. This says to me that the tail is wagging the dog! ISO 9000 allows a vendor to provide whatever testing he promises: so a vendor only needs to specify what parts are provided with his testing, and what are provided with the Boost tests. Users get great benefit from standards that simply say: "If you are going to do this, do it this way." The problem is an opinion by vendors that customers expect them to provide all the Library. IMO, they don't, or shouldn't. In any case, because of the way the standards are written, vendors can provide a conforming implementation by simply returning std::numeric_limits<>::quiet_NaN() for all functions! And finally, considering the record of somewhat casual compliance with the C++ Standard/Library by vendors, I consider this is a bit rich. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
On Tue, 8 Aug 2006 10:18:45 +0100, "Paul A Bristow" <pbristow@hetp.u-net.com> wrote:
| For C++0x, all of TR1 has been adopted, with the exception of the | special math functions. There was a major concern with cost of the | feature outside the Library group. And note that cost goes beyond | simply implementing the library - at least one vendor | mentioned that if | they were given an implementation free of charge they still could not | afford it, due to increased testing/QA costs.
This says to me that the tail is wagging the dog!
Frankly this surprised me too. First of all, none of the vendors which also supply a standard library (note: with this I'm deliberately excluding EDG) seem to care so much about quality as the above statement seem to imply; they do all sorts of silly errors, which go from macro-guarding <cassert>, to making numeric_limits<> members non-ICEs. And this is just 101; let us not speak about *serious errors* (of the kind which can make a perfectly conforming program crash under your eyes). A recent post in "[string_cvt] help with VC 7.1 is needed" should tell enough about the amount of testing many vendors put in their compilers (I wonder what they really do when they delay a release for one year or so). And, after all, why not going with a N1426bis ("Why we can't afford special math functions") which explains in depth why a whole company cannot do what 3 persons alone have done excellently, and for years? Sorry for being harsh, but it seems to me excluding something from the standard just because one vendor didn't want to face it is sacrificing the majority of users for the sake of a commercial minority. -- [ Gennaro Prota, C++ developer for hire ]
Gennaro Prota wrote:
Frankly this surprised me too. First of all, none of the vendors which also supply a standard library (note: with this I'm deliberately excluding EDG) seem to care so much about quality as the above statement seem to imply; they do all sorts of silly errors, which go from macro-guarding <cassert>, to making numeric_limits<> members non-ICEs. And this is just 101; let us not speak about *serious errors* (of the kind which can make a perfectly conforming program crash under your eyes). A recent post in "[string_cvt] help with VC 7.1 is needed" should tell enough about the amount of testing many vendors put in their compilers (I wonder what they really do when they delay a release for one year or so). And, after all, why not going with a N1426bis ("Why we can't afford special math functions") which explains in depth why a whole company cannot do what 3 persons alone have done excellently, and for years?
Sorry for being harsh, but it seems to me excluding something from the standard just because one vendor didn't want to face it is sacrificing the majority of users for the sake of a commercial minority.
Personally I think you are being very harsh to dismiss the level of testing that goes into shipping a major commercial compiler and library. Simply working with my own code I have to accept that no non-trivial codebase is going to be bug free. And I don't have to support legacy users relying on the bugs in my older implementations, which they expect me to support for years to come... The issue is raised exactly because commerical vendors are VERY aware of the cost of validating that kind of library, including finding someone with sufficient mathematical background to verify the tests themselves are valid! And note that QA is only one concern, among several vendors. I still would very much like to see the whole of TR1, including math functions, adopted in the next library. I believe most of the Library working group are quite satisfied with what has been delivered with TR1, and any vendor who has implemented it for the TR would really like to see that work pay off in the main standard as well. We are still several years away from a new standard though, and there is time for things to change. An effective Boost implementation that can be packaged for free would go a long way to lowering the barrier of adoption, but is by no means enough in itself. -- AlisdairM
On Tue, 8 Aug 2006 18:44:45 +0000 (UTC), "AlisdairM" <alisdair.meredith@uk.renaultf1.com> wrote:
Gennaro Prota wrote:
[...]
Personally I think you are being very harsh to dismiss the level of testing that goes into shipping a major commercial compiler and library.
Maybe they are tested. It remains that three persons alone have left all the rest in the dust, for standard compliance and quality of implementation (which includes an excellent *diagnostics* quality - and I restate excellent). As to the math functions I don't see the real issue. Anyone can still claim something like 97% or 98% conformance without implementing them; or can declare them "deprecated" ;-) But I may understand your diplomacy. I'm well know for not having it. <http://google.com/group/comp.lang.c++.moderated/browse_thread/thread/51c244afb36d9058/f374c17d9df8ad9b?#f374c17d9df8ad9b> It's my opinion that congratulations don't have much meaning if they come from someone who never criticizes. One has to be open to both of them, or none. -- [ Gennaro Prota, C++ developer for hire ]
Joel Eidsath wrote:
Is there anyone working on adding a boost-license compliant implementation of these to boost.TR1? I'm looking at the possibility of doing some work on this as part of a directed study.
Some work: I have a few special function here: http://www.johnmaddock.co.uk/toolkit which partly overlap with TR1, there is also a Google SOC project in this area - Xiaogang Zhang has been working on these, just Bessel functions so far, you can browse the source here: https://boost-consulting.com:8443/trac/soc/browser/boost/soc/2006/tr1-math/t... But any further developments would be welcome :-) John.
John Maddock <john <at> johnmaddock.co.uk> writes:
Joel Eidsath wrote:
Is there anyone working on adding a boost-license compliant implementation of these to boost.TR1? I'm looking at the possibility of doing some work on this as part of a directed study.
Some work: I have a few special function here: http://www.johnmaddock.co.uk/toolkit which partly overlap with TR1, there is also a Google SOC project in this area - Xiaogang Zhang has been working on these, just Bessel functions so far, you can browse the source here: https://boost-consulting.com:8443/trac/soc/browser/boost/soc 2006/tr1-math/trunk
But any further developments would be welcome
John.
Paris (U.E.), le 17/08/2006 Bonjour 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. 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. 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...). Merci Hubert Holin
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).
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.
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). Thanks for the comments, John.
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! Hubert Holin
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Hubert Holin | Sent: 17 August 2006 12:47 | To: boost@lists.boost.org | Subject: Re: [boost] TR1 Mathematical Special Functions | | John Maddock <john <at> johnmaddock.co.uk> writes: | | | > Joel Eidsath wrote: | > > Is there anyone working on adding a boost-license compliant | > > implementation of these to boost.TR1? I'm looking at the | possibility | > > of doing some work on this as part of a directed study. | | > Some work: I have a few special function here: | > http://www.johnmaddock.co.uk/toolkit which partly overlap | with TR1, there is | > also a Google SOC project in this area - Xiaogang Zhang | has been working on | > these, just Bessel functions so far, you can browse the | source here: | > https://boost-consulting.com:8443/trac/soc/browser/boost/soc | 2006/tr1-math/trunk | | > But any further developments would be welcome | | > John. You might also look at JohAn Rade recent contribution to portable isnan and signbit: http://boost-consulting.com/vault/ folder serialisation non_finite_num_facets.zip | 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. " Sadly the last update is "Last Modified Sat, Oct 22, 2005" | | 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. John Maddock and I have come this conclusion too and in implementing high math functions, and the statistics functions using them has effectively abandoned them in favour of a fully templated C++ structure, including making distributions like normal, student's t, binomial ... a C++ class. I believe it will still be possible to provide C support - with C-style named functions, but by packaging C++ to be linkable from C, rather than vice versa - effectively the TR1 rules. | Still, having no standard support for usefull functions is | worse than bad | support (that could be built upon), IMHO. | | So, whatever you can contribute will be most welcome. I | should point out that | some requests have been made to have interval computations John Maddock is itching to tackle these by using the interval library with his functions but we are trying to get the math and stats functions out for pre-veiw first. | (as opposed to | only pointwise computations), which AFAIK have still gone | completely unanswered, | but which do have practical applications; Strongly agree - we need to know the computational uncertainty - as well as the measurement uncertainty. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
On Thu, 17 Aug 2006 14:07:34 +0100, "Paul A Bristow" <pbristow@hetp.u-net.com> wrote:
You might also look at JohAn Rade recent contribution to portable isnan and signbit:
Portable? Well, yes, you can carry it around if you like. Perhaps on a USB drive. -- [ Gennaro Prota. C++ developer, Library designer. ] [ For Hire http://gennaro-prota.50webs.com/ ]
participants (6)
-
AlisdairM -
Gennaro Prota -
Hubert Holin -
Joel Eidsath -
John Maddock -
Paul A Bristow