purescript-contrib/purescript-bigints

Arbitrary length integers for PureScript

purescript-bigints's Issues

use NonEmptyString

Would be nice to have the output of various functions here be NonEmptyStrings.

toBase

At the moment, its possible to parse a string representation of a base-n encoded number using fromBase :: Int -> String -> BigInt

However, its not currently possible to go other way around, from BigInt to its base-n representation (only decimal base is supported via toString)

So, having a method toBase :: Int -> BigInt -> String would be quite useful and make things isomorphic.

'big-integer' should be dependency

Hi,
I'm using a purescript module that depends on your purescript-bigints. Somewhere along the line, on a clean install, I'm missing the npm big-integer package. I guess that purescript-bigints depends on having the underlying 'big-integer' package installed? If so, it may be useful to list it as a dependency.

document results of calling functions with negative bases

Example: toBase will accept negative Ints as parameters. It would be nice for comments to address the behavior in this case.

zshr

I realize that this is probably only missing because there isn’t an equivalent function in big-integer but I’m wondering if it could be defined in terms of the existing functions.

Add `fromNumber`

There's currently no way to lift a Number type into BigInt.

Move to contrib?

There is talk on the Discord contrib channel about moving this repo to contrib so that the https://github.com/purescript-contrib/purescript-rationals package can depend on it.

https://discord.com/channels/864614189094928394/938253816862736405/981153724460335125

Are you willing to move this repo to contrib @sharkdp ?

Enclose string in parentheses in `Show` instance

This is a common convention that helps to make output usable in REPL.

instance showBigInt :: Show BigInt where
  show x = "(fromString \"" <> toString x <> "\")"

Add LICENSE file?

MIT is implicit in bower.json, but I think it would be great to have a license file too.

I cannot build bigints with pulp/bower

My library uses bigints. I can't build it with pulp/bower although I can with spago. I wonder if it is related to the CI failure on the last commit?

Conversion to Maybe Int

How can I convert BigInt to Int when I am sure that it fits in the boundaries? It would be nice to have a function for that toInt :: BigInt -> Maybe Int that would degrade BigInt to primitive Int if the conversion is possible

fromNumber is unsafe

For example, fromNumber infinity. Does it make sense to change it to fromNumber :: Number -> Maybe BigInt?

Prim.Partial ?

fromJust returns Prim.Partial, which is not a recognized type.

Example: fromJust (fromString "864854875498476985798759875076")

Documentation doesn't match behavior for the function `not` (and possibly other functions)

Doc says that function not inverts the bits.
In practice, however, the behavior is the following:

> bi = fromInt 42
> bin = toBase 2
> bin bi
"101010"

> bin (not bi)
"-101011"

where expected result for the bin (not bi) would be 10101

Since JavaScript now has BigInt as a primitive type, should not purescript also support BigInt as a primitive type.

The BigInt's in purescript are very slow, since they are wrappers around a BigInteger.js module. Since JavaScript now supports BigInts as primitive types, should not PureScript also support BigInt natively using FFI, instead of these wrappers.

Parsing an empty string succeeds and returns zero

This appears to be by design in the underlying JavaScript library (emphasis mine):

You can create a bigInt by calling the bigInt function. You can pass in

• a string, which it will parse as an bigInt and throw an "Invalid integer" error if the parsing fails.
• a Javascript number, which it will parse as an bigInt and throw an "Invalid integer" error if the parsing fails.
• another bigInt.
• nothing, and it will return bigInt.zero.

The stage 3 draft BigInt specification for ES requires this too:

EDITOR'S NOTE
StringToBigInt("") is 0n according to the logic in 3.1.3.1.

This is not what I would do if it were up to me, but since this library is mostly just a binding to the underlying JavaScript library, perhaps the best way forward is to leave this as-is and clarify this behaviour in the documentation?

base n representations as Arrays of Ints

I propose toBaseArray :: Int -> BigInt -> NonEmptyArray Int.