Transforming a float
into a Bignum.t
needs to be done with care. Most rationals and decimals are not exactly representable as floats, thus their float representation includes some small imprecision at the end of their decimal form (typically after the 17th digits). It is very likely that when transforming a float
into a Bignum.t
, it is best to try to determine which was the original value and retrieve it instead of honoring the noise coming from its imprecise float representation.
Given that the original value is not available in the context of a function whose type is float -> Bignum.t
, it is not possible to solve that problem in a principled way. However, a very reasonable approximation is to build the Bignum
from a short string-representation of the float that guarantees the round-trip float |> to_string
|> of_string
. In particular, if the float was obtained from a short decimal string, this heuristic in practice succeeds at retrieving the original value.
In the context where it is assumed that a float is a perfect representative of the value meant to be modelled, the actual Bignum.t
value for it may be built using of_float_dyadic
.
For example:
3.14
is not a representable decimal, thus:
of_float_dyadic (Float.of_string "3.14") = (3.14 + 7/56294995342131200)
of_float_decimal (Float.of_string "3.14") = 3.14
of_float_dyadic
used to be called of_float
but we think it is not the right default choice, thus of_float
was deprecated, and we introduced different names for this operation to force some explicit decision at call site.
After some time has passed, of_float_decimal
will be renamed to of_float
, thus re-introducing of_float
in the API.