News for hackers. Stuff that matters.
Re:Yet another alternative to floating-point numbers by riggsdk on Saturday October 31, 2020 @11:55PM (#24957112)
Why isn't it more widely used to "simply" use 64bit integers behind the scenes and then chose some (possibly user-defined?) precision? If you for example treat a 64-bit unsigned integer as a measure of length/distance in nanometers then you can measure distances up to 18.446.744 kilometers. If you chose micrometers as your smallest unit then you get to ~17 light hours (two times the diameter of neptune's orbit (thanks Wolfram Alpha). Wouldn't it be better with a value representation that is more predictable like that? You are guaranteed a precision to however many decimal places that you see fit for your specific task and you don't have to worry about all sorts of pitfalls regarding the internal representation. Algorithms to display these values in human readable form becomes trivial as well.
Re:Yet another alternative to floating-point numbers by qppo on Sunday November 01, 2020 @12:37AM (#24957259)
The problem comes when you need to mix precision and now all your multiplication and division needs to keep track of the decimal point through the computation. This isn't terribly uncommon, usually when your computation needs much wider range than your input and output. Exponentials and logarithms are bad about this.

So what you do is either keep track of the precision manually in your call stack, but then you get the bright idea to pass it as data along with your integer. And you don't need 64 bits of precision because that's a lot, you can live with 52 and use the extra bits to hold your exponent. And lo and behold you've discovered floating point.

Re:Yet another alternative to floating-point numbers by nullc on Sunday November 01, 2020 @03:30AM (#24958037)
> If you for example treat a 64-bit unsigned integer as a measure of length/distance in nanometers then you can measure distances up to 18.446.744 kilometers.

If your calculations require you be able to square any of that unit, the largest you can go without running out of range in your intermediate calculations is cut to ... 4 meters. God help you if you need a higher power than 2.

Same deal for taking the product of several numbers for an area or volume.

Working in fixed point has its benefits and it has its costs. Not so unlike manual memory management, but automatic memory management doesn't benefit so much from amazing hardware acceleration that you miss out on with manual management.

Re:Yet another alternative to floating-point numbers by carlmr on Sunday November 01, 2020 @02:56AM (#24957895)
It's very common in embedded systems, especially where you need safety and reliability, which are very strongly intertwined with predictability of computation errors.

If you look at ADA, a language made for safety critical systems programming, it has even a very nice abstraction for these:

https://www.adaic.org/resources/add_content/standards/05rm/h...

Re:Yet another alternative to floating-point numbers by w0utert on Sunday November 01, 2020 @06:02AM (#24958663)
Also very common in embedded systems that simply do not have any floating point capabilities at all. For my CS dissertation I had to implement part of an OpenGL pipeline on a VLIW DSP designed for video coding, and all it had was 32-bit integer ALU’s. Dealing with dynamic range was pretty much half of the total effort to map the reference code that used floating point to fixed point with mixed precision.
Re:Yet another alternative to floating-point numbers by flohofwoe on Sunday November 01, 2020 @08:01AM (#24959183)
For the "user defined precision" part it would be convenient to use a few bits to store where the point is located in such a fixed-point number, and that's essentially reinventing floating point numbers ;)
Re:Yet another alternative to floating-point numbers by sesuximo on Sunday November 01, 2020 @12:24AM (#24957215)
people use fixed point all the time. I think it’s just easier to start using floating point numbers without thinking about it and it works like 80% of the time
Re:Yet another alternative to floating-point numbers by bobowzki on Sunday November 01, 2020 @01:06AM (#24957531)
Fixed point is very common, at least in some areas.
Re:Yet another alternative to floating-point numbers by MaxBarraclough on Sunday November 01, 2020 @06:50AM (#24958843)
GCC has some support for fixed-point arithmetic, as an extension to the C language. Unfortunately only a very few target architectures are supported, not including AMD64. [0] (Unfortunately this page doesn't list which architectures are supported.)

As carlmr mentioned, the Ada language has built-in support for fixed-point arithmetic types.

[0] https://gcc.gnu.org/onlinedocs/gcc/Fixed-Point.html

Re:Yet another alternative to floating-point numbers by flohofwoe on Sunday November 01, 2020 @08:08AM (#24959236)
You don't need special compiler support for fixed-point-math, just left- and right-shift to "move the point around".