Which is theoretically equivalent. Either way, we can implement a
BigDecimal (or similar) in terms of a BigInt, which was my point.
Looking for web consulting? Or a new website?
Send me an email and we can get started.
On Sun, Aug 6, 2017 at 9:28 PM, kai zhu <kaizhu...@gmail.com> wrote:
> no, just use one BigInt padded with a bunch of zeroes (e.g. instead of
> $12.34, use 1234000000, and round to nearest integer for division). this is
> what i meant by “fixed point” decimal.
> arithmetic up to around 9,007,199,254,000,000 which at my previous company,
> was good-enough to use for currency conversions.
>> On Aug 7, 2017, at 2:12 AM, Isiah Meadows <isiahmead...@gmail.com> wrote:
>> FYI, you could create a BigFloat class using two BigInts, one for the
>> value, the other for the decimal point position. You could go from
>> there to model infinite-precision values, using a bit of math to
>> ensure the two fields remain correct.
>> Isiah Meadows
>> Looking for web consulting? Or a new website?
>> Send me an email and we can get started.
>> On Fri, Aug 4, 2017 at 11:42 AM, Bruno Jouhier <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.
>>> es-discuss mailing list
>> es-discuss mailing list
es-discuss mailing list