Skip to content(if available)orjump to list(if available)

DEC64: Decimal Floating Point (2020)

DEC64: Decimal Floating Point (2020)

10 comments

·November 1, 2025

lifthrasiir

Previously:

https://news.ycombinator.com/item?id=7365812 (2014, 187 comments)

https://news.ycombinator.com/item?id=10243011 (2015, 56 comments)

https://news.ycombinator.com/item?id=16513717 (2018, 78 comments)

https://news.ycombinator.com/item?id=20251750 (2019, 37 comments)

Also my past commentary about DEC64:

> Most strikingly DEC64 doesn't do normalization, so comparison will be a nightmare (as you have to normalize in order to compare!). He tried to special-case integer-only arguments, which hides the fact that non-integer cases are much, much slower thanks to added branches and complexity. If DEC64 were going to be "the only number type" in future languages, it had to be much better than this.

spacedcowboy

Atari 8-bit basic used something pretty similar to this [1], except it did have normalization. It only had 10 BCD digits (5 bytes) and 2 digits (1 byte) for exponent, so more of a DEC48 but still… That was a loooong time ago…

It was slightly more logical to use BCD on the 6502 because it had a BCD maths mode [2], so primitive machine opcodes (ADC, SBC) could understand BCD and preserve carry, zero etc flags

[1]: https://www.atarimax.com/freenet/freenet_material/5.8-BitCom...

[2]: http://www.6502.org/tutorials/decimal_mode.html

mgaunard

There are a bunch of different encodings for decimal floating-point. I fail to see how this is the standard that all languages are converging to.

IEEE754 normalizes two encodings, BID and DPD, for decimal32, decimal64 and decimal128 precision presets. This is neither of those.

Many libraries use an approach with a simple significand + exponent, similar to the article, but the representation is not standardized, some use full integral types for this rather than specific bits (C# uses 96+32, Python uses a tuple of arbitrary integers). It's essentially closer to fixed-point but with a variable exponent.

The representation from the article is definitely a fairly good compromise though, specifically if you're dealing with mostly-fixed-point data.

lambdaone

If you want the job done properly, this already exists: https://en.wikipedia.org/wiki/Decimal128_floating-point_form...

pwdisswordfishy

This seems optimized for fast integer operations. Except that if I only cared about integers, I'd use an actual integer type.

cozzyd

Well I suppose it might be preferable if javascript used this type...

sjrd

JavaScript engines do optimize integers. They usually represent integers up to +-2^30 as integers and apply integer operations to them. But of course that's not observable.

cozzyd

The memory savings from 32 bit or even 16 bit floats are definitely not pointless! Not to mention doubling simd throughput. Speaking of which, without simd support this certainly can't be used in a lot of applications. Definitely makes sense for financial calculations though.

null

[deleted]

mildred593

Can't wait to have it in my language!