# Saline: Saturating Arithmetic in Crystal

**URL:** https://forum.crystal-lang.org/t/saline-saturating-arithmetic-in-crystal/2018
**Category:** Community
**Created:** [April 28, 2020, 1:03am UTC](https://forum.crystal-lang.org/t/saline-saturating-arithmetic-in-crystal/2018 "2020-04-28T01:03:33Z")
**Posts on this page:** 1
**Showing post:** 9

<div class="post-metadata">

### Author: ![RespiteSage](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.crystal-lang.org/respitesage/32/793_2.png) [@RespiteSage](https://forum.crystal-lang.org/u/RespiteSage)
#### Post date: [April 28, 2020, 3:05pm UTC](https://forum.crystal-lang.org/t/saline-saturating-arithmetic-in-crystal/2018/9 "2020-04-28T15:05:51Z")

</div>

> [@jhass](#):
>
> For the readme example, how about something like…

This is a good point. I’ll update the README. In particular, my number choice seems to have caused confusion already…

> [@jhass](#):
>
> I’m not sure why you’d want to keep multiple implementation around, the intrinsics version should beat them all :)

I don’t like throwing stuff away… However, if I’m able to keep an API that’s easy to use (like, I’d argue, the current one), I’m fine only using the LLVM-based implementation.

> [@bcardiff](#):
>
> @kinxer using begin/rescue to recover from exception will probably be slow … [use LLVM intrinsics]

Yeah, that’s on my to-do list. 🙂 I saw your code snippet, and I was planning on using something like that. However, I think wrapping it in a type will probably still be a friendlier API.

> **OT**
>
> > [@Arithmethic overflow should not raise an exception](https://forum.crystal-lang.org/t/arithmethic-overflow-should-not-raise-an-exception/2006/53):
> >
> > Pick one.
> 
> I had worked on saturating arithmetic a little before, but a large part of the reason I made this shard was so that **you** could use it. I’m not asking for overflowing gratitude, but it would be nice if you weren’t rude about this thing that was made for you.
> 
> > [@Arithmethic overflow should not raise an exception](https://forum.crystal-lang.org/t/arithmethic-overflow-should-not-raise-an-exception/2006/53):
> >
> > Now, while this shard is good, the initializer parameter seems redundant. If it’s `Saturating(Int32)` , it’s inferred we know the max value, we don’t need to pass in `Int32::MAX` .
> 
> This is a product of my bad example in the README (see @jhass’s post above). In a call `Saturating(T).new(x)`, the `T` is obviously the type, and the `x` is the value you want the variable to have (not the max). I’ll be changing the README to make that more clear.
> 
> > [@Arithmethic overflow should not raise an exception](https://forum.crystal-lang.org/t/arithmethic-overflow-should-not-raise-an-exception/2006/53):
> >
> > Would be better and more bonus points if we could simply do `Saturating.new(0_u32)` …
> 
> I don’t think this is possible, but I’ll look into it.
> 
> > [@Arithmethic overflow should not raise an exception](https://forum.crystal-lang.org/t/arithmethic-overflow-should-not-raise-an-exception/2006/53):
> >
> > There underlies the problem …
> 
> People have discussed this with you, and I’m not going to rehash this argument. This thread is not a place to argue that this shard shouldn’t exist because you think the language should already work like this.

---

_[View the full topic](https://forum.crystal-lang.org/t/saline-saturating-arithmetic-in-crystal/2018)._