nits on BigInt Proposal

[Isiah Meadows]

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 <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> 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
>
>
> _______________________________________________
> 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/e35f4e1c/attachment.html>