[Haskell-cafe] Accuracy of Data.Number.Fixed
lists at qseep.net
Sun Mar 6 16:23:59 UTC 2016
On Sat, Mar 5, 2016 at 10:37 AM, Frank Staals <frank at fstaals.net> wrote:
> Why not just use Data.Fixed from base?
> > import Data.Fixed
> > read "4.02" :: Fixed E2
> > 4.02
Thanks, I had overlooked that one. That is much more satisfyingly accurate
for read/show reversibility.
It also has the advantage of encoding the precision in the type. Oddly, it
doesn't allow all precisions but just gives you a fixed set of them. Also,
It doesn't provide any operations for converting between the precisions,
rounding, or divvying out values in proportions without losing pieces of
it. And it forces you to stick with Integer as the underlying
representation, whereas Decimal lets you choose which sort of Integral to
It's interesting that Data.Fixed uses a type class to encode the precision.
I would have thought using a recursive type like Data.Number.Fixed would
make the most sense (each type being defined to have a precision of a
factor of 10 more than the preceding one), but now I wonder if there might
be some loss of efficiency during conversion due to that.
Overall I would go for the Decimal library for currency manipulation. It
was clearly designed explicitly for that purpose. The only disadvantages
are due to storing the precision in the value: potential inefficiency, and
ease of accidentally doing arithmetic on values of two different precisions
without explicit coercion. The advantages include being able to choose the
underlying integral type, show/read reversibility, and the library
operations for divvying up amounts into proportions while guaranteeing that
the sum matches the original value.
Not that one couldn't write operations to do the divvying, using
Data.Fixed. Its constructor is exposed, so one can easily add new
operations. Likewise, coercion operations could be added.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe