Subject: Re: [boost] New numeric data type proposal
From: John Maddock (boost.regex_at_[hidden])
Date: 2014-03-25 11:29:21
> Im aware of MultiPresicion types in Boost and conceptually I think they are related (and probably also related in-code).
> The main difference with MPFP is the accuracy and the main difference with Rational is in performance and range.
> The scenario to use this type is places where accurate results are needed and a common divisor for operands used exists and is known in most operations.
> The number can be expressed as QxF where Q is some kind of rational and F is some kind of float. (4 integers, Qnum, Qdenom, Mantissa, Exponente).
> The Q handles the accuracy issues:
> A simulation example, suppose you got 2 things ticking one 3 times per second and the other 1 time per second.
> Using MPFP (in Base 10), it doesnt matter how large precision you take, the 0.33333333 will not add up to integer numbers every 3 and some times the 3x ticks of one will not be simultaneous with the other ticking every 1 sec.
> Using the native float same example happens the same. The problem is in the periodic numbers which can easily represented by rationals.
> In this example the proposed numbers are represented as 1/3 * 1 and 1/3 * 3 and the Q never operates because the 2 numbers have common Q, it is reduced to compare if Q equal + same operations than using some kind of float.
> Compared to Rational the difference is the flexibility of using mantisa and exponents as float to avoid modifying the Q all the time, avoiding unnecessary simplifications and having a larger representation range that which can be handled with just changing magnitude orders using the exponent.
> The performance bottleneck is when the Q is different in the operators, but it is not worst than using Rationals and it only happens once in a while in the intended use cases.
> Suppose, a 1/6 Q and 1/7 Q want to participate in an addition, a common divisor needs to be found before operate, both are adjusted to the new divisor.
> An example of use is our simulator use case:
> We got models interacting in a simulation, each model has it own Q fixed, so after linear in quantity of models operations had been done, the Q stabilises for the whole simulation and afterward we only operate on the floating point part of the number. We dont set a global known Q at the start because models are developed in different contexts, research groups, etc we can not enforce a fixed time for everyone using a general purpose simulator, but using this method we can allow interaction easily between those models when needed with zero recoding.
Thanks for the explanation, it's interesting, and almost the same as
"exact floating point" types which are represented as a/b x 2^n and have
exact (arbitrary precision) operations for everything except division
(which is unsupported).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk