Mostly. One difference is that over/underflow is signaled in `CF` (carry bit), and that's used to extend arithmetic: to add a pair of 128-bit numbers you `ADD` the lower 64 bits, advance to the higher 64 bits, and `ADC` those (the "C" means it uses the carry bit). And `CF` might again be set afterward indicating that it overflowed 128 bits. (This is also why Intel architecture orders bytes/words the way it does.) That it otherwise behaves as modular is in support of this, not in support of a mathematical law, and the behavior might differ on other architectures (e.g. PPC, or if someone somewhere still has a processor using 1s- complement). Which is the most important point: the Report specifies `Integral` types other than `Integer` to behave like the machine type, and you're basically assuming x86-64 (_probably_ also AArch64 but i haven't studied that one, just assuming it's 2s-complement) if you assume either modular arithmetic or any other behavior. The only promise you get is "matches the underlying hardware".

On Sun, Jul 20, 2025 at 8:25 PM Jeff Clites via Haskell-Cafe <haskell-cafe@haskell.org> wrote:

> On Jul 20, 2025, at 9:43 AM, Brandon Allbery <allbery.b@gmail.com> wrote:
>
> I would like to point out that if you want correctness, you should use `Integer`. If you are using a bounded `Integral` it is expected that you are doing so because you value speed over correctness. They are _not_ `Z/n`, they are hardware values that have little to do with formal mathematics.

But aren't they de-facto modular integers?

Jeff
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


--
brandon s allbery kf8nh
allbery.b@gmail.com