nits on BigInt Proposal

kai zhu kaizhu256 at gmail.com
Sat Feb 10 05:56:45 UTC 2018


> On Feb 10, 2018, at 12:26 AM, Isiah Meadows <isiahmeadows at gmail.com> 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 <kaizhu256 at gmail.com <mailto:kaizhu256 at gmail.com>> 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 <bjouhier at gmail.com <mailto: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 <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180210/07ec7252/attachment-0001.html>


More information about the es-discuss mailing list