Possible support for numbers larger than 32 bits?

[fasiha]

Only because Project Euler #3 asks for the largest prime factor of 600851475143 (≈6e11) I realized that Arithmetic.primeFactors does something unexpected when faced with numbers too large to fit in 32 bits:

-- Arithmetic.primeFactors 600851475143
[71,-127237759]

It seems to handle inputs less than or equal to 2^32-1 fine but stumbles on bigger values.

Thank you for this very handy library!

[lynn]

Yeah, there’s a sad limitation on Elm’s Int type whereby it can’t store large numbers:

> 600851475143 // 1
-443946297 : Int

I’ve actually looked at @javcasas’ Data.Integer package to resolve this issue — maybe I could rewrite all my algorithms using this bignum type, and export Arithmetic.Integer.primeFactors and the likes. It seems Evan doesn’t want to add bignums to the core language, which I think is a little sad; a library like this will always be a little clumsy to use.

[fasiha]

Just some unsolicited ideas and questions 🙇—

I haven’t grokked Elm’s type system enough to know, but could you make a function that accepts an Int or Float or a bignum or etc., and case on the argument’s type? If so, then could you overload / and other arithmetic operators based on the input’s type? The goal would be to make the core implementation of the algorithm the same for all types, instead of some that use / and others that use // etc. It’d be really nice to keep native Int/Float performance and only step up to bignum if necessary or requested.

This is probably a moot point since Data.Integer is available, but https://github.com/kripken/gmp.js is a GNU GMP port to JavaScript (via Emscripten, so the original C code compiled to JS). That might be another option.

Thanks for this helpful library!

[lynn]

I haven’t grokked Elm’s type system enough to know, but could you make a function that accepts an Int or Float or a bignum or etc., and case on the argument’s type? If so, then could you overload / and other arithmetic operators based on the input’s type? The goal would be to make the core implementation of the algorithm the same for all types, instead of some that use / and others that use // etc. It’d be really nice to keep native Int/Float performance and only step up to bignum if necessary or requested.

This is actually precisely what Haskell does with the number typeclasses. Elm simulates the Num typeclass in a very limited way using a magical number type variable (see the types of (+) and friends), but I can’t add bignums to it. Elm lacking the machinery for this kind of “genericness” is a common complaint — see this article for a nice rant about it, which applies a proposed solution, only to conclude that that solution also kinda sucks. :(

Thanks for this helpful library!

You’re very welcome — I’m glad it’s been helpful to you. I’ll leave this issue open for discussion (and I’m still trying to decide between “implement bignum variants” and “accept that Elm is the wrong language for this”…)

[Mayeu]

Hello,

I was looking for a BigInt library, and found Data.Integer, saddly it is was not up-to-date with Elm 0.18.

I have started a pull request to update it, but my knowledge of Elm and how to encode big integer is pretty limited so I am looking for help to fix the tests.

Will you be willing to help to make big integer possible in Elm 0.18?

Edit: I understood my error, the tests are now fixed ^^