# Haskell Decimal Libraries - Financial App - IEEE 754-2008

**URL:** <https://discourse.haskell.org/t/haskell-decimal-libraries-financial-app-ieee-754-2008/1000>\
**Category:** Learn\
**Created:** [December 1, 2019, 7:04pm UTC](https://discourse.haskell.org/t/haskell-decimal-libraries-financial-app-ieee-754-2008/1000 "2019-12-01T19:04:57Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![DouglasBrunner](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/douglasbrunner/32/621_2.png) [@DouglasBrunner](https://discourse.haskell.org/u/DouglasBrunner)\
**Post date:** [December 1, 2019, 7:04pm UTC](https://discourse.haskell.org/t/haskell-decimal-libraries-financial-app-ieee-754-2008/1000/1 "2019-12-01T19:04:57Z")

</div>

I’m looking for libraries for storing and working with currency.

I’ve found a few so far but would be interested in seeing if there are any that I’ve overlooked.  
I’ll be doing calculations on these values (variance, square root, standard deviation) so it would be ideal if they had instances for working with standard math operators (+, -, ^, sqrt, log, etc).

**Numeric.Decimal**

> **[decimal-arithmetic](https://hackage.haskell.org/package/decimal-arithmetic-0.5.1.0)**
>
> An implementation of the General Decimal Arithmetic
> Specification

It has support for IEEE 754-2008 but is marked as experimental.

**Data.Decimal**

> **[Decimal](https://hackage.haskell.org/package/Decimal-0.5.1)**
>
> Decimal numbers with variable precision

Works with arithmetic operators but missing instance for Fractional so I can’t use it with sqrt and friends without implementing the functionality myself it seems. Despite this, it looks promising.

**Data.Ratio**

> **[Data.Ratio](https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Ratio.html)**

Has a tendency to explode in space and performance can be poor.

**Data.Scientific**

> **[Data.Scientific](https://hackage.haskell.org/package/scientific-0.3.3.5/docs/Data-Scientific.html)**

Looks good, but from the documentation: _Although `Scientific` is an instance of `Fractional` , the methods are only partially defined! Specifically `recip` and `/` will diverge (i.e. loop and consume all space) when their outputs have an infinite decimal expansion_

---

<div class="post-metadata">

**Author:** ![chreekat](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/chreekat/32/2669_2.png) [@chreekat](https://discourse.haskell.org/u/chreekat)\
**Post date:** [December 2, 2019, 6:04am UTC](https://discourse.haskell.org/t/haskell-decimal-libraries-financial-app-ieee-754-2008/1000/2 "2019-12-02T06:04:35Z")

</div>

I would say as soon as you do a sqrt, you aren’t dealing with currency anymore, right? Now you’re doing analysis on currency as if it were a real number, which is probably the time to move to (newtypes over) floats, or some other approximation of the reals.

---

<div class="post-metadata">

**Author:** ![DouglasBrunner](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/douglasbrunner/32/621_2.png) [@DouglasBrunner](https://discourse.haskell.org/u/DouglasBrunner)\
**Post date:** [December 4, 2019, 1:20am UTC](https://discourse.haskell.org/t/haskell-decimal-libraries-financial-app-ieee-754-2008/1000/3 "2019-12-04T01:20:07Z")

</div>

That’s a good perspective, and I like it. I was hoping for a quick win and would be able to use one accurate type throughout, but I’ll consider the approximation.

Using Data.Decimal I was to get unit tests passing which were failing when using Doubles. The actual and expected result differed by a small amount when using Doubles. I could have tested for a lesser precision rather than for an exact match, but it was nice to see that the calculations could be done so accurately.

---

<div class="post-metadata">

**Author:** ![chreekat](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/chreekat/32/2669_2.png) [@chreekat](https://discourse.haskell.org/u/chreekat)\
**Post date:** [December 5, 2019, 8:15am UTC](https://discourse.haskell.org/t/haskell-decimal-libraries-financial-app-ieee-754-2008/1000/4 "2019-12-05T08:15:05Z")

</div>

> [@DouglasBrunner](#):
>
> I could have tested for a lesser precision rather than for an exact match,

This is really the only possibility, if I remember my numerical analysis courses properly. You definitely want integers for _counting_ your currency, but lots of useful analysis introduces both rounding errors and estimation errors. If you aren’t keeping track of those, you’re probably introducing bugs. 🙂 And with some known error e, the best equivalence you can test for is the fuzzy `|a1 - a2| < e`

---

<div class="post-metadata">

**Author:** ![ajirx](https://avatars.discourse-cdn.com/v4/letter/a/46a35a/32.png) [@ajirx](https://discourse.haskell.org/u/ajirx)\
**Post date:** [December 11, 2019, 6:42am UTC](https://discourse.haskell.org/t/haskell-decimal-libraries-financial-app-ieee-754-2008/1000/6 "2019-12-11T06:42:47Z")

</div>

> [@chreekat](#):
>
> I would say as soon as you do a sqrt, you aren’t dealing with currency anymore, right?

In the case of calculating the interest to be paid or received, you may need sqrt or other functions that work rather on doubles than on integers. This leads to rounding rules and handling the precision appropriately, but we are still calculating something that will give a currency (not analysis, but actual amounts). There are also other cases e.g. in accounting and handling currencies, where you may need doubles.

---

<div class="post-metadata">

**Author:** ![Drezil](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/drezil/32/4989_2.png) [@Drezil](https://discourse.haskell.org/u/Drezil)\
**Post date:** [February 12, 2020, 12:21pm UTC](https://discourse.haskell.org/t/haskell-decimal-libraries-financial-app-ieee-754-2008/1000/8 "2020-02-12T12:21:21Z")

</div>

Or you can use recurring-fractions… those should handle this as well… but computations can get way expensive as you just cache everything in lazy lists & only do the computation up to the needed precision in the end.