Hacker News Reader

Comment by heresy | Hacker News Reader

This seems like the right way to do it.

Though, I assume non-suffixed literals are still regular floats?

Yes; insofar as maximal perf is a desirable default characteristic, `0.2` must continue to be a regular decimal value (technically, a double in Clojure). We've already been down the path of having to extensively hint Clojure code to get the best perf, and we'll likely not revisit that.

That said, the above notation makes advice to those who are having trouble a lot easier.

> This seems like the right way to do it.

It's also slow as molasses, which is why very few languages default to decimal floats and use IEEE floats (or doubles) instead, via their hardware implementation. The behavior of IEEE floats and doubles is very well defined, and though they are unfit in some sectors (you do not want to count money using them), have to be massaged a bit when displayed and don't deal well with great differences in powers-of-10 (e.g. 1e21 + 1 == 1e21) they work well enough in practice. And they're implemented in hardware.

I remember reading that Java has one difference from IEEE754 that might bite somebody once in a while: floating point modulo. But I can't find a reference

Seems like other delta's (e.g. how many NaN's are implemented) don't much matter.

http://java.sun.com/docs/books/jvms/second_edition/html/Conc...

I'm aware of the performance hit, I just like the approach of a BigDecimal literal instead of having to write that boilerplate.

> I just like the approach of a BigDecimal literal instead of having to write that boilerplate.

Ah yes. Well not all languages require a bunch of boilerplate either. In Python for instance, there is a type decimal.Decimal which you can just alias to `d` and write:

    val = d('0.1')

I do wish there were a syntax for Decimal literals, e.g. 0.1D (analogous to 100L as long, etc.). Maybe I'll make it my weekend project even if I don't really expect it to be accepted into CPython proper.

I'm pretty sure the L syntax has gone away in Python3, with numbers being auto-promoted to Long if they're going to overflow. I'm a bit hazy about this, but I think I talked to the maintainer over lunch at PyCon two years ago.

There's actually no externally-visible long type at all in Python 3, it's all done transparently now. That said, I'm not using Python 3. The promoting behavior you speak of is how Python 2 works.

Indeed it has, integers and longs have been unified as a single `int` type, so the external marker is gone as well.

Reply on news.ycombinator.com