@kai Yes, DecimalFloat128 is sufficient for financial applications.
If a DecimalFloat128Array type is added to the language, doesn't this imply
that a DecimalFloat128 type also exists?
If, as you wrote, typeof aa[0] === 'string', then aa[0] + bb[0] would be
string concatenation, which would be ut
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
m...@isiahmeadows.com
Looking for web
>* I remember that was a proposal for operator overloading. Was it decided
*>* against? I think that packages could solve this and many other problems if
*>* there was overloading.*
IMO Operator overloading is better than another built-in number type.
It solves a
wider range of problems: complex n
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
4 matches
Mail list logo
