Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BigDecimal – JavaScript Polyfill for proposed Decimal data type

github.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: BigDecimal – JavaScript Polyfill for proposed Decimal data type

#11

Post by eropple »

throwthere wrote: post #10
dlojudice wrote: post #3

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

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.

Re: BigDecimal – JavaScript Polyfill for proposed Decimal data type

#12

Post by goatlover »

miohtama wrote: post #6
zarzavat wrote: post #4

Earlier quoted context omitted.

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

Re: BigDecimal – JavaScript Polyfill for proposed Decimal data type

#13

Post by namelosw »

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.

Re: BigDecimal – JavaScript Polyfill for proposed Decimal data type

#14

Post by doliveira »

zarzavat wrote: post #4
dlojudice wrote: post #3

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.

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

Re: BigDecimal – JavaScript Polyfill for proposed Decimal data type

#15

Post by bluepizza »

carnitine wrote: post #8
dlojudice wrote: post #3

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

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.

Re: BigDecimal – JavaScript Polyfill for proposed Decimal data type

#16

Post by eyelidlessness »

Osiris wrote: post #5
eyelidlessness wrote: post #2

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

Re: BigDecimal – JavaScript Polyfill for proposed Decimal data type

#17

Post by postalrat »

zarzavat wrote: post #4
dlojudice wrote: post #3

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.

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

Re: BigDecimal – JavaScript Polyfill for proposed Decimal data type

#18

Post by carnitine »

bluepizza wrote: post #15
carnitine wrote: post #8

Earlier quoted context omitted.

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.

Re: BigDecimal – JavaScript Polyfill for proposed Decimal data type

#19

Post by dlojudice »

carnitine wrote: post #8
dlojudice wrote: post #3

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

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

> or computations can be done on the backend

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

Post reply on HN