3 ms·

This seems like the right way to do it. Though, I assume non-suffixed literals are still regular floats?

by heresy 16y ago

masklinn 16y ago
> 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.
- heresy 16y ago
  I'm aware of the performance hit, I just like the approach of a BigDecimal literal instead of having to write that boilerplate.
  - masklinn 16y ago
    > 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')
    - gxti 16y ago
      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.
      - tonyarkles 16y ago
        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.
        gxti 16y 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.
        masklinn 16y ago
        Indeed it has, integers and longs have been unified as a single `int` type, so the external marker is gone as well.
- gtani 16y ago
  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/Concepts.doc.html http://java.sun.com/docs/books/jvms/second_edition/html/Conc...
cemerick 16y ago
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. Though, I assume non-suffixed literals are still regular floats?

by heresy 16y ago

This seems like the right way to do it. Though, I assume non-suffixed literals are still regular floats?

> 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.

heresy 16y ago
I'm aware of the performance hit, I just like the approach of a BigDecimal literal instead of having to write that boilerplate.
- masklinn 16y ago
  > 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')
  - gxti 16y ago
    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.
    - tonyarkles 16y ago
      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.
      - gxti 16y 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.
      - masklinn 16y ago
        Indeed it has, integers and longs have been unified as a single `int` type, so the external marker is gone as well.
gtani 16y ago
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/Concepts.doc.html http://java.sun.com/docs/books/jvms/second_edition/html/Conc...

cemerick 16y ago

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.