> On Feb 10, 2018, at 12:26 AM, Isiah Meadows <[email protected]> wrote: > > Kai, mind commenting about this in the proposal's repo (filing a new issue > there), where you'll more likely get feedback? > yea, and got feedback. turns out there’s a serious footgun [1] using string-only interface :(
[1] https://github.com/tc39/proposal-bigint/issues/120#issuecomment-364521444 <https://github.com/tc39/proposal-bigint/issues/120#issuecomment-364521444> > > On Fri, Feb 9, 2018, 08:51 kai zhu <[email protected] > <mailto:[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] >> <mailto:[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] <mailto:[email protected]> >> https://mail.mozilla.org/listinfo/es-discuss >> <https://mail.mozilla.org/listinfo/es-discuss> > > _______________________________________________ > es-discuss mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
