Boost logo

Boost :

Subject: Re: [boost] [Review Request] Multiprecision Arithmetic Library
From: Topher Cooper (topher_at_[hidden])
Date: 2012-04-03 00:37:51

On 4/2/2012 6:29 PM, Andrii Sydorchuk wrote:
> Yes, those are very large numbers:-). I would say that int32 exponent
> should be good enough (I don't mean that it should be used). I am eager to
> see applications of int64 exponent range.
> Andrii
Yeah -- the diameter of the observable universe (not the observed
universe -- the physically observable universe) in Plank units (the
smallest physically meaningful length according to QM) is about
1.5*2^204, so 9 bits (positive and negative exponents) is all that is
required to express the exponent for any physical distance in any
physically meaningful units. Volumes would reach binary exponent of 613
so 11 bits covers this with generous room to spare. I doubt you will
find any physical quantities that will be much larger. Combinatorics
can easily generate very large quantities, of course, but if you are
getting into those ranges you probably will be using logarithms. So 16
bits is probably as much as you can reasonably expect to need (lots of
bits in the mantissa is, of course, justifiable to preserve precision in
intermediate results), and 32 would be as much as you can *un*reasonably
expect to need -- and more.

I'm not actually arguing against the choice of int64 representation for
the exponents either. There are other issues then utility in efficient
design and a few unused bits are worth it for performance or even just
code simplicity. Just thought I would put things in perspective. (I'm
partially responding with amusment here, because I remember when we
wondered whether there really was any point to the 15 bit exponents when
the HFloat (H = Huge) format was introduced the the VAX architecture on
request/recommendation of some members of the scientific community, the
GFloat format (G=Grand) introduced at the same time for the same reason
had 11 bit exponents).


Boost list run by bdawes at, gregod at, cpdaniel at, john at