3 ms·

> you need to be extremely careful about overflows/underflows. [...] you need to ensure that every intermediate result of your operation gives an in range resul

> 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. I wasn't expecting it to?

constantcrying 3y ago
>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.
jcranmer 3y ago
> 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.
- Karellen 3y ago
  > 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.
  - constantcrying 3y ago
    >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.
    - 6510 3y ago
      1.03 + 1 = 2.0300000000000002
      - constantcrying 3y ago
        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?
        6510 3y ago
        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.

constantcrying 3y ago

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

jcranmer 3y ago

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

Karellen 3y ago
> 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.
- constantcrying 3y ago
  >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.
  - 6510 3y ago
    1.03 + 1 = 2.0300000000000002
    - constantcrying 3y ago
      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?
      - 6510 3y ago
        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.