Many simulations and gaming are both better off using fixed point. The range available with a 64-bit integer is staggering and precision varying with distance from an arbitrary origin is a bug, not a feature for those cases.
The range available with 54 bit fixed point is also staggering.
And almost any code that would work with 54 bit fixed point works even better with 64 bit floating point, and the floating point version is much easier to code.
So sure, floating point isn't optional when you start off assuming the same number of bits. But if you treat it as a small overhead to make code more robust to large numbers, easier to code, and often faster to run, then it looks a lot better.
Yes, the respective sins of both floating- and fixed-point math are significantly reduced when you have more bits (for a demo of this try using both at 16 bits; you will have to code very carefully and be very aware of the faults of each).
For many situations though, I find the graceful degradation of floats to cause more subtle bugs, which can be a problem.
Range warnings are going to be calculation specific. Adding a non-zero fixed point number "y" N times to a fixed-point number "x" will result in either an overflow or x+N*y.
If integer overflows trap (curse you Intel, C89), then repeated additions (important in many simulations) will either work as expected or crash.
Floating point operations are (for practical purposes) highly privileged because of extremely mature hardware implementations. Hardware implementations that make other forms of calculations more tractable are possible (and have existed in the past) and should be considered when evaluating FPs fitness for purpose, otherwise we will be stuck in the IEEE local maximum forever.
Hilarious. Fixed point is awful it was thrown out the moment people could use floats on their computers. Fixed point numbers cause an enormous programmer overhead and do not fix the problems.
> Fixed point numbers cause an enormous programmer overhead and do not fix the problems.
How so? Is that because of inherent problems with the outcomes of fixed-point arithmetic, or are they just clumsy to use and no-one's written a decent library that makes dealing with fixed-point numbers straightforward?
Because you need to be extremely careful about overflows/underflows. All operations you perform suddenly become difficult and require careful analysis. With fixed point numbers you need to ensure that every intermediate result of your operation gives an in range result.
You can not remove that tedium by a library, since any potential application has different requirements and now you need to start out your program by defining those requirements for your library. All operations you perform need to be analysed based on your initial requirements.
Also, fixed point arithmetic does not fix floats. You have an uncountable number of real numbers and you try to fit that into 32 or so bytes. It seems simple to understand that any such projectiom whatever you try has enormous drawbacks.
That floats do not behave like real numbers is the consequence of their design requirements. Fixed point just means instead of being able to pretend that floating point operations are sometimes inaccurate real number operations, you have to deal with constan, domain specific renormalization and have to be extremely careful aboit choosing scaling.
> you need to be extremely careful about overflows/underflows. [...] you need to ensure that every intermediate result of your operation gives an in range result.
How is that any different from ordinary integer operations/arithmetic with ints/longs/etc...?
> Also, fixed point arithmetic does not fix floats.
> How is that any different from ordinary integer operations/arithmetic with ints/longs/etc...?
One of the key advantages of floating-point is that it is scale-independent--it doesn't matter if you're doing your calculations in meters, feet, miles, kilometers, parsecs, AUs, nanometers, Planck lengths--you'll get the same relative accuracy. If you're using fixed point (or integers), you instead have to take care to make sure that you scale things such that your units are not too large or too small.
Floating-point is essentially binary scientific notation, and it should be no surprise that it's a good format if you're in a field that already uses scientific notation all the time.
> it doesn't matter if you're doing your calculations in meters, feet, miles, kilometers, parsecs, AUs, nanometers, Planck lengths--you'll get the same relative accuracy.
Yes, but if I'm working with lengths where I know micrometers are good enough, but I also want micrometer (or, at least, better-than-millimeter) precision, but I want to actually deal in meters and I know I'm not going to be dealing with lengths longer than 100km, then fixed point would be ideal for that.
Simlarly, if I want to deal in dollars, but need cent precision (or, tenth of a cent precision), and need it to be precise, then fixed point would be ideal for that too.
I think the disconnect might be that I wasn't considering fixed-point arithmetic as a general replacement for floating-point arithmetic, I'm considering it as a complement to floating-point, to be used in the cases where it makes sense to do so.
The impression I got from the commenter I was originally replying to was "fixed point is absolutely terrible and there is never a reason to prefer it over floats". If that wasn't an intended implication, I guess I'm kind of arguing into the void.
>I know I'm not going to be dealing with lengths longer than 100km, then fixed point would be ideal for that.
Huge fallacy. No, you can not use fixed point numbers like that, it can not work. It is irrelevant what the actual maximum/minimum scale you are dealing with is. The thing which matters is the largest/smallest intermediate value you need. You need to consider every step in all your algorithms.
Imagine calculating the distance of two objects being 50km in x and 50km in y direction apart. Even though the input and output values fit within your range, the result is nonsensical if you use naive fix point arithmetic. Floating point allows you to write down the mathematical formula exactly, using fixed point arithmetic, you can not do that.
Looking at the maximum and minimum resolution you need is a huge fallacy when working with fixed point arithmetic and one big reason why everyone avoids using it. You need to carefully analyze your entire algorithm to use it.
>The impression I got from the commenter I was originally replying to was "fixed point is absolutely terrible and there is never a reason to prefer it over floats".
My position is that sometimes there might be a situation where fixed point arithmetic could be useful. If you are willing to put in a significant amount of time and effort into analyzing your system and dataflow it can be implememted successfully.
It is a far more complex and errorprone system and if you aren't careful it will bite you. In all cases floating point should be the default option and only deviated from if there are very good reasons.
Everyone here knows that floating point isn't perfectly representing the real numbers. What is the point of this comment? What does it have to do with what I posted? Why give another example when another was talked about already?
The other examples involve things like running out of memory and time, the impossibility of real numbers, precision of giant numbers. While the actual problem begins very close to 1+1.
Forget everything else, I need to pay my bills, this involves money.
I didn't say anything else because it is hard not to make sarcastic jokes and devolve into a rant.
You break down a problem to it's smallest parts then you solve those small problems. It seems very basic.
The smallest problem is c = a + b NOT a + b
One can do c = 2.03 , there is no problem storing the number.
One can also do 103 + 100 like c = ((a100) + (b100))/100
This looks even more hideous than c = asfdsADD(a,b) but at least you don't need to hurl around a big num lib to do 1+1.
If things get ever so slightly more complicated than 1+1, what should be a bunch of nice looking formulas looks horrible. Heaven forbid one wants a percentage of something. I would have to think how to accomplish that without the lib.
I have a very slow brain with very little memory and many threads, I'd much rather spend cpu cycles.
>How is that any different from ordinary integer operations/arithmetic with ints/longs/etc...?
It is different, because you never want to take the square root of an integer.
Floats allow you to pretend you are working with sometimes inaccurate real numbers. That is the magic behind it and why fixed point arithmetic was abandoned almost immediately when floating point became fast and easily available.
There are plenty of libraries which makes dealing with fixed-point relatively easy.
I think GP is alluding to issues you get when you have a mix of scales. Like floating-point, fixed-point will have a limited precision range around the origin. In contrast to floating-point, the range for fixed-point is smaller but evenly spaced.
Say you have 32:32 fixed-point. You can then represent numbers in multiple of ~0.2e-9. So if you need to calculate distances in nanometers, perhaps due to a short timestep in a simulation, you have hardly any precision to work with.
The obvious way around this is to pull out a scale factor, say 1e-9 since you know you'll be in the nano-range. Now the numbers you're working with are back on the order of 1 with lots of precision, however you need to apply the scale factor when you actually want to use the number, and now you have to be careful not to overflow when multiplying two or more scaled numbers. This is part of the programmer overhead GP alluded to.
> The obvious way around this is to pull out a scale factor, say 1e-9 since you know you'll be in the nano-range. Now the numbers you're working with are back on the order of 1 with lots of precision, however you need to apply the scale factor when you actually want to use the number, and now you have to be careful not to overflow when multiplying two or more scaled numbers.
Do that rescaling automatically and have a system that just keeps track of the scale and you've just implemented floats. (:
Consider a simple newtonian physics simulation. What you say is probably true for both force and acceleration. It may be true for velocity, but is almost certainly not true for position.
Consider an object with a very small velocity traveling away from the origin with no forces acting upon it. With floating-point arithmetic, it will eventually stop at some distance away from the origin. In general objects with small velocity will only move if they are close to the origin.
Sure, but most PIC methods are centered at their element or local domain. (You can likely even do the same with ewald/nbody). I definitely agree with you though if you need high accuracy on position when everything is on the same huge grid.
A simulation that computes bulk properties by simulating particles directly is very rare. At least for me. Observable like temperature, electric/magnetic field strength, stress, velocity, etc are much more common outputs. These often all vary over many order of magnitude across a domain.
Working with continuum mechanics, performing large inverted solves on matrices in fixed precision, or heck, even an FFT sounds terrifying to guard against overflow.
