Is there interest in e_float: Multiple-precision float and special functions?
Is there interest in my e_float library for potential inclusion in boost? e_float is a portable C++ system for multiple-precision floating-point calculations and calculations of special functions. The e_float library supports 30 to 300 decimal digits of precision. It has an extendable architecture featuring a uniform C++ mathematical layer which can be used with any suitably prepared big-number back end such as GMP, MPFR, etc. The e_float system implements many high precision special functions and extends some of these to very large parameter ranges not available from other systems. Interoperability with Microsoft's CLR, Python (via Boost.Python) and Mathematica are supported. The e_float library is well-tested and has high performance. Further details can be found in my original work published in the ACM: Christopher Kormanyos, "Algorithm 910: A Portable C++ Multiple-Precision System for Special-Function Calculations", ACM Trans. Math. Soft. 37, 4, 2010, article 45. http://portal.acm.org/citation.cfm?id=1916469 e_float is potentially suited for boost because: * It provides a uniform, standardization-capable interface to multiple precision mathematics. * It has a sound mathematical foundation (published in the ACM). * It has been programmed from the ground up using modern C++ programming idioms. * It uses a layered architecture that hosts any number of big-number back ends. * It is highly portable, robust and durable. * It has a broad test suite developed in conjunction with code coverage analyses. * It is extendable. Additional functions, parameter ranges and test cases can be added. * It provides interfaces to very high level languages. Thank you for your feedback. Sincerely, Chris.
On Wed, 2011-06-01 at 21:34 +0100, Christopher Kormanyos wrote:
Further details can be found in my original work published in the ACM: Christopher Kormanyos, "Algorithm 910: A Portable C++ Multiple-Precision System for Special-Function Calculations", ACM Trans. Math. Soft. 37, 4, 2010, article 45.
Is there any way for you to get your code up on a public repo such as github or sourceforge?
Further details can be found in my original work published in the ACM: Christopher Kormanyos, "Algorithm 910: A Portable C++ Multiple-Precision System for Special-Function Calculations", ACM Trans. Math. Soft. 37, 4, 2010, article 45.
Is there any way for you to get your code up on a public repo such as github or sourceforge?
It's also at this page: http://calgo.acm.org/ Direct download link is http://calgo.acm.org/910.zip HTH, John.
The ACM version of the code is available at CALGO (the ACM Collected Algorithms page). The ACM version is called algorithm 910, in "910.zip" at CALGO. CALGO: http://calgo.acm.org/ ACM version of e_float: http://calgo.acm.org/910.zip John also just provided the link. Regards, Chris. ________________________________ From: Erik Erlandson <eerlands@redhat.com> To: boost@lists.boost.org Sent: Wednesday, June 1, 2011 11:55 PM Subject: Re: [boost] Is there interest in e_float: Multiple-precision float and special functions? On Wed, 2011-06-01 at 21:34 +0100, Christopher Kormanyos wrote:
Further details can be found in my original work published in the ACM: Christopher Kormanyos, "Algorithm 910: A Portable C++ Multiple-Precision System for Special-Function Calculations", ACM Trans. Math. Soft. 37, 4, 2010, article 45.
Is there any way for you to get your code up on a public repo such as github or sourceforge? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 6/1/2011 4:34 PM, Christopher Kormanyos wrote:
Is there interest in my e_float library for potential inclusion in boost?
e_float is a portable C++ system for multiple-precision floating-point calculations and calculations of special functions.
What is multiple precision floating point and how does this differ from float, double, or long double ?
The e_float library supports 30 to 300 decimal digits of precision. It has an extendable architecture featuring a uniform C++ mathematical layer which can be used with any suitably prepared big-number back end such as GMP, MPFR, etc. The e_float system implements many high precision special functions and extends some of these to very large parameter ranges not available from other systems. Interoperability with Microsoft's CLR, Python (via Boost.Python) and Mathematica
are supported. The e_float library is well-tested and has high performance.
Further details can be found in my original work published in the ACM: Christopher Kormanyos, "Algorithm 910: A Portable C++ Multiple-Precision System for Special-Function Calculations", ACM Trans. Math. Soft. 37, 4, 2010, article 45.
This does not help anybody since it is inaccessible.
http://portal.acm.org/citation.cfm?id=1916469
e_float is potentially suited for boost because:
* It provides a uniform, standardization-capable interface to multiple precision mathematics. * It has a sound mathematical foundation (published in the ACM). * It has been programmed from the ground up using modern C++ programming idioms. * It uses a layered architecture that hosts any number of big-number back ends. * It is highly portable, robust and durable. * It has a broad test suite developed in conjunction with code coverage analyses. * It is extendable. Additional functions, parameter ranges and test cases can be added. * It provides interfaces to very high level languages.
Your library sounds interesting but perhaps you can explain it in relation to what C++ already has as far as floating point support.
Is there interest in my e_float library for potential inclusion in boost?
e_float is a portable C++ system for multiple-precision floating-point calculations and calculations of special functions.
What is multiple precision floating point and how does this differ from float, double, or long double ?
From memory I believe there are two key differences:
1) It performs calculations in base 10 not base 2 2) It performs calculations at 100 decimal digit precision and with a greatly expanded exponent range compared to say [long] double. There is tentative support for use of e_float in current Boost.Math trunk (via boost/math/bindings/e_float.hpp), which actually proved to be a very useful test of our code as this is the first time it's been exposed to a real-number type that's quite so obviously base 10 as this one. Some more general comments: * It obviously would need quite a lot of "Boostification" before becoming a formal submission. * There are some (mostly interface) design choices that our perhaps questionable, but which no doubt can be worked out. * There *may* be a license issue, as ACM claim copyright over all submissions to their journal (including code). I gather that ACM may be amenable to derivative works being published under a different / more liberal license, but that would have to be worked out formally at some point I guess. HTH, John.
Multiple-precision is precision larger than that available with float, double, long double, etc. A floating point representation has about 7 decimal digits of precision, double-precision has about 15. GCC's new __float128 has up to 34 decimal digits of precision. That sounds like a lot. But even still, many applications in science and engineering such as geology or compiler verification require even more digits such as 50, hundreds, thousands or even more. Multiple-precision provides this added precision. There are several multiple-precision packages already available such as GMP, MPFR, MPIR, etc. My e_float library is unique because it uses strong C++ semantics and style while maintaining a high level of C++ portability. I also offer a wide selection of special functions. You can get the ACM version of the code here: http://calgo.acm.org/ Or use this direct link: http://calgo.acm.org/910.zip The code in the link has PDF documentation. The ACM version of the code is free. However, the ACM article is not free. I need to go to a library to get my own article. Any good university library will have subscriptions to all ACM publications. Regards, Chris. ________________________________ From: Edward Diener <eldiener@tropicsoft.com> To: boost@lists.boost.org Sent: Thursday, June 2, 2011 12:06 AM Subject: Re: [boost] Is there interest in e_float: Multiple-precision float and special functions? On 6/1/2011 4:34 PM, Christopher Kormanyos wrote:
Is there interest in my e_float library for potential inclusion in boost?
e_float is a portable C++ system for multiple-precision floating-point calculations and calculations of special functions.
What is multiple precision floating point and how does this differ from float, double, or long double ?
The e_float library supports 30 to 300 decimal digits of precision. It has an extendable architecture featuring a uniform C++ mathematical layer which can be used with any suitably prepared big-number back end such as GMP, MPFR, etc. The e_float system implements many high precision special functions and extends some of these to very large parameter ranges not available from other systems. Interoperability with Microsoft's CLR, Python (via Boost.Python) and Mathematica
are supported. The e_float library is well-tested and has high performance.
Further details can be found in my original work published in the ACM: Christopher Kormanyos, "Algorithm 910: A Portable C++ Multiple-Precision System for Special-Function Calculations", ACM Trans. Math. Soft. 37, 4, 2010, article 45.
This does not help anybody since it is inaccessible.
http://portal.acm.org/citation.cfm?id=1916469
e_float is potentially suited for boost because:
* It provides a uniform, standardization-capable interface to multiple precision mathematics. * It has a sound mathematical foundation (published in the ACM). * It has been programmed from the ground up using modern C++ programming idioms. * It uses a layered architecture that hosts any number of big-number back ends. * It is highly portable, robust and durable. * It has a broad test suite developed in conjunction with code coverage analyses. * It is extendable. Additional functions, parameter ranges and test cases can be added. * It provides interfaces to very high level languages.
Your library sounds interesting but perhaps you can explain it in relation to what C++ already has as far as floating point support. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Den 01-06-2011 22:34, Christopher Kormanyos skrev:
Is there interest in my e_float library for potential inclusion in boost?
e_float is a portable C++ system for multiple-precision floating-point calculations and calculations of special functions.
I'm mostly interested in the first part. I would be a hande tool to verify the precision of various internal computations in probabilistic models. So, yes, there is interest. -Thorsten
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Christopher Kormanyos Sent: Wednesday, June 01, 2011 9:34 PM To: boost@lists.boost.org Subject: [boost] Is there interest in e_float: Multiple-precision float and special functions?
Is there interest in my e_float library for potential inclusion in boost?
e_float is a portable C++ system for multiple-precision floating-point calculations and calculations of special functions. The e_float library supports 30 to 300 decimal digits of precision. It has an extendable architecture featuring a uniform C++ mathematical layer which can be used with any suitably
prepared big-
number back end such as GMP, MPFR, etc. The e_float system implements many high precision special functions and extends some of these to very large parameter ranges not available from other systems. Interoperability with Microsoft's CLR, Python (via Boost.Python) and Mathematica
are supported. The e_float library is well-tested and has high performance.
Further details can be found in my original work published in the ACM: Christopher Kormanyos, "Algorithm 910: A Portable C++ Multiple-Precision System for Special-Function Calculations", ACM Trans. Math. Soft. 37, 4, 2010, article 45.
http://portal.acm.org/citation.cfm?id=1916469
e_float is potentially suited for boost because:
* It provides a uniform, standardization-capable interface to multiple precision mathematics. * It has a sound mathematical foundation (published in the ACM). * It has been programmed from the ground up using modern C++ programming idioms. * It uses a layered architecture that hosts any number of big-number back ends. * It is highly portable, robust and durable. * It has a broad test suite developed in conjunction with code coverage analyses. * It is extendable. Additional functions, parameter ranges and test cases can be added. * It provides interfaces to very high level languages.
This looks a most impressive body of work. More important for Boosters, it may offer a Boost-compatible floating-point package in a way that allows a smooth transition from the C++ built-in float-point types up to arbitrary (but not infinite or exact) precision. Although built-in types are fine of most applications, when you need a higher precision, you need it badly - and I think Boost really, really needs this as part of its toolkit. As John Maddock has noted, there are some potential license issues, but I am confident these can be overcome. (All other similar packages have Boost-unfriendly license conditions - sadly). It comes with an extensive set of tests. (But it might be nice of these used Boost.Test - this would help Boost's routine multiplatform testing). To move forward, I would welcome the core e_float (with addition of reference to Boost license terms in the program text - as normal Boost practice) to be put into the Boost Sandbox. This will allow us to have something concrete to try out and make more informed comments on exactly what Boostification we feel is desirable. (It will also allow us to get a definitive license statement of agreement from ACM before we get too far in. ). Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
To move forward, I would welcome the core e_float (with addition of reference to Boost license terms in the program text - as normal Boost practice) to be put into the Boost Sandbox. This will allow us to have something concrete to try out and make more informed comments on exactly what Boostification we feel is desirable. (It will also allow us to get a definitive license statement of agreement from ACM before we get too far in. ).
Just to be clear, we would need to sort out the license definitively *before* any code went into the sandbox SVN. Pedantically yours, John.
Thank you, John. Present state: * I have already modified my codes to include boost licensing and the boost style directories. * I have also addressed the issues that were drawn to my attention by you and other users. * The regression testing is almost complete. Give me a chance to do the following: 1. Write to the ACM and attempt to obtain an explicit written licensing arrangement for a derived boost version of the e_float core. 2. Separate the e_float core from the functions and work out a sensible strategy for handling the modularity. I will get back to you as soon as I have significantly progressed on 1 and 2. Thank you for your interest. Sincerely, Chris. From: John Maddock <boost.regex@virgin.net> To: boost@lists.boost.org Sent: Saturday, June 4, 2011 10:10 AM Subject: Re: [boost] Is there interest in e_float: Multiple-precision floatand special functions?
To move forward, I would welcome the core e_float (with addition of reference to Boost license terms in the program text - as normal Boost practice) to be put into the Boost Sandbox. This will allow us to have something concrete to try out and make more informed comments on exactly what Boostification we feel is desirable. (It will also allow us to get a definitive license statement of agreement from ACM before we get too far in. ).
Just to be clear, we would need to sort out the license definitively *before* any code went into the sandbox SVN. Pedantically yours, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I believe that we cleared up the license issues in recent private mails. Did we adequately clear up the license issues? 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 ones. Would this initial selection be appropriate? Sincerely, Chris. From: John Maddock <boost.regex@virgin.net> To: boost@lists.boost.org Sent: Saturday, June 4, 2011 10:10 AM Subject: Re: [boost] Is there interest in e_float: Multiple-precision floatand special functions?
To move forward, I would welcome the core e_float (with addition of reference to Boost license terms in the program text - as normal Boost practice) to be put into the Boost Sandbox. This will allow us to have something concrete to try out and make more informed comments on exactly what Boostification we feel is desirable. (It will also allow us to get a definitive license statement of agreement from ACM before we get too far in. ).
Just to be clear, we would need to sort out the license definitively *before* any code went into the sandbox SVN. Pedantically yours, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Christopher Kormanyos Sent: Thursday, June 09, 2011 10:04 PM To: boost@lists.boost.org 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?
In order to get the e_float core in the sandbox, we need to define how much we would initially
*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?) 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 ones.
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 ;-) Paul 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@hetp.u-net.com
Thanks. I'm going to need some help with all this as we progress. Let me try to get started as time allows. Sincerely, Chris. From: John Maddock <boost.regex@virgin.net> To: boost@lists.boost.org Sent: Friday, June 10, 2011 6:22 PM Subject: Re: [boost] Is there interest in e_float:Multiple-precision floatand special functions?
PS You need write access to the sandbox of course. Hopefully moderator John Maddock will enable this for you?
Already done, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thanks for the input Paul. I agree. Sincerely, Chris. From: Paul A. Bristow <pbristow@hetp.u-net.com> To: boost@lists.boost.org Sent: Friday, June 10, 2011 11:27 AM Subject: Re: [boost] Is there interest in e_float: Multiple-precision floatand special functions?
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Christopher Kormanyos Sent: Thursday, June 09, 2011 10:04 PM To: boost@lists.boost.org 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?
In order to get the e_float core in the sandbox, we need to define how much we would initially
*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?) 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 ones.
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 ;-) Paul 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@hetp.u-net.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I believe that we cleared up the license issues in recent private mails.
Nod, apologies I dropped the ball on that one, but having now read http://cacm.acm.org/about-communications/author-center/acm-copyright-policy/ and talked to the other moderators, I think we're OK. There'll be an email invitation to the sandbox shortly.
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.
Nod. Ultimately it would be nice if: * The elementary functions could be made generic - it would be a huge help in getting other real-number types in Boost. * The special functions could be merged with our existing (generic) special function code base. HTH, John.
OK, thanks John. For generic elementary transcendental functions, Icould either template them or utilize the virtual mechanism. I would prefer the templates. Do you have a preference? Perhaps we should leave the option open to target up to millions of digits in future versions of e_float.(I mean quite a bit later, after building a solid basis for e_float in boost in the first place.) See next paragraph. In addition, I have another (unpublished) program, an older one, that has architecture similar to e_float's. My other program goes up to ~100-million digits using multicore FFTs, etc. It does 10^6 digits of pi using an AGM algo. in about 10 seconds. So its performance isn't too shabby. Sincerely, Chris From: John Maddock <boost.regex@virgin.net> To: boost@lists.boost.org Sent: Friday, June 10, 2011 12:38 PM Subject: Re: [boost] Is there interest in e_float: Multiple-precisionfloatand special functions?
I believe that we cleared up the license issues in recent private mails.
Nod, apologies I dropped the ball on that one, but having now read http://cacm.acm.org/about-communications/author-center/acm-copyright-policy/ and talked to the other moderators, I think we're OK. There'll be an email invitation to the sandbox shortly.
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.
Nod. Ultimately it would be nice if: * The elementary functions could be made generic - it would be a huge help in getting other real-number types in Boost. * The special functions could be merged with our existing (generic) special function code base. HTH, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
For generic elementary transcendental functions, Icould either template them or utilize the virtual mechanism.
I would prefer the templates. Do you have a preference? Perhaps we should leave the option open to target up to millions of digits in future versions of e_float. (I mean quite a bit later, after building a solid basis for e_float in boost in the first place.) See next paragraph.
They would have to be templates otherwise they're not generic ;-) There are also some conceptual architypes in Boost.Math that can be used to verify that they'll work with any type that fulfils those concept requirements. Cheers, John.
OK, the e_float codes are fully prepared for the first trial submission to the sandbox. I have committed them to my own repository. They are tested and fully equipped with licensing comments. - The bugs reported in the past have been corrected. - The special functions have been reduced to include only (elementary transcendental + gamma + zeta) for real and complex. - The test suite has been reduced accordingly. - The test program runs in ~1-10 seconds for 100 digits depending on the CPU and selected big-number back-end. - Big-number back-end support for MPFR, GMP and my own EFX are included. - The Fortran-90 REAL*16 back-end support has been removed.- A partial implementation of a generic functional interface has been added. I would like someone to take a look at this before I continue with it. I probably did not get it right. Remember, e_float in its present form only goes up to 300 digits. Nonetheless, I diligently checked compatibility of e_float with my other (bigger digit) programs and found no conflicts or limitations regarding potential extension of e_float to thousands or millions of digits in the future, of course not for every function, only those with known big-number algorithms. I am interested to see how we might interface e_float with the existing wealth of algorithms in Boost.Math. I also expect that the e_float code needs a lot of work for potential preparation for boost. I see this work as one small, but crucial, step toward standardizing big numbers. I lost my key to the sandbox. Sorry. My bad. Could you please provide me with a replacement key? Sincerely, Chris. ________________________________ From: John Maddock <boost.regex@virgin.net> To: boost@lists.boost.org Sent: Saturday, June 11, 2011 10:33 AM Subject: Re: [boost] Is there interest in e_float:Multiple-precisionfloatand special functions?
For generic elementary transcendental functions, Icould either template them or utilize the virtual mechanism.
I would prefer the templates. Do you have a preference? Perhaps we should leave the option open to target up to millions of digits in future versions of e_float. (I mean quite a bit later, after building a solid basis for e_float in boost in the first place.) See next paragraph.
They would have to be templates otherwise they're not generic ;-) There are also some conceptual architypes in Boost.Math that can be used to verify that they'll work with any type that fulfils those concept requirements. Cheers, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, Jun 23, 2011 at 8:33 AM, Christopher Kormanyos <e_float@yahoo.com>wrote: [...]
Remember, e_float in its present form only goes up to 300 digits.
[...] I'm curious, what are the reasons for this limitation? I may have missed this in previous discussion... - Jeff
Jeff, The original e_float publication in the ACM included a wide variety of the special functions of pure and applied mathematics extended to large parameter ranges. When preparing this original research work, I restricted the digit range to 300 in order to guarantee full precision of all special function calculations within known digit and parameter ranges. In the future, it will be possible to extend e_float's digit range. In fact, the digit range can be extended any time when using e_float with its GMP and MPFR back ends. Simple mathematics like add, sub, mul, div, sqrt, etc. work for GMP and MPFR in very high digit ranges. However, constants like pi, log(2), Euler's gamma, etc. as well as e_float's special functions are not yet designed for these regions and not tested therein. Also be aware that my portable big-number back-end included in e_float (called EFX) only includes order-N^2 multiplication. As such it can not be extended beyond several hundred digits. I can add Karatsuba and FFT multiplication to the EFX version at a later time, as I do have these methods in other programs. With e_float, we are making a modest first step in big-number floats for boost at this time. We need to concentrate on the architecture and design of the program and the proper semantics of the floats. Digit extension is of secondary concern right now. Sincerely, Chris. ________________________________ From: "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung@gmail.com> To: boost@lists.boost.org Sent: Thursday, June 23, 2011 8:23 PM Subject: Re: [boost] Is there interest in e_float:Multiple-precisionfloatand special functions? On Thu, Jun 23, 2011 at 8:33 AM, Christopher Kormanyos <e_float@yahoo.com>wrote: [...]
Remember, e_float in its present form only goes up to 300 digits.
[...] I'm curious, what are the reasons for this limitation? I may have missed this in previous discussion... - Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, Jun 23, 2011 at 09:45:11PM +0100, Christopher Kormanyos wrote:
Jeff,
The original e_float publication in the ACM included a wide variety of the special functions of pure and applied mathematics extended to large parameter ranges. When preparing this original research work, I restricted the digit range to 300 in order to guarantee full precision of all special function calculations within known digit and parameter ranges.
In the future, it will be possible to extend e_float's digit range. In fact, the digit range can be extended any time when using e_float with its GMP and MPFR back ends. Simple mathematics like add, sub, mul, div, sqrt, etc. work for GMP and MPFR in very high digit ranges. However, constants like pi, log(2), Euler's gamma, etc. as well as e_float's special functions are not yet designed for these regions and not tested therein.
Also be aware that my portable big-number back-end included in e_float (called EFX) only includes order-N^2 multiplication. As such it can not be extended beyond several hundred digits. I can add Karatsuba and FFT multiplication to the EFX version at a later time, as I do have these methods in other programs.
With e_float, we are making a modest first step in big-number floats for boost at this time. We need to concentrate on the architecture and design of the program and the proper semantics of the floats. Digit extension is of secondary concern right now.
Sincerely, Chris.
________________________________ From: "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung@gmail.com> To: boost@lists.boost.org Sent: Thursday, June 23, 2011 8:23 PM Subject: Re: [boost] Is there interest in e_float:Multiple-precisionfloatand special functions?
On Thu, Jun 23, 2011 at 8:33 AM, Christopher Kormanyos <e_float@yahoo.com>wrote: [...]
Remember, e_float in its present form only goes up to 300 digits.
[...]
I'm curious, what are the reasons for this limitation? I may have missed this in previous discussion...
This sounds like awesome work, but note that list policy discourages top-posting, instead preferring replies in-line or below. -- Lars Viklund | zao@acc.umu.se
Lars Viklund wrote:
On Thu, Jun 23, 2011 at 09:45:11PM +0100, Christopher Kormanyos wrote: [snip quoted text, including signatures]
This sounds like awesome work, but note that list policy discourages top-posting, instead preferring replies in-line or below.
It would be helpful to post the link to the policy (http://www.boost.org/community/policy.html#quoting), and to avoid over-quoting while posting your correction on top-posting. FWIW, I usually send private e-mail to folks about such things to avoid extra list noise. I replied publicly this time to make these suggestions for any future posts like yours. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Jeff, The original e_float publication in the ACM included a wide variety of the special functions of pure and applied mathematics extended to large parameter ranges. When preparing this original research work, I restricted the digit range to 300 in order to guarantee full precision of all special function calculations within known digit and parameter ranges. In the future, it will be possible to extend e_float's digit range. In fact, the digit range can be extended any time when using e_float with its GMP and MPFR back ends. Simple mathematics like add, sub, mul, div, sqrt, etc. work for GMP and MPFR in very high digit ranges. However, constants like pi, log(2), Euler's gamma, etc. as well as e_float's special functions are not yet designed for these regions and not tested therein. Also be aware that my portable big-number back-end included in e_float (called EFX) only includes order-N^2 multiplication. As such it can not be extended beyond several hundred digits. I can add Karatsuba and FFT multiplication to the EFX version at a later time, as I do have these methods in other programs. With e_float, we are making a modest first step in big-number floats for boost at this time. We need to concentrate on the architecture and design of the program and the proper semantics of the floats. Digit extension is of secondary concern right now. Sincerely, Chris. ________________________________ From: "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung@gmail.com> To: boost@lists.boost.org Sent: Thursday, June 23, 2011 8:23 PM Subject: Re: [boost] Is there interest in e_float:Multiple-precisionfloatand special functions? On Thu, Jun 23, 2011 at 8:33 AM, Christopher Kormanyos <e_float@yahoo.com>wrote: [...]
Remember, e_float in its present form only goes up to 300 digits.
[...] I'm curious, what are the reasons for this limitation? I may have missed this in previous discussion... - Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I lost my key to the sandbox. Sorry. My bad. Could you please provide me with a replacement key?
Can you please check your ISP to see if the message is archived anywhere, I don't see an easy way to send another invitation... if not we'll have to think of another way, John.
participants (9)
-
Christopher Kormanyos -
Edward Diener -
Erik Erlandson -
Jeffrey Lee Hellrung, Jr. -
John Maddock -
Lars Viklund -
Paul A. Bristow -
Stewart, Robert -
Thorsten Ottosen