
DEC64 (2014) - tosh
http://dec64.com/
======
jasoneckert
Am I the only one who saw DEC in the title and got excited (perhaps a revival
of the DEC Alpha 64 platform)?!?

~~~
DonHopkins
"If you're not playing with 36 bits, you're not playing with a full DEC!"
-Doug "DIGEX" Humphrey

------
bryanlarsen
Previous:
[https://news.ycombinator.com/item?id=16513717](https://news.ycombinator.com/item?id=16513717)

And that contains links to prior discussions

~~~
acqq
And especially the topmost comment by stephencanon (highlights):

[https://news.ycombinator.com/item?id=16514962](https://news.ycombinator.com/item?id=16514962)

"If you want a default decimal floating-point type, the only defensible choice
is the decimal128 type standardized by IEEE 754. It has a fully-defined
arithmetic, specified by experts who have spent their careers thinking about
the issues involved, and is wide enough to exactly represent the US national
debt in every currency used on earth.

There are situations where other decimal floating-point types are appropriate,
but if you do not understand the tradeoffs you are making, you should be using
decimal128."

and

"I would be remiss not to note that Intel has made available a well-tested
complete implementation of IEEE 754 decimal64 and decimal128 under 3-clause
BSD: [http://www.netlib.org/misc/intel/](http://www.netlib.org/misc/intel/) "

~~~
atemerev
Dec64 is approachable to try to implement it on my own where it is needed the
most (Java/JVM). decimal64/128 is most certainly not.

~~~
acqq
Can’t you link the existing C code by Intel, linked above and BSD licensed?
There’s also GPL licensed one by IBM if you prefer that, linked in my other
post.

No need to use the worse solution, which is dec64, unless you have some very
specific goals.

------
macdice
"A later revision of IEEE 754 attempted to remedy this, but the formats it
recommended were so inefficient that it has not found much acceptance. DEC64
is a better alternative."

This is just plain wrong. The IEEE decimal float types are now in SQL as
DECFLOAT, coming to C and C++, I could go on...

~~~
acqq
> coming to C and C++

[https://raw.githubusercontent.com/libdfp/libdfp/master/READM...](https://raw.githubusercontent.com/libdfp/libdfp/master/README.user)

"libdfp

The "Decimal Floating Point C Library" User's Guide for the GNU/Linux OS and
GLIBC 2.10+

Contributed by IBM Corporation Copyright (C) 2010 - 2014 Free Software
Foundation"

~~~
RustyRussell
I know one of the authors who worked on this; he described it as "decimal
floating" because he insisted "there's no point".

Seems he was right: even IBM didn't do a hardware implementation after Power 6
IIRC.

~~~
macdice
Seems useful to me. Fixed sized data is very convenient for computers (fits in
a register, pass-by-value), and being able to represent 0.1 and 0.01 is very
convenient for humans.

The hardware does seem to be of questionable value; I heard rumours that the
POWER hardware didn't actually beat the Intel software implementation running
on an x86. That doesn't mean that the datatype is worthless.

And it sure as hell doesn't mean that this DEC64 type, which has arbitrarily
incompatible parameters but adds nothing, and is late to the game, is better!

------
peter_d_sherman
This looks absolutely beautiful (from a computer scientist, mathematician's
and aestheticist's perspective)... Future typed programming languages should
include this type!

~~~
snek
Unfortunately this website doesn't talk much about the shortcomings of DEC64.
Just to start, numbers in DEC64 have multiple representations, meaning even a
simple equality check can take tens of cycles. Don't get me wrong, it's a cool
way to store numbers, and it does have purpose, but it is not suited for
general use like IEEE754 is.

~~~
windsurfer
I checked out the reference implementation and although there are some
heuristics to make comparing numbers faster, you're completely right that the
worst case scenario is quite complicated:
[https://github.com/douglascrockford/DEC64/blob/master/dec64....](https://github.com/douglascrockford/DEC64/blob/master/dec64.asm#L1284)

~~~
bonzini
That code is certainly not written by someone with x86 optimization
experience. Using high-byte registers (e.g. ah which he rewrites as r0_h) is
an awful idea on any Pentium Pro or more recent processor.

~~~
pwdisswordfish2
Alternatively: it was written by someone with obsolete x86 optimization
experience.

------
kristianp
This seems similar to the c#/ .net decimal type (1), except the .net type is
128 bits. The c# decimal precedes the IEEE decimal types and isn't the same.

(1) [https://docs.microsoft.com/en-au/dotnet/csharp/language-
refe...](https://docs.microsoft.com/en-au/dotnet/csharp/language-
reference/language-specification/types#the-decimal-type)

------
sprash
Bad idea, better idea:

[https://en.wikipedia.org/wiki/Logarithmic_number_system](https://en.wikipedia.org/wiki/Logarithmic_number_system)

main advantages:

\- no multiple representations of the same number

\- multiplication/division with complexity of addition and subtraction

~~~
hedora
LNS doesn’t seem to meet either of the goals of DEC64:

\- Drop-in replacement for signed integer types for loop iteration, array
indexes, etc (Exact integer operations for 56 (55?) bit addition and
subtraction with 1 cycle overhead; similar efficiency for multiplication)

-Drop in replacement for financial fixed point types (which need to be exact in base-10)

------
waynecochran
Essentially just a base-10 version of floating point. It will work better for
accountants and others performing conventional math done with base 10, but no
fundamental advantage. The problem stems from trying to represent an
uncountably infinite set with a finite set -- at the end of the day you end of
with a very sparse approximation.

~~~
hakfoo
Dismissing it as "better for accountants" feels trivializes the problem.

There's billions of lines of code in circulation dealing with fixed-decimal
currency formats.

The choices have always been:

* Scale things up and down (do your math in cents and convert back to dollars at the last minute), which is an easy opportunity for off-by-2-orders-of-magnitude bugs * Use floating points and pray nobody notices the all but guaranteed errors * Use something like BCD and have to explain it to everyone * Deal with some custom format or language-specific type, kissing portability goodbye, and depending on implementation, possibly poor performance

A well-established decimal-friendly type, whether this, decimal128, or
something else, provides a go-to solution to a very common problem.

~~~
waynecochran
BCD has been around since the earliest CPU's. I get the importance of using
base 10 for finances, but there is nothing new offered here that I can see.

