10 ms·

There is no "better floating point model" because floating point will always be floating point. Fixed point always has been and always will be an option if you

There is no "better floating point model" because floating point will always be floating point. Fixed point always has been and always will be an option if you don't like the exponential notation.

crazygringo 7y ago
> Fixed point always has been and always will be an option Not really. It would be really cool if fixed point number storage were an option... but I'm not aware of any popular language that provides it as a built-in primitive along with int and float, just as easy to use and choose as floats themselves. Yes probably every language has libraries somewhere that let you do it where you have to learn a lot of function call names. But it would be pretty cool to have a language with it built-in, e.g. for base-10 seven digits followed by two decimals: fixed(7,2) i; i = 395.25; i += 0.01; And obviously supporting any desired base between 2 and 16. Someone please let me know if there is such primitive-level support in any mainstream language!
- snickerbockers 7y ago
  You don't need special support from the language, fixed-point arithmetic is effectively the same as integer. DOOM's implementation of fixed-point is a good example which should work on any platform as long as sizeof(int) >= 4. https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/m_fixed.h https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.... https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/m_fixed.c https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.... Addition and subtraction will work normally. Multiplication also works normally except you need to right-shift by FRAC_BITS afterwards (and probably also cast to a larger integer type beforehand to protect against overflow). Division is somewhat difficult since integer division is not what you want to do. DOOM's solution was to cast to double, perform the division, and then convert that back to fixed-point by multiplying by 1.0 before casting back to integer. This seems like cheating since it's using floating-point as an intermediate type, but it is safe to do because 64-bit floating point can represent all 32-bit integers. As long as you're on a platform with an FPU it's probably also faster than trying to roll your own division implementation.
- gpderetta 7y ago
  Writing a fixed point class in C++ is pretty trivial [1]. It would have semantics and performance comparable to integer. Fixed point classes have been proposed many times as addition to the standard library, but have yet to be voted in. [1] see my comment elsethread about trivial problems.
- nwallin 7y ago
  COBOL was created to serve the interests of the financial industry, therefore COBOL has fixed point as a first class data type. Every programming language that has come since has been designed to be a general purpose programming language, therefore they don't include fixed point as a first class data type. Therefore the financial industry continues to use COBOL. Every time someone some tries to rewrite some crusty COBOL thing in the language de jure, they'll inevitably fuck up the rounding somewhere. The financial industry has complicated rounding rules. Or better yet, the reference implementation is buggy and the new version is right, but since the answers are different it's not accepted.

There is no "better floating point model" because floating point will always be floating point. Fixed point always has been and always will be an option if you don't like the exponential notation.

crazygringo 7y ago

> Fixed point always has been and always will be an option Not really. It would be really cool if fixed point number storage were an option... but I'm not aware of any popular language that provides it as a built-in primitive along with int and float, just as easy to use and choose as floats themselves. Yes probably every language has libraries somewhere that let you do it where you have to learn a lot of function call names. But it would be pretty cool to have a language with it built-in, e.g. for base-10 seven digits followed by two decimals: fixed(7,2) i; i = 395.25; i += 0.01; And obviously supporting any desired base between 2 and 16. Someone please let me know if there is such primitive-level support in any mainstream language!

snickerbockers 7y ago
You don't need special support from the language, fixed-point arithmetic is effectively the same as integer. DOOM's implementation of fixed-point is a good example which should work on any platform as long as sizeof(int) >= 4. https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/m_fixed.h https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.... https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/m_fixed.c https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.... Addition and subtraction will work normally. Multiplication also works normally except you need to right-shift by FRAC_BITS afterwards (and probably also cast to a larger integer type beforehand to protect against overflow). Division is somewhat difficult since integer division is not what you want to do. DOOM's solution was to cast to double, perform the division, and then convert that back to fixed-point by multiplying by 1.0 before casting back to integer. This seems like cheating since it's using floating-point as an intermediate type, but it is safe to do because 64-bit floating point can represent all 32-bit integers. As long as you're on a platform with an FPU it's probably also faster than trying to roll your own division implementation.
gpderetta 7y ago
Writing a fixed point class in C++ is pretty trivial [1]. It would have semantics and performance comparable to integer. Fixed point classes have been proposed many times as addition to the standard library, but have yet to be voted in. [1] see my comment elsethread about trivial problems.
nwallin 7y ago
COBOL was created to serve the interests of the financial industry, therefore COBOL has fixed point as a first class data type. Every programming language that has come since has been designed to be a general purpose programming language, therefore they don't include fixed point as a first class data type. Therefore the financial industry continues to use COBOL. Every time someone some tries to rewrite some crusty COBOL thing in the language de jure, they'll inevitably fuck up the rounding somewhere. The financial industry has complicated rounding rules. Or better yet, the reference implementation is buggy and the new version is right, but since the answers are different it's not accepted.