Boost logo

Boost :

From: Andras Erdei (aerdei_at_[hidden])
Date: 2005-09-14 08:57:20


On 9/13/05, Andy Little <andy_at_[hidden]> wrote:
>
> Are there really libraries that have unlimited precision?
> What happens when the result of a computation is irrational?
>

as i understand the possible range of arithmetic types, there are

_fixed_ precision representations, like the built-in int or float,
or (extended precision) user-defined types, like a 2048 bit integer
for RSA operations (likely implemented using modular arithmetic)

we are all familiar with these

_arbitrary_ precision numbers (same as above, but the precision is
set at runtime, rather than selected at compile time); if i understand
correctly, Joel is proposing this kind of library

i have never used such a beast, nor seen it used, so i only have
guesses about it

_unlimited_ precision types (i think these are referred as 'unlimited'
rather than as 'infinite' -- except by the current C++ Standard
Library proposal :O) -- intentionally)

these usually do not have functions like sin/log/sqrt, as they are
used for problems like solving a set of linear equations, or
maintaining your account balance in a bank, in both cases
exactly

sometimes they do have some of those functions, coupled with
the cabaility to represent the results, but i only have read about
such ones in articles, never seen or used one

_symbolic_ calculation

i have never used such a thing (beyond the capabilities of my
HP128S calculator long ago), but i think a really general implementation
is impossible (e.g. finding a primitive function could be a hard AI
problem :O), still, there are such things in use (i think mathematica
is an example, although i could be wrong)

so my answer is: unlimited precision types do not have operations
that would lead out from the set of numbers representable in that type

this does not mean that boost::rational cannot have an sqrt() function,
but it will work just like the one for float, returning an approximate
result

br,
andras


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk