Dec64: Decimal Floating Point (2020)

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.

People routinely have trouble picking ints for monetary amounts, leading to all kinds of lovely rounding errors.

There's something to say for languages like Python and Clojure were plain ordinary math might involve ordinary integers, arbitrary precision integers, floats or even rationals.

In grad school it was drilled into me to use floats instead of doubles wherever I could which cuts your memory consumption of big arrays in half. (It was odd that Intel chips in the 1990s were about the same speed for floats and doubles but all the RISC competitors had floats about twice the speed of doubles, something that Intel caught up with in the 2000s)

Old books on numerical analysis, particularly Foreman Acton's

https://www.amazon.com/Real-Computing-Made-Engineering-Calcu...

teach the art of how to formulate calculations to minimize the effect of rounding errors which resolves some of the need for deep precision. For that matter, modern neural networks use specialized formats like FP4 because these save memory and are effectively faster in SIMD.

---

Personally when it comes to general purpose programming languages I've watched a lot of people have experiences that lead them to thinking that "programming is not for them", I think

   >>> 0.1+0.2
   0.30000000000000004

is one of them. Accountants, for instance, expect certain invariants to be true and if they see some nonsense like

   >>> 0.1+0.2==0.3
   False

it is not unusual for them to refuse to work or leave the room or have a sit-down strike until you can present them numbers that respect the invariants. You have a lot of people who could be productive lay programmers and put their skills on wheels and if you are using the trash floats that we usually use instead of DEC64 you are hitting them in the face with pepper spray as soon as they start.

IEEE 754 is a floating point standard. It has a few warts that would be nice to fix if we had tabula rasa, but on the whole is one of the most successful standards anywhere. It defines a set of binary and decimal types and operations that make defensible engineering tradeoffs and are used across all sorts of software and hardware with great effect. In the places where better choices might be made knowing what we know today, there are historical reasons why different choices were made in the past.

DEC64 is just some bullshit one dude made up, and has nothing to do with “floating-point standards.”

The set of real numbers is continuous and uncountably infinite. Any attempt to fit it into a discrete finite set necessarily requires severe tradeoffs. Different tradeoffs are desirable for different applications.

Well, for one thing, IEEE-757 was a significant improvement on the vendor-specific ways of handling floating point that it replaced ( https://people.eecs.berkeley.edu/~wkahan/ieee754status/754st... ).

I wasn't a big fan of floating point until I worked with a former college professor who had taught astrophysics. When possible, he preferred to use respected libraries that would give accurate results fast. But when he had to implement things himself, he didn't always necessarily want the fastest or the most accurate implementation; he'd intentionally make and document the tradeoffs for his implementation. He could analyze an algorithm to estimate the accumulated units in the last place error ( https://en.wikipedia.org/wiki/Unit_in_the_last_place ), but he realized when that wasn't necessary.

Can you be more specific?

How would fix the standards, or if your point is about having too many, which one would you choose as the _one_?

I do think DEC64 has merit: Most of the time, I'd prefer to be able to reason about how non-integers are handled; and I just can't reason about traditional floating point.

Yes, Doug does bloviate quite a bit. (And when I asked him if there was a way to make callbacks in Node.js / Javascript simpler, he mocked me. A few years later, "await" was added to the language, which generally cleans up callback chains.)

He literally says he "discovered" it!?!?! https://nofluffjuststuff.com/blog/douglas_crockford/2008/01/...

...primary source: """I do not claim to have invented JSON. I claim only that I discovered it. It existed in nature. I identified it, gave it a name, and showed how it was useful. I never claimed to be the first to have discovered JSON. I made my discovery in the spring of 2001. There were other developers who were using it 2000."""

I see value in this semi-simplistic representation of DEC64, and to respond to a peer comment, consider "DEC64-norm", where non-normalized representations are "illegal" or must be tainted/tagged/parsed like UTF-8 before processing.

His other "useful" contribution which I lament not seeing anywhere else is "The Crockford Keyboard" another "near-discovery" of existing useful properties in an endemic standard (the English alphabet): https://www.crockford.com/keyboard.html

I really wish that the X-Box onscreen keyboard used this layout! You could imagine that if you could "hot-key" back to the left row (vowels), and have "tab-complete" (ie: shift-tab/tab) it could be a pretty comfortable typing experience compared to the existing "let's copy QWERTY(?!)".

...I feel him as a kindred spirit of pragmatism and complexity reduction (which necessarily) introduces more complexity since we live in a world where complicated things exist. Compared to IEEE floating point numbers, this DEC64 or "Number()" type seems like a breath of fresh air (apart from normalization, as mentioned!).

Decimal128 has exact rounding of decimal rules and preserves trailing zeros.

I don’t think Decimal64 has the same features, but it has been a while.

But unless you hit the limits of 34 decimal digits of significand, Decimal128 will work for anything you would use fixed point for, but much faster if you have hardware support like on the IBM cpus or some of the sparc cpus from Japan.

OPAP Agg functions as an example are an application.

I'm pretty confident that dfp is used for financial computation. Both because it has been pushed heavily by IBM (who certainly are very involved in financial industry) and because many papers describing dfp use financial applications as motivating example. For example this paper: https://speleotrove.com/decimal/IEEE-cowlishaw-arith16.pdf

> This extensive use of decimal data suggested that it would be worthwhile to study how the data are used and how decimal arithmetic should be defined. These investigations showed that the nature of commercial computation has changed so that decimal floating-point arithmetic is now an advantage for many applications.

> It also became apparent that the increasing use of decimal floating-point, both in programming languages and in application libraries, brought into question any assumption that decimal arithmetic is an insignificant part of commercial workloads.

> Simple changes to existing benchmarks (which used incorrect binary approximations for financial computations) indicated that many applications, such as a typical Internet-based ‘warehouse’ application, may be spending 50% or more of their processing time in decimal arithmetic. Further, a new benchmark, designed to model an extreme case (a telephone company’s daily billing application), shows that the decimal processing overhead could reach over 90%

Wonder if it depends on which side of banking: investments, accounting, clients side (web pages, and ui) vs the backend. Or if we're talking about central banks vs a small credit union.

That’s not too surprising to me, I imagine that many number types are used, and it depends entirely on the task at hand? If you have deeper knowledge of what gets done in practice, I’m still curious what criteria and types and how many decimal points might get used in the most restrictive cases. What do people use in practice for, say, interest compounding on a trillion dollars? I can calculate how many decimal places I need at a minimum for any given transaction to guarantee the correct pennies value, but I don’t have first-hand experience with banks and I don’t know what the rules of thumb, or formal standards might be for safe & careful calculation on large sums of money. I would imagine they avoid doing floating point analysis in every case, since that’s expensive engineering?

The noob-expert meme is really apropos here, as floating-point is really the option to go for if you know nothing about it or you know a lot about it.

The "problem" with floating-point is that you have to deal with rounding. But in financial contracts, you have to deal with rounding modes. Fixed-point (aka integers) gives you one rounding mode, and that rounding mode is wrong.

> I have never seen a Money type nor anything like DEC64 in a real commercial system, its all floats or ints/longs for pennies.

I've been working in ERP land for a long time working with many different commercial systems of different sizes and market share and I've only seen NUMERIC/DECIMAL types used in DB for things like Price, Cost, Amount etc.

The only time I've ever seen floating point is for storage of non-money type values, like latitude and longitude of store locations.

Examples of a few top systems:

SAP - Packed decimal

Oracle NetSuite - Decimal

Microsoft Dynamics - Decimal/Numeric

Infor - Decimal/Numeric