-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document saturating behavior of addition and multiplication #13
Conversation
Also fixes some bitrot in the build. |
Ah, yes, this is the result of the discussion here: So, the intention is to do what Purescript does for I suppose that if you enforce I guess the other alternative would be to throw an exception past 53 bits ... but that's not what Anyway, it probably makes sense to merge this documentation change ... I'm just thinking out loud again about the underlying behaviour, which I suppose still makes sense. |
Or, perhaps there is another behaviour in which you'd "wrap around" from top to bottom and vice versa? Perhaps it would be possible to obey the associativity laws that way, and still in a sense enforce Though I don't think that's what |
The "wrap around" behaviour is described here: https://en.wikipedia.org/wiki/Integer_overflow But I suppose what I really ought to do is re-verify what |
This is what most sane languages do. Haskell, for example:
And this obeys associativity of addition, and a few more laws that aren't satisfied by saturating arithmetic.
It does:
Since we have to deal with JavaScript, it's not easy to implement, so I'm not sure it should be the behavior of |
By the way, I found this issue while investigating jacobstanley/purescript-jack#25 . It's quite possible that the author of the RNG module expected Int53 to wrap around, since the module is a port from Haskell. |
Ah, oddly enough I ran into the same problem recently with a random number generator in purescript-elm-compat ... I broke it when saturating top and bottom in Int53, for (roughly) the same reason. Basically, my design goals for
So, if a "wrapping around" behaviour can be implemented in a way that doesn't eliminate the performance improvement vs. arbitrary length integers, that's what I'd prefer to do. (Speaking of which, I suppose I ought to benchmark the performance improvement if that's one of my design goals!) Thinking out loud for a moment about implementation, I suppose the difficulty is that the "overflowed" number you get from Javascript past 53 bits is of limited use as an integer. You can compare it, so you can know you've gone over 53 bits. However, you've lost precision, so you can't directly use that number to "recover" a wrapped-around result. So, I suppose you'd have to detect the overflowed situation (which the module does now), and then fall back on some other kind of calculation with the original arguments. As for what this would be, I can think of two things off the top of my head:
It seems to me that doing something clever might be possible for addition and subtraction, but I might be wrong about that. I'm less confident about multiplication or raising to a power. Anyway, I'd like to give that a try -- I'd prefer not to saturate if |
So, the This does a little bit more in Javascript than I had realized. For 32 bits, the first positive integer that overflows is 2147483648, and Anyway, that just re-confirms that an ordinary Purescript |
So, I've created #14 to think a bit about behaviour ... in the meantime, I suppose one should document what it does now. So, I'll merge this ... thanks! |
Arithmetic operations on
Int53
saturate onbottom
andtop
. This may be non-obvious, since most in most languages integers wrap around instead. Instance documentation should clarify that.