4 ms·

Floats are evil. Here's some more fun you can have: int main() { float a = 0x7FFFFFFF; printf("%f %f %f\n", a, a - 64, a - 65); return 0; }

ska 11y ago
Float may be evil, but if so they are often a necessary evil.
- chowells 11y ago
  I dispute "often". I honestly can't think of cases other than certain scientific calculations where they are more appropriate than fixed-point numbers. The fact that scientists had so much input on the early design of hardware and programming languages means that floats are often a performance hack that exchanges semantics for speed. But that's hardly necessary in most applications. And if hardware and language support was better for fixed point numbers, floats would be seen as the bizarre special case that's only appropriate in rare cases.
  - zurn 11y ago
    How big improvements do you feel improved hardware fixed point support could yield, and what form might the improvements take? Imagining for example that Intel decided to make a instruction set extension in their next CPU.
    - jjuhl 11y ago
      I don't know the answer to your question. But if you can get access to a machine with a POWER CPU you could test it, since those CPUs contain hardware fixed-point arithmetic units.
    - chowells 11y ago
      Modern CPUs are already so complex and so fast that I can't imagine the potential speedup would be significant as compared to modern optimized fixed point libraries. Language support is a much bigger issue. Programmers are fundamentally lazy, and will always do the thing that takes the least work (for them, right now). So for fixed point numbers to really be used, that means that they need to be fully first class in the language. Literals need to exist, and with syntax no more complex than it is for other numerical literals. And of course, all operators must use the same syntax for both. This is hard to retrofit into a language. Java and C can't retrofit either in. C++, Python, and Ruby can do operators, but not literals. You have to get into pretty uncommon languages before support for additional numerical types becomes good. Haskell and Scala, for instance, can meet both of the requirements. Given that, I'd say any kind of widespread use of fixed point numbers in the cases where they're more appropriate than floats is at least 30 years away. Maybe 50.
      - anon4 11y ago
        Didn't C++ get support for user-defined literals?
        Someone 11y ago
        Yes. See http://en.cppreference.com/w/cpp/language/user_literal http://en.cppreference.com/w/cpp/language/user_literal
      - jacobolus 11y ago
        You should give some more concrete examples of domains where you think fixed point is more appropriate than floating point, but floats are currently used. As it is, your comment can’t really be discussed or disputed, because it’s just an abstract complaint with no substantive evidence/analysis presented. Here are some areas where I think floats are more appropriate than fixed point, given the availability of CPUs and GPUs with native floating point support: computer game physics, any kind of 3d rendering, 2d vector graphics including e.g. map rendering, high dynamic range image/video editing, most types of statistical analysis, ... I’m having trouble thinking of any applications where I think fixed point numbers seem more appropriate than floats or integers, except code running on embedded devices without native floating point. Audio maybe? Image/video decoding for immediate playback?
        zurn 11y ago
        Floating point is actually a significant source of bugs in 3D graphics and games. And a complex thing you have to constantly keep in mind, taking cognitive resources from other more useful stuff. And a thing you have to code around, increasing the codebase complexity, making changes harder and taking time from programming/debugging/testing useful code. CPUs and GPUs do have support for fixed point (aka integer) data formats, it's been a DX/OpenGL requirement for a while. Though I don't know what API issues you run into if you try to avoid FP altogether.
        shele 11y ago
        Floating point arithmetic is a significant source of bugs. And if you transition to fixed point arithmetic, you will still have a significant source of same-same-but-different bugs (maybe unless you really only need to add things and not never scale or multiply them).
    - DougBTX 11y ago
      Unums could be interesting, more of a GPU answer than a CPU answer though https://github.com/tbreloff/Unums.jl/wiki/Unum-Summary-(in-progress) https://github.com/tbreloff/Unums.jl/wiki/Unum-Summary-(in-p...
      - dnautics 11y ago
        You may want to play with a functioning (still early and being debugged) implementation: https://github.com/REX-Computing/unumjl https://github.com/REX-Computing/unumjl Disclaimer: I'm the author
      - Someone 11y ago
        But how do you make them efficient? If assignment to any variable can grow or shrink its size requirements, I don't see how you can avoid introducing an indirection that will eat your cache locality, or waste storage by making every variable of maximum size "just in case", in which case you are back to using quad floats throughout.
  - ska 11y ago
    This is probably fair - selection bias on my side as I mostly do numerical algorithms.
  - ori_b 11y ago
    > I dispute "often". I honestly can't think of cases other than certain scientific calculations where they are more appropriate than fixed-point numbers. But fixed point numbers have many similar issues, require more thought to find a reasonable significand, and are useful over a far narrower range of values.
david-given 11y ago
Floats are evil. Here's a program: int main(int argc, char* argv[]) { double x = 0.75; double t1 = 0.50000025; int i, j; int n8 = 93 * 100; for (i = 0;; i++) { for (j = 0; j<n8; j++) x = sqrt(exp(log(x) / t1)); printf("%d %f\n", i, x); } } Watch what happens to the performance as i passes 4632. The full saga is here; AFAICT it's a pathological edge case in glibc. https://plus.google.com/118274112180368285367/posts/ZPL5LTK9gpm https://plus.google.com/118274112180368285367/posts/ZPL5LTK9...

