Skip to content
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

Not precise enough #12

Closed
whitejava opened this issue Jun 5, 2017 · 8 comments
Closed

Not precise enough #12

whitejava opened this issue Jun 5, 2017 · 8 comments

Comments

@whitejava
Copy link

It's not precise enough:

        var a = fraction('1.00001');
        var b = fraction('3.2000000000001');
        var actual = a.add(b); // get 4.200010000000099 but expect 4.2000100000001

I use it for money calculation, so this behaviour is not acceptable.

@dekuenstle
Copy link

The fractions are still represented internally with floats for numerator and denominator.
Therefore you can run in approximation and representation problems like you usually do with floats (see https://stackoverflow.com/a/2100502).
For money, better use something which is based on an (almost infinit) decimal representation with the cost of runtime speed (like decimal.js).

@JensGrabner
Copy link

This script works fine: http://czurnieden.github.io/bernoulli.html

@infusion
Copy link
Collaborator

infusion commented Jun 6, 2017

Thanks for reporting this issue. We discuss this issue for quite some time now. Fraction.js isn't meant to be an arbitrary precision library (yet). It's a performance tradeoff between having a fast library and a library like decimal.js or the library Jens mentioned, which extends to rational numbers. @josdejong We should definitely think about an arbitrary precision version, for complex.js, fraction.js and quaternion.js. The question is, what is the best way to tackle this issue. Either duplicate the original source file and add an abstract version. Another way would be to create completely new projects (which I don't like, I would keep it in one project where the user can decide). As for math.js, there is already decimal.js embedded. As such the definition of the abstract type would be quite easy (plus including a different source file). What do you think?

@infusion
Copy link
Collaborator

infusion commented May 7, 2018

@josdejong Have you seen https://developers.google.com/web/updates/2018/05/bigint ? :) This looks pretty promising and I will extend the library as soon as it is in node.js.

@josdejong
Copy link

Yes, this is really great!

See also josdejong/mathjs#1096

@josdejong
Copy link

It would be nice and powerful if Fraction.js could handle "any" numeric type: number, bigint, BigNumber. We've discussed something like that in the paste in josdejong/mathjs#694

@infusion
Copy link
Collaborator

infusion commented May 7, 2018

Hmm, for complex.js this might make sense. Fraction.js can handle any input type, but I think internally the new way to go should be BigInt. For the implementation, I will create a simple polyfill for BigInt, which operates on number like before. Maybe I'll add a constant which indicates if full BigInt support is available.

@infusion
Copy link
Collaborator

infusion commented Dec 6, 2018

Please see #28

@infusion infusion closed this as completed Dec 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants