no, just use one BigInt padded with a bunch of zeroes (e.g. instead of $12.34, use 1234000000, and round to nearest integer for division). this is what i meant by “fixed point” decimal. for current javascript double-precision numbers, you can do integer arithmetic up to around 9,007,199,254,000,000 which at my previous company, was good-enough to use for currency conversions.
> On Aug 7, 2017, at 2:12 AM, Isiah Meadows <isiahmead...@gmail.com> wrote: > > FYI, you could create a BigFloat class using two BigInts, one for the > value, the other for the decimal point position. You could go from > there to model infinite-precision values, using a bit of math to > ensure the two fields remain correct. > ----- > > Isiah Meadows > m...@isiahmeadows.com > > Looking for web consulting? Or a new website? > Send me an email and we can get started. > www.isiahmeadows.com > > > On Fri, Aug 4, 2017 at 11:42 AM, Bruno Jouhier <bjouh...@gmail.com> wrote: >> BigDecimal is a MUST for accounting. >> >> Main reasons: >> >> JS number precision is too limited (16 digits) >> Decimal numbers are not represented "exactly" by JS numbers => comparisons >> gives surprising results (0.1 + 0.2 !== 0.3). >> Incorrect roundtrips with SQL Databases: decimals have up to 38 digits >> precision in Oracle and SQL Server, 65 (!!) in MySQL. >> >> JSON serialization is addressed by serializing to string. Like dates (no >> date literals in JS/JSON). >> >> Same for SQL. In the absence of a BigDecimal type on JS side, values are >> passed as strings. >> >> Bruno >> >> >> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
