BigDecimal – JavaScript Polyfill for proposed Decimal data type | Hacker News Reader

BigDecimal – JavaScript Polyfill for proposed Decimal data type

github.com

53 pointsmunrocket18 comments

JS urgently needs support for decimals and thus be able to establish in sectors such as scientific and financial.

as I said before, V8 + dynamic language + better math support = perfect environment for many applications out there

Decimal shouldn't be part of the interpreter. Even Python doesn't do that.

JS needs operator overloading so that it can have decimals, rationals, ndarrays, automatic differentiation, etc. Unfortunately operator overloading is a dirty word for most of the webblubs who use JS. I've given up hope of that ever changing.

JavaScript inherited the abysmal standard library support of Lisp language families and poor support for domain specific use cases of Java. The situation has been improving, but with the ”never break the backwards compatibility” of the web browsers on the driver seat, JavaScript will never be like Python or Julia for the data science use cases.

Common Lisp supports actual fractions (integer ratios).

Yeah, operator overloading would be a nice welcome change, and in the end the interpreter already does something similar because of all the coercion rules... Considering how JavaScript works behind the curtain, it seems to me that it wouldn't be such a huge change to just do something like Python's __add__ magic method

Floating point shouldn't be part of the interpreter. Integers are all you need.

A corollary is that SQLite is as ubiquitous to structured storage as JavaScript is to programming and it too lacks the exact decimal representation available as DECIMAL(precision, scale) in other SQL engines.

These are not fatal flaws, IMO, just gaps in need of attention.

JS is already very popular in finance, decimal types aren’t always needed for monetary values, floats are often fine (or computations can be done on the backend).

We usually store the values as longs and apply the decimal marker only when showing to the user. Floats are fine when it's just long to float. But any operation between two floats is a mistake.

Not for financial modelling which is the bulk of work in the front office. Everything is calculated as floats for performance reasons, no model is accurate enough for floating point error to matter.

> or computations can be done on the backend

what if your backend is nodejs? decimals for JS are mainly needed on backend

I don't think decimal is that big a deal for financial programming. When $0.01 accuracy matters, you just build your data structures around cents instead of dollars and get on with your life.

Right, but then you get "and what about tenths of a cent?". I've worked on projects where the necessary precision changed over time, and it's a lot easier to update your database columns to `DECIMAL(9,2)` to `DECIMAL(10,3)` than to update every place in your code where you're going from cents to mills.

Obviously, there's still significant testing to do to make sure that formerly correct code still rounds as expected, but if you're using a decimal structure like most BigDecimal ones, in memory you're already using arbitrary precision until storage anyway. Which I've done using stuff like decimal.js in JS, too, as it happens. But having it in core is the happy path for a lot of folks who don't already know that this is the way to go.

I’m curious how much diff there is with the existing BigDecimal packages (big.js & family). Their APIs look very similar, unsurprisingly. It would be great if a lot of existing code is already mostly compatible.

I woke in crypto and we use bignumber.js. even so, developers default to just using Number and built in math. Having Decimal be native would make it a lot easier to be consistent in the code.

Oh for sure! I definitely found myself being a lone voice when I saw precision-dependent arithmetic being done with native floats and asking to use a decimal library.

I was mostly coming at the question as “I wonder how much API overlap there is for people who already adopted libraries”.

This is a bit of a tangent, but after I used Clojure for a while, I found the default ratio type is really neat compared to floats.

It seems to me that with modern machines, performance is not the first priority. Floats have caused too many surprising, costly, and dangerous bugs. IMO new programming languages should really consider using safer types like decimals and ratios by default, and floats are there for those who want further optimizations.

Could use a round 'to-zero' option (which rounds down on positive numbers and up on negative numbers.)

Here are the options in .net 5:

https://docs.microsoft.com/en-us/dotnet/api/system.midpointr...

Reply on news.ycombinator.com