I'm glad there is some interest. I've already begun implementing it (will be testing it with GMP). I noticed (I think 3) implementations of big_integer classes in the yahoo group files section. None of them has ripened into a solid library so far? Or are they just not entirely compatible with boost::rational? Boost seems fairly ready for this stage of evolution what with interval and rational... so perhaps it's just a matter of time for big_int to be completed. At any rate, I'll continue my work and post more when I have something worth reporting (or ?s). Thanks guys, Brandon "Paul A Bristow" <pbristow@hetp.u-net.com> wrote in message news:E1D3bdc-0007Gk-SA@he303war.uk.vianw.net...
This looks very useful - if a minority pastime, but since Boost has yet to get a yet-to-be Boost big_integer to work with Boost rational, it might be running before walking.
However, exposing your impressive work to Boosters view must be good.
Paul
Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Brandon Kohn | Sent: 19 February 2005 10:15 | To: boost@lists.boost.org | Subject: [boost] lazy exact arithmetic | | Hello, | | I was just posting to see if there is any interest in | developing a library | to help with exact arithmetic using the lazy arithmetic strategy? | | I've been working for the last couple of years with | computational geometry | algorithms, and have found that such a library is really essential to | overcoming problems due to floating point precision/round off | errors in most | computational geometry algorithms with non-brute force | complexity. The idea | behind the lazy paradigm is that exact computation (using rational | arithmetic with arbitrary sized integers) is too costly to be | used all the | time. So the exact computations are delayed until such a time | as you cannot | reliably make decisions with the information you have from the 'lazy' | filters. The lazy filters are implemented as a layer of | calculation that | uses interval arithmetic to compare numerical quantities. If | the intervals | being compared are non-overlapping, the result is considered to be | sufficient and exact computation is avoided. If the intervals | do overlap, | exact computation is required to unambiguously decide how the | quantities | compare. | | This is just a rough outline of how the method works, and I'm | sure there | will be plenty of kinks to work out (my background is in physics and | computer science... so perhaps a mathematician in the group | would step up to | help guide my efforts :). | | A library such as this one exists in the CGAL kernel library which is | available under the LGPL. I find that while the LGPL can be | useful in cases | where the library is already organized as a single DLL/shared object | library, it is generally difficult to implement into | commercial solutions | due to the dynamic linking constraints imposed by the | library. Further, I | think that this type of algorithm (which solves a very big | problem with | floating point arithmetic in computing) is really something | that should be | standardized and freely available. | | Sorry for the long post :) | | What do you guys think? | | Kind regards, | Brandon | | | | _______________________________________________ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/boost | |
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost