Subject: Re: [boost] Is there interest in e_float: Multiple-precision floatand special functions?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2011-06-10 05:27:22
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of
> Sent: Thursday, June 09, 2011 10:04 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Is there interest in e_float: Multiple-precision floatand special functions?
> I believe that we cleared up the license issues in recent private mails.
> Did we adequately clear up the license issues?
*I* believe you have done all that is necessary on the license issue.
(But I think Boost should make sure it stores the documents you provided somewhere safe for the long
term - in case there is any question in a few years' time. I'm not sure where this should be?)
> In order to get the e_float core in the sandbox, we need to define how much we would initially
like to have
> in the core.
> I might suggest:
> - The real data type e_float, its base class and its interfaces to the big-number back ends.
> - The specialization of std::numeric_limits<e_float>.
> - The complex data type (ef_complex)
> - Elementary transcendental functions (trig, power, log hyperbolic) for real and complex.
> - (optional) Possibly the Gamma function and Zeta functions for real and complex.
> This selection would limit the initial size of the e_float core in the sandbox to a few tens of
files and no big
> Would this initial selection be appropriate?
Sounds good to me.
We already have gamma and zeta functions in Boost.Math and these should 'just work' with e_float,
but it may be interesting to compare.
I, and others I am sure, will be willing to help with getting some testing using the idiosyncratic
but effective Boost.Test, and also build using the bizarre but effective bjam build system. (This
will help (future) testing on all the Boost platforms - dealing with their whims and wishes proved
quite hard and tedious work with Boost.Math).
Documentation production using the Quickbook toolchain is even more convoluted, but the final
results are excellent, but don't start on this without seeking help.
Effective documentation is thin, so drawing on the knowledge base of the cognoscenti will save you
hair loss ;-)
PS You need write access to the sandbox of course. Hopefully moderator John Maddock will enable
this for you?
--- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk