4 ms·

This is about floating point arithmetic in computers.

madez 11y ago
This is specifically about IEEE 754. Arbitray-precision floating point arithmetic like e.g. GMP offers doesn't suffer these issues.
- brandmeyer 11y ago
  MPFR is sensitive in exactly the same way. Just because you can arbitrarily increase the precision of results with that library doesn't mean that it isn't still sensitive to roundoff error.
  - madez 11y ago
    Yes, you are right. However, it's possible using MPFR in a way without suffering this issues. One could increase precision every time there would be rounding.
    - ori_b 11y ago
      The problem is that the second you multiply by pi or e, which is fairly common, your required precision for a perfect result becomes infinite. Even if you don't, your required precision blows up very quickly, and your performance drops.
      - madez 11y ago
        In finite precision arithmetic "multiplying by pi or e" makes no sense. And all arithmetic is finite precision. You could multiply by an approximation, and accordingly adjust the precision to avoid rounding. In more general context, you could choose e as the base of your number system and then multiplying by e is a trivial shift. Then, however, multiplying by 2 would make arithmetically no sense. The natural question that arises is whether it's possible to represent all computable numbers non-lossy in one system. The answer is yes. Besides that, I think you should re-evaluate your decision-making for votes.
        ori_b 11y ago
        > In finite precision arithmetic "multiplying by pi or e" makes no sense. And all arithmetic is finite precision. Yes. that's kind of my point: Either you have a finite precision cutoff and lose accuracy, or the memory used for your arbitrary precision representation blows up to incredibly large values (transcendentals will do this to you quickly), or a combination of the two.
dragonwriter 11y ago
> This is about floating point arithmetic in computers. Its about binary floating point arithmetic in computers, though one could do a similar thing for, e.g., decimal floating point. (Though decimal floating point rounding issues will show up much more rarely in many real-world classes of application.)

madez 11y ago

This is specifically about IEEE 754. Arbitray-precision floating point arithmetic like e.g. GMP offers doesn't suffer these issues.

brandmeyer 11y ago
MPFR is sensitive in exactly the same way. Just because you can arbitrarily increase the precision of results with that library doesn't mean that it isn't still sensitive to roundoff error.
- madez 11y ago
  Yes, you are right. However, it's possible using MPFR in a way without suffering this issues. One could increase precision every time there would be rounding.
  - ori_b 11y ago
    The problem is that the second you multiply by pi or e, which is fairly common, your required precision for a perfect result becomes infinite. Even if you don't, your required precision blows up very quickly, and your performance drops.
    - madez 11y ago
      In finite precision arithmetic "multiplying by pi or e" makes no sense. And all arithmetic is finite precision. You could multiply by an approximation, and accordingly adjust the precision to avoid rounding. In more general context, you could choose e as the base of your number system and then multiplying by e is a trivial shift. Then, however, multiplying by 2 would make arithmetically no sense. The natural question that arises is whether it's possible to represent all computable numbers non-lossy in one system. The answer is yes. Besides that, I think you should re-evaluate your decision-making for votes.
      - ori_b 11y ago
        > In finite precision arithmetic "multiplying by pi or e" makes no sense. And all arithmetic is finite precision. Yes. that's kind of my point: Either you have a finite precision cutoff and lose accuracy, or the memory used for your arbitrary precision representation blows up to incredibly large values (transcendentals will do this to you quickly), or a combination of the two.

dragonwriter 11y ago

> This is about floating point arithmetic in computers. Its about binary floating point arithmetic in computers, though one could do a similar thing for, e.g., decimal floating point. (Though decimal floating point rounding issues will show up much more rarely in many real-world classes of application.)