[HN Gopher] BigDecimal - JavaScript Polyfill for proposed Decima...
___________________________________________________________________
BigDecimal - JavaScript Polyfill for proposed Decimal data type
Author : munrocket
Score : 47 points
Date : 2021-09-03 10:32 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| namelosw wrote:
| 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.
| dlojudice wrote:
| 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
| zarzavat wrote:
| 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 wrote:
| 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 wrote:
| 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.
| goatlover wrote:
| Common Lisp supports actual fractions (integer ratios).
| carnitine wrote:
| 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).
| throwthere wrote:
| 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 wrote:
| 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.
| sradman wrote:
| 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.
| eyelidlessness wrote:
| 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 wrote:
| 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.
| irq-1 wrote:
| 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...
___________________________________________________________________
(page generated 2021-09-04 23:02 UTC)