ska 11y ago

Float may be evil, but if so they are often a necessary evil.

chowells 11y ago
I dispute "often". I honestly can't think of cases other than certain scientific calculations where they are more appropriate than fixed-point numbers. The fact that scientists had so much input on the early design of hardware and programming languages means that floats are often a performance hack that exchanges semantics for speed. But that's hardly necessary in most applications. And if hardware and language support was better for fixed point numbers, floats would be seen as the bizarre special case that's only appropriate in rare cases.
- zurn 11y ago
  How big improvements do you feel improved hardware fixed point support could yield, and what form might the improvements take? Imagining for example that Intel decided to make a instruction set extension in their next CPU.
  - jjuhl 11y ago
    I don't know the answer to your question. But if you can get access to a machine with a POWER CPU you could test it, since those CPUs contain hardware fixed-point arithmetic units.
  - chowells 11y ago
    Modern CPUs are already so complex and so fast that I can't imagine the potential speedup would be significant as compared to modern optimized fixed point libraries. Language support is a much bigger issue. Programmers are fundamentally lazy, and will always do the thing that takes the least work (for them, right now). So for fixed point numbers to really be used, that means that they need to be fully first class in the language. Literals need to exist, and with syntax no more complex than it is for other numerical literals. And of course, all operators must use the same syntax for both. This is hard to retrofit into a language. Java and C can't retrofit either in. C++, Python, and Ruby can do operators, but not literals. You have to get into pretty uncommon languages before support for additional numerical types becomes good. Haskell and Scala, for instance, can meet both of the requirements. Given that, I'd say any kind of widespread use of fixed point numbers in the cases where they're more appropriate than floats is at least 30 years away. Maybe 50.
    - anon4 11y ago
      Didn't C++ get support for user-defined literals?
      - Someone 11y ago
        Yes. See http://en.cppreference.com/w/cpp/language/user_literal http://en.cppreference.com/w/cpp/language/user_literal
    - jacobolus 11y ago
      You should give some more concrete examples of domains where you think fixed point is more appropriate than floating point, but floats are currently used. As it is, your comment can’t really be discussed or disputed, because it’s just an abstract complaint with no substantive evidence/analysis presented. Here are some areas where I think floats are more appropriate than fixed point, given the availability of CPUs and GPUs with native floating point support: computer game physics, any kind of 3d rendering, 2d vector graphics including e.g. map rendering, high dynamic range image/video editing, most types of statistical analysis, ... I’m having trouble thinking of any applications where I think fixed point numbers seem more appropriate than floats or integers, except code running on embedded devices without native floating point. Audio maybe? Image/video decoding for immediate playback?
      - zurn 11y ago
        Floating point is actually a significant source of bugs in 3D graphics and games. And a complex thing you have to constantly keep in mind, taking cognitive resources from other more useful stuff. And a thing you have to code around, increasing the codebase complexity, making changes harder and taking time from programming/debugging/testing useful code. CPUs and GPUs do have support for fixed point (aka integer) data formats, it's been a DX/OpenGL requirement for a while. Though I don't know what API issues you run into if you try to avoid FP altogether.
        shele 11y ago
        Floating point arithmetic is a significant source of bugs. And if you transition to fixed point arithmetic, you will still have a significant source of same-same-but-different bugs (maybe unless you really only need to add things and not never scale or multiply them).
  - DougBTX 11y ago
    Unums could be interesting, more of a GPU answer than a CPU answer though https://github.com/tbreloff/Unums.jl/wiki/Unum-Summary-(in-progress) https://github.com/tbreloff/Unums.jl/wiki/Unum-Summary-(in-p...
    - dnautics 11y ago
      You may want to play with a functioning (still early and being debugged) implementation: https://github.com/REX-Computing/unumjl https://github.com/REX-Computing/unumjl Disclaimer: I'm the author
    - Someone 11y ago
      But how do you make them efficient? If assignment to any variable can grow or shrink its size requirements, I don't see how you can avoid introducing an indirection that will eat your cache locality, or waste storage by making every variable of maximum size "just in case", in which case you are back to using quad floats throughout.
- ska 11y ago
  This is probably fair - selection bias on my side as I mostly do numerical algorithms.
- ori_b 11y ago
  > I dispute "often". I honestly can't think of cases other than certain scientific calculations where they are more appropriate than fixed-point numbers. But fixed point numbers have many similar issues, require more thought to find a reasonable significand, and are useful over a far narrower range of values.

david-given 11y ago

Floats are evil. Here's a program: int main(int argc, char* argv[]) { double x = 0.75; double t1 = 0.50000025; int i, j; int n8 = 93 * 100; for (i = 0;; i++) { for (j = 0; j<n8; j++) x = sqrt(exp(log(x) / t1)); printf("%d %f\n", i, x); } } Watch what happens to the performance as i passes 4632. The full saga is here; AFAICT it's a pathological edge case in glibc. https://plus.google.com/118274112180368285367/posts/ZPL5LTK9gpm https://plus.google.com/118274112180368285367/posts/ZPL5LTK9...