Hacker News Reader

Check out C#'s decimal type.

https://learn.microsoft.com/en-us/dotnet/api/system.decimal?...

Thanks, it's been forever since I've used C# so glad to know this exists, and seems like the ideal implementation.

Really wish JS had added first class support for a bigdecimal class before bigint. After all, the first is basically a superset of the latter.

Came here to make this exact same comment, including the "I love TS but wish it wasn't built on JS" sentiment. I explored Rust recently and was disappointed to see there's no stdlib Decimal, but instead there are multiple community implementations - so I'd have to sort through and vet the right one.

It's surprising that none of the popular high level languages that borrow so much else from Lisp haven't borrowed its rational number type. Really the whole numeric tower makes a ton of sense, and you can always declare floats if needed.

Thanks for the encouragement to look up lisp's numeric tower (https://en.wikipedia.org/wiki/Numerical_tower), that was interesting to compare to the languages I'm more familiar with.

What about Julia? It's somewhat popular and heavily inspired by Lisp. It has a type tree that's reminiscent of Lisp's numerical tower: https://global.discourse-cdn.com/business5/uploads/julialang...

Rationals are not really great for a long series of calculations. E.g. imagine taking the average of a bunch of numbers like 1.15542345089. It will blow up your CPU usage to stratospheric levels.

Including Lisp. Not every Lisp dialect has rationals.

Unless you're dealing with billions and care about pennies then using float for money is fine in 99% of cases.

