Johan Råde wrote:
There is also an overlap with the Math Tool Kit library; both libraries provide implementations of fpclassify, isnan etc. (The two implementations use completely different approaches.)
My plan has been to have the library included in Boost as an addition to Boost.Math rather than as an independent library.
However, I'm very busy; the next year will probably decide whether my company becomes a success or a failure.
The very best of luck with that :-) Johan, I must apologise, I've been meaning to volunteer as review manager for this: if accepted the current Boost.Math implementation could be merged with this one (especially as the current Boost.Math implementation already has the pp-logic to use the platform's native implementation where available). IMO the only things stopping this being integrated into Boost.Math as is (given that it doesn't change the interface, only the back end implementation) are: 1) A good eyeball once-over by interested parties, to spot potential issues: since the library uses non-portable casts etc this is quite important IMO. 2) The knowledge to know when to use this implementation, and when/where it might fail. So.... I'd also ask you to keep up the review request - if no showstoppers turn up, then it can just be integrated into Boost.Math more or less as is - hopefully without too much work for yourself or Paul and me. If there are any changes required then we'll have to figure out what to do about them: possibly just restrict the platforms/compilers where your implementation is used. So hopefully, your involvement could be restricted to answering queries about the implementation during the review: is that possible given your current schedule? Best regards, John Maddock.