Hacker News Reader

Comment by tel | Hacker News Reader

It can provide very fast performance on integer values, eliminating the need for a separate int type and avoiding the terrible errors than can result from int truncation.

What! I do not see how making a float fast on integers should ever eliminate the need for an int type. Ints and Real-approximations like Dec64 are simply different things entirely.

It's annoying enough that this happens in Javascript.

View on HN

Why does anybody listen to Crockford? He wrote a human-readable data format but refused to give it comments. He wrote an obnoxious linter that bans continue;. Now he's proposing to replace integers with decimal floating point type (what happens if someone wants to store a 64-bit integer?).

As a C programmer, he just seems off his trolley.

How often have you needed a 64-bit integer where a 56-bit one wouldn't do? I rather like the idea of having only one numeric type.

Still, hardware is inherently base-2. What I'd like to see is hardware assisted adaptive precision predicates and compilers/runtimes that make proper use of modern instructions.

I have never ever thougt that float/double/decimal was too much choice.

As a succinct example, 64-bits is 584 years of nanoseconds. 56-bits is only 2 years of nanoseconds.

The problem is that many extant APIs return 64-bit integers, so if your language only has 56-bit integers you are creating a bug/vulnerability every time you want to talk to the outside world.

e.g. sqlite has sqlite3_column_int64() to get a value from a result set. How do you use that safely if your language can only do 56-bit ints? Ugly.

Remember the "Twitter Apocalypse" when Twitter changed their tweet IDs to be bigger than 56-bits and all the JS programmers had to switch to using strings?

Also, bitboards. Bitboards are cool: https://chessprogramming.wikispaces.com/Bitboards.

EDIT: I also reject the premise that just because there's an ugly hack available, we can get rid of useful language features. Am I working for the language or is the language working for me?

The question is, why do APIs return 64-bit values? In general it's not because they need all 64 bits, it's because the 64-bit integer type is convenient for them. This might make Crockford's proposal completely impractical but it doesn't invalidate the argument that led to it.

I reject the nanosecond example because it's completely arbitrary. 64 bits of picoseconds would only cover 0.584 years so should we claim 64 bits isn't enough? Wouldn't 2000 years of microseconds in 56 bits be good enough?

I'll give you credit for bitboards though, that's one I hadn't considered.

>Now he's proposing to replace integers with decimal floating point type

Why is that so bad? JavaScript did it.

I would suggest that's a strong indicator that it is bad.

Wrong. JavaScript has a binary floating point type.

This is proposing a decimal floating point type.

Which is actually not a bad idea. This "specification" is, however, laughable. Especially since there are quite good decimal floating point specification out there that he could have just stolen^H^H^Hborrowed from.

I stand corrected. I somehow read that as 'replace integers with floating point type'.

Which is not bad if that floating point type is decimal. All of your integers do what they're supposed to. In addition, things like the standard programming fail of using "i += 0.1;" as a loop iterator actually work when you use decimal floating point.

Also, things like converting to/from strings become operations with a priori bounded limits just by taking a quick look at the number of digits if you have decimal floating point.

This is not true for binary floating point. There is a reason why printf libraries are so blasted huge and have malloc issues--it's the binary floating point conversions.

Much of the stupidity we encounter in dealing with floating point (inexact numbers on exact decimals, silly rounding, inability to handle significant figures, weird conversion to/from strings) simply goes away if you use decimal floating point.

In addition, if you go back through the ECMAScript archives, they actually thought about this back in ECMAScript4 but rejected it for some good reasons. I don't agree with those reasons, but they did think about and discuss them.

Integers are also exactly represented in the standard floating point formats, so this isn't even a particular advantage of DEC64.

What is "int truncation" anyway? Overflow?

I believe he means the stuff that happens in js like 111111111111111110000 + 1111 = 111111111111111110000;

EDIT: not a javascript specific thing, rather a float one, methinks

To clarify, they are basic floating-point errors from C that happen to be errors for integers as well in Javascript, because Javascript does not support fixed-precision integers.

I know the author despises types, but sometimes types provide valuable semantic information. Like, indexing into an array using a float is completely unnecessary and meaningless.

It's not completely unnecessary and meaningless. In computer graphics, floating point indexing is used to interpolate between texel values during texture look-up.

Interesting. A weighed average between at least two values in an array? Makes sense in the context of computer graphics. Thanks for the correction.

I don't typically think of it as indexing an array, but it's conceptually similar in some circumstances I suppose. The hardware still eventually has to read values from integer-based addresses, though. As to the details:

Sampling modes customize how the value calculation is done. Some will simply round the index to the nearest integer texel, resulting in only one value being accessed (cheap.)

Others will interpolate via weighted average as you're thinking, in the 1D case. Then there's the 2D and 3D cases... plus mipmaps... plus anti-aliasing patterns... at which point you could easily have 16+ samples bearing little resemblance to "indexing an array", especially as one can apply all these interpolation techniques to generic functions such as perlin noise which aren't array based.

And each of those sampling methods is exactly a function

    Double -> Int

Which is also exactly why having an int type is important. It otherwise becomes much harder to talk about the meaning of those functions.

I do not see any basis for the statement 'very fast performance on integer values', given that simple calculations like substraction and checking of simple equality require many operations in the proposed standard.

Reply on news.ycombinator.com