That's absolutely, 100% false. Trivial example (I've actually hit an analogous bug in production): User has money in their wallet, and you want to check before they make withdrawals that their balance doesn't go negative. You have some logic in your code that is basically like:

    if (walletBalance - sumOfWithdrawals < 0) { throw new Error('overdrawn); }

Try that code in Javascript where walletBalance = 0.3 and the sumOfWithdrawals = 0.2 + 0.1.

Point being there are tons of operations in the financial world where you check things against 0, or want to ensure that a breakdown of smaller transactions equals a larger amount. Those all can fail with floating points but succeed with decimals.

That's only true if you know that you have to round everything to the second digit. If you have a user calculating the total cost of buying something that is $7.10 and something that is $10.20, you don't want to show them $17.299999999999997. You would be better off storing everything as an integer of pennies and just displaying the dot in the frontend. To be fair, I also think that high level languages should come with types for all the major currencies.

I'm an expert programmer and I agree with downvoted IshKebab. This is just HN having a Reddit moment.

IEEE 64 bit floats are accurate to just past 15 decimal digits. For ordinary monetary amounts, the exact figure in cents is approximated with ridiculous precision. If you rub two pennies together, you are likely causing more of a difference in the amount of copper than the IEEE 64 bit float causes in the value.

You have to do many, many additions and multiplications before you get a result which has accumulated so much error that it is now closer to the wrong penny. E.g. if you don't deal with dollar amounts more than 7 figures, you have about 8 places past the decimal point; you need something like a 6 place error before the penny is affected.

You can counteract this problem by correcting intermediate results to that floating-point value which is closest to exact penny result. In other words, throughout your calculation, you truncate away the difference between the result, and the best approximation of the dollar and cent value.

Within this framework, you can implement all required rounding rules, too. You can take a floating-point result representing a fraction of a penny and round it according to banker's rule to the penny.

Of course, you can't just ignore the issue and just blindly use floating-point for money in a serious accounting system; but that's a strawman version of using floating-point for money.

Also, Microsoft Excel uses floating point. See here:

https://learn.microsoft.com/en-us/office/troubleshoot/excel/...

Vast armies of people rely on Excel for financial calculations.

Since you're an expert, I'm sure you won't mind these corrections:

> IEEE 64 bit floats

That should be IEEE 64-bit floating-point. The name `float` is a 32-bit floating-point.

> are accurate to just past 15 decimal digits.

FOR SOME RANGE. They're called floating-point because they can modify how much scaling is devoted to either side of the decimal point. The more scale it has to devote to representing whole portion, the lower its precision in the fractional portion. At some point, a 64-bit floating-point value cannot represent any decimal digits. Past around 2^53, a `double` 64-bit floating-point value cannot even represent every whole number, because at that point the available precision is 2 or more.

A "float" is 32 bit floating-point in the C language, yes.

If I say "64 bit float", it's obviously not that one.

Here is CLISP:

  [1]> (type-of 3.0)
  SINGLE-FLOAT
  [2]> (type-of 3.0d0)
  DOUBLE-FLOAT

Python3:

  >>> type(3.0)
  <class 'float'>
  >>> type(3.0e300)
  <class 'float'>

Looks like it's calling the 64 bit ones just float.

Rust has f32 and f64. Some historic languages have used type names like REAL and DOUBLE and others.

"IEEE 64 bit float" is almost unambiguous; it could be the binary one or the decimal one.

IEEE uses identifiers like binary64, decimal32, if you want to be pedantic, and not float and double.

> FOR SOME RANGE ...

Your comment is seems to be based on the wrong idea of what the number of digits means. An IEEE 64 bit binary float stores 15 significant digits without loss. In that C language that gives us the float type, the preprocessor constant DBL_DIG has a value of 15 (on IEEE floating point platforms).

This is a 15 digit number using E notation (in terms of digits of precision / significant figures):

  1.23456789012345E-20

So is this; it is not a 16 digit number:

  123456789012345.0

And so is this isn't a 17 digit one:

  12345678901234500.0 (same as 1.23456789012345E16)

You have to write the number in exponentatial notation, and chop the trailing zeros. Then count the remaining number number of digits in the mantissa part.

I think it's only for subnormal numbers that the 15 rule breaks down; but I might have mentioned that. These are special representations close to zero beyond what is reachable with the regular exponent and mantissa, which have the benefit of certain desirable behaviors in underflow situations.

I don't think experts like pointless and incorrect pedantry anymore than anyone else. Well maybe a little more because they can easily put you in your place. :)

> You have to do many, many additions and multiplications before you get a result which has accumulated so much error that it is now closer to the wrong penny

> You can counteract this problem by correcting intermediate results to that floating-point value which is closest to exact penny result

The argument seems to be "floats are okay, as long as you're careful", but forgetting to round the number in between a large number of operations is a probable mistake.

Using decimals would make such a mistake impossible.

Even with a decimal representation, there are situations where you have to remember to round to a cent.

Decimals are software libs; what could go wrong?

More people use the floating-point instructions of a popular CPU than any given decimal library.

If you're starting from scratch, it's probably a lot less work to write (test and debug) a Money class based on floating-point, whose overloaded math operations do the required rounding (so that code using the class cannot forget) than to make a Money class based on decimal arithmetic.

(The last time I wrote an accounting system, I made a Money class based on integers. It could be retargeted to other representations easily. I could make the change and compare the ledger totals and other reports to see if there is a difference.)

> Decimals are software libs; what could go wrong?

Bugs in libraries do exist, but it's much easier to fix a bug in one place, than to track down every single line where floating point operations could misbehave.

> More people use the floating-point instructions of a popular CPU than any given decimal library.

Perhaps, but how many of the former are in a position to notice accuracy issues? I have more faith in a reputable decimal library than your average FPU, frankly.

You can use floating-point for money even if you're dealing with (American) billions (10 figures), and care about pennies. With 10 figures in the integer part, you have 5 more digits of precision in the fractional part, so down to the thousandths of a cent. A single addition or multiplication will not accumulate an error which affects the cent, and you can round the calculation to the best approximation of the penny in order to clip off the error.

JSON specifies the grammar of numbers as tokens, but not the behavior of how they should be parsed. Implementors could choose to parse numbers as decimals without violating the spec.

I agree with you, but there's theory and then there is reality. The JSON spec is famously "underspecified" in that it pretty much ONLY specifies the token grammar but nothing with respect to interpretation, and hence there are lots of areas which have been problematic for years - the spec even says this with respect to object keys:

> The JSON syntax does not impose any restrictions on the strings used as names, does not require that name strings be unique, and does not assign any significance to the ordering of name/value pairs. These are all semantic considerations that may be defined by JSON processors or in specifications defining specific uses of JSON for data interchange.

So, in reality, the JSON "spec" is really how the most popular implementations interpret it. I'm not aware of a single implementation (though I could most definitely be wrong) that interprets number tokens as anything but floats/doubles by default.

In practice, it is usually easier to use the parser that came with your language(s) and figure out a different way to encode the values that are causing trouble, instead of writing a new parser.