nits on BigInt Proposal

[kai zhu]

@bruno, i'm wondering if having a DecimalFloat128Array (based on ieee 754 standard) is good enough for accounting (with 34 decimal-digit precision)?  like existing database drivers, you can only get/set strings, but infix / inplace operators wouldn’t have that restriction.

e.g.:
```javascript
aa = new DecimalFloat128Array(['9823749.82742']);
// aa[0] can only be exposed as the string '9823749.82742'
console.assert(typeof aa[0] === 'string' && aa[0] === '9823749.82742');
// aa[0] can only be set using string as well
aa[0] = '87834398978.798';

aa = new DecimalFloat128Array(['.1']);
bb = new DecimalFloat128Array(['3']);
// cc is assigned the string '0.3',
// but the engines should be able to easily optimize hotspots that use infix and inplace operators
// with native-types,
// if implicit coercion is disallowed between DecimalFloat128Array and other types.
cc = aa[0] * bb[0];
aa[0] *= bb[0];

// guidance for database drivers would be to implement string get/set as well
aa = new DecimalFloat128Array(['97324927.8934723'])
mysqlDriver.execute(
    'INSERT INTO mydecimaltable (?,?,?);',
    ['id1234', aa[0],'foo'],
    function (error) {
        mysqlDriver.execute(
            'SELECT decimalValue,foo FROM mydecimaltable WHERE id=id1234;',
            function (error, valueList) {
                // db-driver exposes valueList[0] as the string '97324927.8934723'
                console.assert(typeof valueList[0] === 'string' && valueList[0] === '97324927.8934723');
            }
        );
    }
);
```


pros:
- requires no new language-syntax
- avoids introducing new typeof's to the javascript-language, which avoids compatibility-risks with existing database drivers (use strings to get/set values)

cons:
- arithmetic for scalars is weird: aa[0] + bb[0] (instead of aa + bb)
- does not support arbitrary precision (but are there common javascript use-cases requiring arbitrary precision?)


> On Aug 4, 2017, at 10:42 PM, 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180209/0d5fbc41/attachment.html>