# \[RFC\] What should the arithmetic within the FixedPointNumbers be

**URL:** <https://discourse.julialang.org/t/rfc-what-should-the-arithmetic-within-the-fixedpointnumbers-be/46697>\
**Category:** Visualization\
**Tags:** package, colors, numerics\
**Created:** [September 16, 2020, 12:14pm UTC](https://discourse.julialang.org/t/rfc-what-should-the-arithmetic-within-the-fixedpointnumbers-be/46697 "2020-09-16T12:14:42Z")\
**Posts on this page:** 1\
**Showing post:** 36

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [September 18, 2020, 11:59am UTC](https://discourse.julialang.org/t/rfc-what-should-the-arithmetic-within-the-fixedpointnumbers-be/46697/36 "2020-09-18T11:59:11Z")

</div>

I think you might have hit on the right answer: what about putting the arithmetic in a separate package? What if we had

- FixedPointWrappingArthmetic
- FixedPointSaturatingArithmetic
- FixedPointCheckedArithmetic
- FixedPointFloatArithmetic

and the user/developer just picked one? The main issue I foresee is we now need some mechanism of package exclusion: since they would all override Base operators, we can’t have ImageCore picking `FixedPointFloatArithmetic` while some other simultaneously-loaded package picks `FixedPointCheckedArithmetic`.

In the modern world all these could live in the same repository, so it would ensure they all remain closely coupled.

Splitting out the arithmetic and defining in a secondary package is technically type-piracy, but it’s that closely-coupled form of piracy that I’ve long argued has a valid place in the ecosystem.

---

_[View the full topic](https://discourse.julialang.org/t/rfc-what-should-the-arithmetic-within-the-fixedpointnumbers-be/46697)._