nits on BigInt Proposal

[kai zhu]

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 <isiahmeadows at 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
> me at 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 <bjouhier at 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 at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss