Hacker News Reader

Comment by throw0101c | Hacker News Reader

I was under the impression that BCD was generally recommended for money, often because of (IEEE?) rounding and machine precision/epsilon:

* https://en.wikipedia.org/wiki/Binary-coded_decimal

* https://en.wikipedia.org/wiki/Machine_epsilon

View on HN

BCD is better than IEEE 754 floating point, but simple integers with an implied decimal point is much better than either of those.

BCD makes stored value -> human-readable trivial, at the cost of complicating math on those values.

So it's useful for applications where you're mostly doing human input/output <-> stored value.

But as soon as you do any non-trivial math on those values, using (fixed point?) integers wins. At the cost of a simple stored value <-> human readable conversion.

I'd think most financial applications fall into the category "do math, so integers win over BCD".

I honestly don't understand the argument here or the parent comment makes.

Why is a BCD decimal 128 worse at math then a fixed point integer? You are saying it is more CPU efficient? Are you saying some operations with fixed point integer math operations are more accurate then dec128?

I've seen this asserted several times, both in the post and in comments, but I've never seen a single concrete example of it being better. Can someone provide an example?

Most CPUs don't have BCD math instructions, so you need multiple instructions, with probably around a 10-100x slowdown in math.

Do you know what BCD is? If you did, it becomes pretty obvious why BCD is significantly slower than fixed point integers.

I know what BCD is, I know they are slower.

What I was asking for is, when they said it was just "better", are they specifically saying "CPU computations is a bottleneck, thus BCD is not as good as fixed point integers"? Which is fine if it is, I just would like that to be stated clearly. In my line of work, BCD CPU is NEVER the bottleneck, it never will be, and it is likely that the time it takes for a CPU to compute the BCD operation it will still be stalling on pref etching the next instruction from main memory anyway.

But maybe, for their specific ledger specific database, it is better. If so, show the benchmark, and how it impacted their specific code. But don't expect me to just take fewer CPU instructions for math operations to directly translate to more desirable.

While IEEE 754 does have curiosities, the 1/10 problem the article points out isn't really addressed by anything mentioned in the article (or here). BCDs have exactly the same problem with e.g. 1/3.

What you really want is a rational (fractional value: numerator and denominator) of some form.

no, integers are generally used. BCD is fixed-point in any case so it's just an inefficient integer representation.

I'm under the impression that people use decimal floats from IEEE 754-2008, which is Crenshaw's General Decimal Arithmetic at https://speleotrove.com/decimal/decarith.html .

As I understand it, the regulations related to money can require specific rounding modes and a specific number of digits for intermediate representations. These are much easier to manage with, eg, Python's decimal module than doing everything as integers.

For example, at https://news.ycombinator.com/item?id=36687627 I pointed to US law at https://www.law.cornell.edu/cfr/text/7/1005.83 with:

  (3) Divide the result in paragraph (a)(2) of this section by 5.5, and round
  down to three decimal places to compute the fuel cost adjustment factor;

  (4) Add the result in paragraph (a)(3) of this section to $1.91;

  (5) Divide the result in paragraph (a)(4) of this section by 480;

  (6) Round the result in paragraph (a)(5) of this section down to five decimal
  places to compute the mileage rate.

why add the complexity of bcd when you can just put in it units (e.g. cents) where there's no decimal point?

What do you do if heavy deflation causes the government to release a $0.001 coin? A cent isn't a fundamental unit.

Edit: as another hypothetical, what if the $0.001 coin is released to support micropayment use cases?

Actually that would break so many things (the cent as the smallest unit in law and in custom where that is currently the case) that governments may by preference issue a whole new currency instead of stir that pot.

I thought the smallest unit in the US was the mill. https://en.wikipedia.org/wiki/Mill_(currency)

> https://www.law.cornell.edu/uscode/text/31/5101 says "United States money is expressed in dollars, dimes or tenths, cents or hundreths,[1] and mills or thousandths. A dime is a tenth of a dollar, a cent is a hundredth of a dollar, and a mill is a thousandth of a dollar."

> [1] So in original. Probably should be “hundredths,”.

About the only time you see values given in mills is with gas prices, like $4.999/gal, though often denoted as tenths of a cent. It's also indirectly used in property taxes.

This year on our local ballot there is a tax levy to approve an increase to the property tax by 5 mills per 100,000 dollars of assessed property value. Allegedly allowing them to raise a few million over the next 10 years to pay off an addition to the school.

These systems use something like 10^-8 as the implied decimal in the real world. Some forex exchanges even go to 10^-9

Fiat currency can go to -4 i think, crypto currency going to -18. And that's whole units like cents P.S. crypto things are using uint256 internally, and this type don't exist in most languages. Using int64 can work out, sometimes, and will usually break soon enough

In a situation like that I think it would be better to have the system not work until it’s fixed than to potentially lose precision and work with untested inputs

Worth noting that hyperdeflation has never happened, which is kind of interesting because it theoretically could.

I believe that economists generally think that a small amount of inflation is good for the economy, and that deflation is bad (because it leads to reductions in spending and investment, potentially causing a vicious circle). It's also relatively easy to counteract - just print more. In order for hyperdeflation to occur you'd need a currency where the issuing body didn't believe deflation was bad, or didn't care.

Bitcoin has a hyper deflationary monetary policy hard coded in.

Yup, and as a result, nobody wants to actually treat it as the digital currency that it was originally set out to be.

Anybody who truly thinks Bitcoin could hit $100K value certainly doesn't want to spend them.

It's not really symmetric. It's not hard to imagine a situation where everyone stops believing something (a currency) is not worth anything anymore. But why would somebody believe that nothing except currency is not worth anything?

Not sure what exactly you call hyperdeflation, but something like that has occurred in communist Czechoslovakia in 1953.

https://cs.wikipedia.org/wiki/%C4%8Ceskoslovensk%C3%A1_m%C4%...

I think you could easily convert every stored value to the new unit of measure by multiplying by an appropriate factor. In your example that would mean multiplying all the old values by 10. But when you're designing such software, you could also be conservative and use a smaller unit than cents (which probably many financial sw already do, as you already have things considering fractions of cents like gasoline prices).

Different currencies already have different rules. Any good accounting software isn't going to assume US cents. Update your currency table to include a version of USD in increments of $0.001. Update the amounts on a need-be basis. ( Multiply by 10 and change the currency type)

Division. 1/x is a common operation in finance (particularly in trading), and you'll get all sorts of trouble if you try to express everything in cents.

So, you'll need subpenny fractions (e.g. 8 decimal points), or BigDecimal, or decimal-normalized floats.

Because it is very common to need to deal with fractions of a cent in intermediate calculations.

Decimal float has a larger range and a more natural representation when debugging than fixed point. Either way works well though.

Every financial system I've seen uses either decimal floating point or integers. Using normal float is just asking for trouble.

I've seen floats for money in production, not a financial system per se, but it moved amounts around external systems that often would include some financial ones. It worked surprisingly well given the amounts involved (anywhere from tens to thousands of EUR/USD), and when I asked about the off by +-0.01 errors every now I was told they were "not worth fighting by the customers".

Most customers may not care, but reports and automated processes likely will when a customer is 'in debt' thanks to small differences, and the tax authority in certain countries also care when the sum of the differences is large enough.

Float can be justified where performance is more important than accuracy. Which does happen sometimes in the financial world.

I've never seen anyone use floating point for money in their bespoke applications

You _can_ use floating point if you are very careful and know what you are doing and know about decimal normalization (see e.g. OpenHFT implementation for high-frequency trading: https://github.com/OpenHFT/Chronicle-Core/blob/ea/src/main/j...)

But if you are not an expert, you better stick to BigDecimal and absorb the performance costs.

Nice share! Interesting sorcery in their code:

> final double residual = df - ldf + Math.ulp(d) * (factor * 0.983);

Every banking client did use double for the actual calculation phase of their derivatives trades.

(And some of our back-end systems then did ludicrous broken wrong-headed rounding to turn them into fictional currency values... Ho hum.)

QuickBooks almost certainly used float in the early versions of their currency conversion. We saw lots of accumulated rounding errors that really couldn't be explained any other way.

That was maybe 15 years ago - hopefully they've fired that programmer and fixed it in the meantime. We don't know, because we don't use QuickBooks any more.

Nubank used floating point - not in their real backend systems, but somewhere in their app. It was a bit amusing when people on Twitter found out certain very specific, arbitrary-looking amounts were not able to be transferred, then the computer scientists noticed what they had in common.

Count yourself lucky.

I worked on some software in the past where I converted double to C#'s decimal type. Unfortunately it wasn't so easy on the shop's old php stuff, but there I was more concerned with fixing their SQL injection issues rather than their rounding errors

Reply on news.ycombinator.com