Kai, mind commenting about this in the proposal's repo (filing a new issue there), where you'll more likely get feedback?
On Fri, Feb 9, 2018, 08:51 kai zhu <[email protected]> wrote: > @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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
