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

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to