A Boost.NumericAdaptor library to support big numbers
Hello, Barend quickly talked about this in the discussion about robustness, big numbers and GMP. We have discussed about the idea and I'd like to present it here to see if there's an interest. The idea started from the need to rely on big numbers in geometry computations that are sensitive to floating point errors. The most important points were: - big numbers are needed for those computations - it's difficult to develop a Boost Big Numbers library as efficient as the existing ones - having a Boost geometry library that *necessarily* depends on an existing big numbers library would impose to the user the way in which big numbers must be handled, and would imply a dependency that apparently disturbs some people Thus we had the idea of using an adaptor, that is a wrapper that would have the same semantics as a number, with an underlying implementation chosen at compile-time, by selecting a policy. There would be a IEEE policy that doesn't use any big number at all, and other policies that would be implemented upon the most widely used big numbers libraries. In the end it appears that this adaptor could become a library on its own since it can be useful in other libraries than just geometry. It could thus take the form of a Boost.NumericAdaptor library, aimed to any library developer who needs to optionally enable the use of big numbers for the most robustness-sensible operations of his library. He would just have to take a policy as a template parameter, and propagate this policy to a Numeric Adaptor used internally. The first user of this library would obviously be the GGL we're developing. Libraries like the fixed-size matrix being currently discussed as a GSoC project could offer take advantage of this kind of library, since ideally it has to support big numbers. The sample in attachment shows the numeric_adaptor, a IEEE policy, a GMP policy and a sample showing the use of the library. The implementation has to evolve of course, but the main points are here. Would there be an interest in adding such a library into Boost? Bruno Lalande Barend Gehrels
Bruno Lalande wrote:
The sample in attachment shows the numeric_adaptor, a IEEE policy, a GMP policy and a sample showing the use of the library. The implementation has to evolve of course, but the main points are here.
Would there be an interest in adding such a library into Boost?
I personally would love to see such a library. Regards, Chris Hamilton
On Mon, Mar 30, 2009 at 10:55, Bruno Lalande <bruno.lalande@gmail.com> wrote:
The sample in attachment shows the numeric_adaptor, a IEEE policy, a GMP policy and a sample showing the use of the library. The implementation has to evolve of course, but the main points are here.
The attachment didn't come through for me; Perhaps you should upload it to vault/sandbox?
Would there be an interest in adding such a library into Boost?
I would be very interested. I think the wrapper approach is far superior to yet another incomplete implementation.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Bruno Lalande Sent: 30 March 2009 15:56 To: boost@lists.boost.org Subject: [boost] A Boost.NumericAdaptor library to support big numbers
Hello,
Barend quickly talked about this in the discussion about robustness, big numbers and GMP. We have discussed about the idea and I'd like to present it here to see if there's an interest.
The idea started from the need to rely on big numbers in geometry computations that are sensitive to floating point errors. The most important points were: - big numbers are needed for those computations - it's difficult to develop a Boost Big Numbers library as efficient as the existing ones - having a Boost geometry library that *necessarily* depends on an existing big numbers library would impose to the user the way in which big numbers must be handled, and would imply a dependency that apparently disturbs some people
Thus we had the idea of using an adaptor, that is a wrapper that would have the same semantics as a number, with an underlying implementation chosen at compile-time, by selecting a policy. There would be a IEEE policy that doesn't use any big number at all, and other policies that would be implemented upon the most widely used big numbers libraries.
In the end it appears that this adaptor could become a library on its own since it can be useful in other libraries than just geometry. It could thus take the form of a Boost.NumericAdaptor library, aimed to any library developer who needs to optionally enable the use of big numbers for the most robustness-sensible operations of his library. He would just have to take a policy as a template parameter, and propagate this policy to a Numeric Adaptor used internally. The first user of this library would obviously be the GGL we're developing. Libraries like the fixed-size matrix being currently discussed as a GSoC project could offer take advantage of this kind of library, since ideally it has to support big numbers.
The sample in attachment shows the numeric_adaptor, a IEEE policy, a GMP policy and a sample showing the use of the library. The implementation has to evolve of course, but the main points are here.
Would there be an interest in adding such a library into Boost?
Bruno Lalande Barend Gehrels
Yes - Sounds interesting - but the sample compiles - with a blizzard of warnings :-(( I've used this gmp.h #include "i:\boost-sandbox\SOC\2007\bigint\gmp-win32\gmp.h" but fails to link for me. (MSVC 2008 Sp1) What am I also missing? Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com num_adaptor.obj : error LNK2019: unresolved external symbol __imp____gmpf_clear referenced in function "public: static void __cdecl gmp_policy::destruct(struct __mpf_struct (&)[1])" (?destruct@gmp_policy@@SAXAAY00U__mpf_struct@@@Z) num_adaptor.obj : error LNK2019: unresolved external symbol __imp____gmpf_set referenced in function "public: static void __cdecl gmp_policy::copy(struct __mpf_struct const (&)[1],struct __mpf_struct (&)[1])" (?copy@gmp_policy@@SAXAAY00$$CBU__mpf_struct@@AAY00U2@@Z) num_adaptor.obj : error LNK2019: unresolved external symbol __imp____gmpf_cmp referenced in function "public: static int __cdecl gmp_policy::compare(struct __mpf_struct const (&)[1],struct __mpf_struct const (&)[1])" (?compare@gmp_policy@@SAHAAY00$$CBU__mpf_struct@@0@Z) num_adaptor.obj : error LNK2019: unresolved external symbol __imp____gmpf_init referenced in function "public: static void __cdecl gmp_policy::init(struct __mpf_struct (&)[1])" (?init@gmp_policy@@SAXAAY00U__mpf_struct@@@Z) num_adaptor.obj : error LNK2019: unresolved external symbol __imp____gmpf_add referenced in function "public: static void __cdecl gmp_policy::add(struct __mpf_struct (&)[1],struct __mpf_struct const (&)[1],struct __mpf_struct const (&)[1])" (?add@gmp_policy@@SAXAAY00U__mpf_struct@@AAY00$$CBU2@1@Z) num_adaptor.obj : error LNK2019: unresolved external symbol __imp____gmpf_mul referenced in function "public: static void __cdecl gmp_policy::multiply(struct __mpf_struct (&)[1],struct __mpf_struct const (&)[1],struct __mpf_struct const (&)[1])" (?multiply@gmp_policy@@SAXAAY00U__mpf_struct@@AAY00$$CBU2@1@Z) num_adaptor.obj : error LNK2019: unresolved external symbol __imp____gmpf_sub referenced in function "public: static void __cdecl gmp_policy::subtract(struct __mpf_struct (&)[1],struct __mpf_struct const (&)[1],struct __mpf_struct const (&)[1])" (?subtract@gmp_policy@@SAXAAY00U__mpf_struct@@AAY00$$CBU2@1@Z) num_adaptor.obj : error LNK2019: unresolved external symbol __imp____gmpf_div referenced in function "public: static void __cdecl gmp_policy::divide(struct __mpf_struct (&)[1],struct __mpf_struct const (&)[1],struct __mpf_struct const (&)[1])" (?divide@gmp_policy@@SAXAAY00U__mpf_struct@@AAY00$$CBU2@1@Z) num_adaptor.obj : error LNK2019: unresolved external symbol __imp____gmpf_sqrt referenced in function "public: static void __cdecl gmp_policy::sqrt(struct __mpf_struct (&)[1],struct __mpf_struct const (&)[1])" (?sqrt@gmp_policy@@SAXAAY00U__mpf_struct@@AAY00$$CBU2@@Z) num_adaptor.obj : error LNK2019: unresolved external symbol __imp____gmpf_set_d referenced in function "public: static void __cdecl gmp_policy::set<double>(struct __mpf_struct (&)[1],double const &)" (??$set@N@gmp_policy@@SAXAAY00U__mpf_struct@@ABN@Z) num_adaptor.obj : error LNK2019: unresolved external symbol __imp____gmpf_get_d referenced in function "public: static double __cdecl gmp_policy::big_numeric_cast<double>(struct __mpf_struct const (&)[1])" (??$big_numeric_cast@N@gmp_policy@@SANAAY00$$CBU__mpf_struct@@@Z) J:\Cpp\num_adapter\num_adapter\Debug\num_adapter.exe : fatal error LNK1120: 11 unresolved externals E-mail message checked by Spyware Doctor (6.0.0.386) Database version: 5.12070 http://www.pctools.com/uk/spyware-doctor-antivirus/
Hi Paul, I personally use GCC/Linux, with the libgmp pakaged by Debian (libgmp3-dev). I don't have any warning (even with -Wall) or link errors (as soon as I link with libgmp of course). Barend uses MSVC so maybe he'll be able to help you more than me? Could you show us the list of warnings? Bruno
Hi Paul, Paul A. Bristow wrote:
Yes - Sounds interesting - but the sample compiles - with a blizzard of warnings :-((
I've used this gmp.h
#include "i:\boost-sandbox\SOC\2007\bigint\gmp-win32\gmp.h"
but fails to link for me. (MSVC 2008 Sp1)
What am I also missing?
GMP is not header only. You need a win32 build. There are some (but not too much) on the internet. I have it from http://www.cs.nyu.edu/exact/core/gmp. It works fine but it is not the latest version of GMP. Maybe someone knows a better win32 distribution. Regards, Barend
Brian Gladman has produced some MSVC builds of gmp, e.g. here: http://gladman.plushost.co.uk/oldsite/computing/index.php Chris -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Barend Gehrels Sent: 31 March 2009 09:24 To: boost@lists.boost.org Subject: Re: [boost] A Boost.NumericAdaptor library to support big numbers Hi Paul, Paul A. Bristow wrote:
Yes - Sounds interesting - but the sample compiles - with a blizzard of warnings :-((
I've used this gmp.h
#include "i:\boost-sandbox\SOC\2007\bigint\gmp-win32\gmp.h"
but fails to link for me. (MSVC 2008 Sp1)
What am I also missing?
GMP is not header only. You need a win32 build. There are some (but not too much) on the internet. I have it from http://www.cs.nyu.edu/exact/core/gmp. It works fine but it is not the latest version of GMP. Maybe someone knows a better win32 distribution. Regards, Barend _______________________________________________ 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 Chris Card Sent: 31 March 2009 09:36 To: boost@lists.boost.org Subject: Re: [boost] A Boost.NumericAdaptor library to support big numbers
Brian Gladman has produced some MSVC builds of gmp, e.g. here: http://gladman.plushost.co.uk/oldsite/computing/index.php
I have this thanks - but the Solution had a Problem building :-( So I have a specialised gmp.h OK but I don't have a library :-(( But thanks. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
Hello, As there seems to be some interest in this library, we will develop a complete and maybe more elaborated version, and will propose it soon for review. Thanks for your feedbacks. Bruno
On Thu, 2 Apr 2009 09:38:39 +0200, Bruno Lalande <bruno.lalande@gmail.com> wrote:
As there seems to be some interest in this library, we will develop a complete and maybe more elaborated version, and will propose it soon for review. Thanks for your feedbacks.
I'm really looking forward to seeing a big number library in boost. -- EA
participants (7)
-
Barend Gehrels -
Bruno Lalande -
Chris Card -
Chris Hamilton -
Edouard A. -
Paul A. Bristow -
Scott McMurray