rgrempel / purescript-int-53 Goto Github PK

Hi, is this lib in spago?

Something like this:

https://pursuit.purescript.org/packages/purescript-bigints/0.2.1/docs/Data.BigInt#v:pow

For consistency, degree for Ints in Prelude is defined via abs, whereas here you reuse the version for Numbers, which is simply a constant 1.

I'm actually wondering why degree is even required, since (AFAIK) its' only usage is during the proof that a generalized GCD algorithm exists for a chosen ring.

link to pursuit is broken

Following up on the discussion in #13, I'd prefer to wrap around upon overflow, rather than saturating.

My reasoning is as follows:

• Wrapping around is what the Purescript Int does, and I'd like to mimic its behaviour as far as possible.

• It appears that wrapping around is the "usual" behaviour for Integers (e.g. see https://en.wikipedia.org/wiki/Integer_overflow), whereas saturating is a more "specialized" behaviour, suitable for particular contexts.

There may be a performance implication, but:

• it shouldn't be worse than saturating for calculations that stay within 53 bits
• calculations that overflow are necessarily exceptional

The main thing would be to maintain a performance advantage over arbitrary-length integers, since if we don't have that, then we may as well use arbitrary-length integers.

Implementing a wrapping overflow will be interesting. My initial plan is something like this:

• We already detect overflow, by doing the calculation and then comparing to top and bottom

• This works because the Javascript number does compare properly to top and bottom, even beyond 53 bits.

• But, we can't determine how far we are beyond 53 bits, because we've lost precision ... that's the sense in which Javascript has 53 bits. (I suppose, in a way, Javascript keeps the wrong 53 bits for our purposes ... we'd prefer to keep them from the other end?).

• So, upon detecting overflow, we'll need to retry the original computation using a (presumably) less efficient method.

• Conceptually, one method would be to convert to arbitrary length integers, do the calculation there, and then convert back to something that fits in the expected way within 53 bits. Presumably this can be made to work ... the question is whether there might be a more efficient method, at least for some cases.

• Especially for addition and subtraction, something more clever might be possible, by detecting whether the arguments are positive or negative, measuring the difference from top or bottom, and arriving at the desired result through a calculation that doesn't overflow. Whether that's actually possible remains to be seen.

I just want to begin by thanking you for your work writing purescript-int-53. 😄

This issue is more advisory than anything, but the 2.1.0 to 2.1.1 patch upgrade included your bumping versions of Prelude and other libraries which, due to the flat resolution that PureScript/Bower uses, resulted in a rippling upgrade of everything in my app (… which broke everything).

I might suggest a major version bump in future, much like the other standard libraries did when they bumped their own dependencies.

In any case, thanks again; feel free to close this when you see it.

I know that previous merge has removed old generic support (which is discussed a bit further under PR: #15).

Do you consider tagging and publishing new version without generic support for now?

I don't want to push anything but to be honest missing official release of int53 blocks our other libraries (like redis client) releases ;-)

The latest code on Github uses Math.trunc, which should provide some modest efficiency gains.

I should release a new version. However, I'd have to declare a dependency on version 1.0.0 of purescript-math, while other of my dependencies want to pull in version 0.2 -- thus, requiring a "resolution". Which I've done for Github, but I'm a little reluctant to impose that on users of the library.

So I think I'll wait until the 1.0 series of the various dependencies have synced up.

Is there a reason of not heaving default derived Generic instance ?

Something like this:

https://pursuit.purescript.org/packages/purescript-bigints/0.2.1/docs/Data.BigInt#v:abs

Something like this:

https://pursuit.purescript.org/packages/purescript-bigints/0.2.1/docs/Data.BigInt#v:fromBase

Of course, many numeric types only 'mostly' follow laws, and I think this is understandable. But perhaps it's worth noting somewhere in the documentation that it's possible to get an Int53 which is greater than top?

For example:

module Main where

import Prelude
import Data.Int53 as Int53
import Control.Monad.Eff.Console (log)

main =
  when (top + two > top :: Int53.Int53) (log "Bounded law violated")
  where
  two = one + one

Somewhat related, I was browsing the source and noticed this comment:

Purescript is more aggressive than this with the Int type,
dropping fractional parts via (i | 0) even when you wouldn't
think a fractional part was possible.

The reason the Int type does that even when fractional parts are not possible (eg add and mul) is to ensure that the result is in the 32-bit range, so that top and bottom really are upper and lower bounds (unless you cheat with the FFI / unsafeCoerce), and also so that when it does under/overflow, the behaviour is at least generally understood and (relatively) easy to predict, just in case that wasn't clear.

For purescript-deprecated/purescript-dom#125 it would be nice to use Int53 but in contrib modules depending on "private" libraries is avoided. This lib could be pretty useful for FFI on existing JS APIs (like the issue above), so what you think, about moving this lib to purescript-contrib?

/cc @garyb