Robert Eisele

Yes, I removed this as it introduced overflow problems quickly and I did not like the implementation. It was added due to a bug report back then, but after running...

The old song ;D I started porting fraction.js to BigInt, but still a way to go to make it robust and pass all test cases. Since it is a string,...

Ah and BTW, the actual problem I have with BigInt is backwards compatibility. Every constant term within the source must be suffixed by n, like "0n" for a BigInt(0). This...

Yea, lets focus on fractions first, complex numbers is another even more complex story. I'm almost done converting it to bigint, from 200 failing tests to only 29 edge cases....

Boooooom, I invite all of you to test the file as much as possible: https://github.com/infusion/Fraction.js/blob/master/bigfraction.js Only one test is failing, namely `JSON.stringify` does not know how to serialize BigInt, I...

Ah and what I changed is this silly `NaN` behavior. Since `NaN ∉ BigInt`, I reverted that decision that `NaN ∈ Fraction`. Based on a pull request somewhere in time...

And to come back to the initial call of issue #28: ```js new Fraction('4.166666666666667') // { s: 1n, n: 4166666666666667n, d: 1000000000000000n } new Fraction('4.166666666666666666666666666666666666666666666666666666666666667') // { s: 1n, //...

I just managed to implement a backwards compatible fraction.js implementation. The only problem is Babel now. I got a ticket a while ago that es6 modules can't be compressed easily...

I hope we can find a solution for the packaging problem as it is the only show stopper right now to release 5.0.0. Do you see any conflicts on the...

It might only break when you access the numerator and denominator attributes directly since you run into a type mismatch this way. The quick fix is to wrap it into...