BigDecimal – JavaScript Polyfill for proposed Decimal data type

BigDecimal – JavaScript Polyfill for proposed Decimal data type(github.com)

53 points by munrocket 4 years ago | 18 comments

dlojudice 4 years ago |

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

sradman 4 years ago | |

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.

carnitine 4 years ago | |

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).

bluepizza 4 years ago | | |

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.

dlojudice 4 years ago | | |

> or computations can be done on the backend

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

zarzavat 4 years ago | |

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.

doliveira 4 years ago | | |

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

miohtama 4 years ago | | |

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.

postalrat 4 years ago | | |

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

throwthere 4 years ago | |

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.

eropple 4 years ago | | |

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.

eyelidlessness 4 years ago |

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.

Osiris 4 years ago | |

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.

eyelidlessness 4 years ago | | |

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”.

namelosw 4 years ago |

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.

irq-1 4 years ago |

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...