________________________________ From: "Simonson, Lucanus J" <lucanus.j.simonson@intel.com> To: "boost@lists.boost.org" <boost@lists.boost.org> Sent: Thursday, September 1, 2011 7:31 AM Subject: Re: [boost] Name and Namespace for Potential Boost Extended Floating-Point Christopher Kormanyos wrote:
I hear you. But I beg to augment this critical point. ...
From my perspective though, the common case is numbers with only a small constant factor more bits than the largest built-ins. In my case 65, 96 and 126 bit integer and rationals. You need 65 bits for a 32 bit integer cross product in the worst case. In many cases the probability of a large number occuring goes down with increase in its size. Yes, a fixed size array in the datatype would be my preference, but the way I would like to use such a boost multiprecision library is as a wrapper for gmp that defaults to a portable c++ implementation when gmp is not available. From my perspective usage of gmp with modest sized multiprecision values is the common case. As much as we may hate the lgpl, gmp is part of the linux environment of every machine I use for real work and it is free. Right now I have no fall back and my algorithms run in non-robust mode without gmp. I'd be very happy to have a library in boost to provide the default multiprecision datatype implementation.
Given that xint was recently rejected, which we all have mixed feelings about, I'm sure, we need to be careful about what the scope and intent of this fairly similar library is. Is the scope multiprecision floating point only with the intent to provide high-performance multiprecision algorithms? I'm afraid that direction would lead to benchmark comparisons with gmp, with predictable results. If you provide a metafunction for looking up the implementation of the mutliprecision arithemtic so that people can specify gmp (or suitable alternative) then the focus will turn toward how well you wrap gmp with your expression templates and the primary concern about your own algorithms will be their correctness and portability. I think an effort in that direction is realistic and achievable and something that could be accepted as a boost library. Be careful to set yourself a task you can succeed at by limiting the scope of your library and be careful also to avoid confusion about what it is you are trying to do by being very clear about what those limits are. Building a coalition of contributing authors might also be a good idea. For example, will you provide an extensible framework for adding mp_int and mp_rational later if your initial scope is limited to mp_float? I wish you the best of luck and success. Regards, Luke --------------------------------------------------------------------------------- Thank you for your detailed comments, Luke. The primary concern right now is multiple-precision floating point algorithms. You're right, I was not specific. My float type does this: * boost::multiprecision::mp_real (or whatever it might be called) provides a multiprecision floating-point type with a compile-time width. * It is tested and specified from 30...300 decimal digits of precision. * In addition, the expected semantics for C++ such as interaction with PODs and I/O streams are supported. * A selection of elementary transcendental functions sin, cos, etc. and Gamma and Zeta functions are provided for real and complex values. * Three back end numeric types are included in boost::multiprecision::mp_real: GMP, MPFR and my own portable base-10 EFX type. * All three back ends have similar performance, with MPFR slightly higher due to its superior transcendental functions. * The EFX type compares well with, or even beats, GMP in a bare-bones MFLOPS test at 50 and 100 decimal digits. This is going to make you guffaw. But people just say GMP is fast. They never really tried to come up with a serious alternative. Although GMP is far superior to the limited digit range that I am preliminarily offering. And we need to do a lot of work to catch up with those guys. John's big_number templates wrap native GMP, MPFR and my boost::multiprecision::mp_real, thereby augmentig these with a common interface for high-level algorithm design. Again, you are right. I have no infrastructure for a common backbone for real, int, float. And my vision is probably running away from me.