4 ms·

The point the article makes on comparing floating point values and the floating point type is true, but it's not because of any rounding error. It's because th

The point the article makes on comparing floating point values and the floating point type is true, but it's not because of any rounding error. It's because the comparison operators are defined for every value. That is, "True < []" is valid in Python 2.7, along with any other 2 values, regardless of type. This is a surprising instance of weak typing in Python, which is otherwise strongly typed, which is why this was fixed in Python 3 (https://docs.python.org/3.0/whatsnew/3.0.html#ordering-comparisons https://docs.python.org/3.0/whatsnew/3.0.html#ordering-compa...). This is also not a case of Python doing something useful, like with '"foo"*2'. The result of the comparison is defined, but it's not useful. I suppose it was useful for making sure that you can always sort a list, but there are better ways to do that.

viraptor 10y ago
> The point the article makes on comparing floating point values and the floating point type is true, but it's not because of any rounding error. Do you mean this example? (it's the only one I can find about floating point comparison) > 2.2 * 3.0 == 3.3 * 2.0 It's definitely due to accuracy error. (rather than type comparison) How would you explain it otherwise?
- masklinn 10y ago
  Accuracy problems in floating-point computations: https://en.wikipedia.org/wiki/Floating_point#Accuracy_problems https://en.wikipedia.org/wiki/Floating_point#Accuracy_proble...
  - viraptor 10y ago
    My bad, wrote rounding not accuracy. (corrected now) But my point was that it's not related to weak typing as the parent seems to suggest.
    - masklinn 10y ago
      > But my point was that it's not related to weak typing as the parent seems to suggest. And you're completely right there. Any language using floating-point numbers will have the same issue regardless of its typing discipline e.g. Rust: https://is.gd/4BNoWa https://is.gd/4BNoWa
- greggyb 10y ago
  There is another snippet near that section which evaluates the following. >>> float > float('infinity') True
  - viraptor 10y ago
    Bah, you're right, missed that example :(
- amyjess 10y ago
  This really makes me wish they made the decision for Python 3 to auto-convert these literals to Fraction objects like Perl 6 does. Basically, autoconvert the above to this (and make Fraction a builtin instead of in the standard library, of course): >>> Fraction('2.2') * Fraction('3.0') == Fraction('3.3') * Fraction('2.0') True
  - pstch 10y ago
    The speed of these operations isn't on the same order of magnitude as floating-point operations. I do agree that literals for `Fraction` and `Decimal` would be interesting. Also, I think that '2.2' is better represented as `Decimal`, as it's a decimal number (which is a subset of rational numbers, that are usually better represented using `Decimal`) (edit: that of course depends on the use case, as Decimal uses fixed-point precision).
xapata 10y ago
> not ... something useful Intertype comparison is useful for sorting a list of heterogenous types. But for Python 3 they decided that use case wasn't so important.

viraptor 10y ago

> The point the article makes on comparing floating point values and the floating point type is true, but it's not because of any rounding error. Do you mean this example? (it's the only one I can find about floating point comparison) > 2.2 * 3.0 == 3.3 * 2.0 It's definitely due to accuracy error. (rather than type comparison) How would you explain it otherwise?

masklinn 10y ago
Accuracy problems in floating-point computations: https://en.wikipedia.org/wiki/Floating_point#Accuracy_problems https://en.wikipedia.org/wiki/Floating_point#Accuracy_proble...
- viraptor 10y ago
  My bad, wrote rounding not accuracy. (corrected now) But my point was that it's not related to weak typing as the parent seems to suggest.
  - masklinn 10y ago
    > But my point was that it's not related to weak typing as the parent seems to suggest. And you're completely right there. Any language using floating-point numbers will have the same issue regardless of its typing discipline e.g. Rust: https://is.gd/4BNoWa https://is.gd/4BNoWa
greggyb 10y ago
There is another snippet near that section which evaluates the following. >>> float > float('infinity') True
- viraptor 10y ago
  Bah, you're right, missed that example :(
amyjess 10y ago
This really makes me wish they made the decision for Python 3 to auto-convert these literals to Fraction objects like Perl 6 does. Basically, autoconvert the above to this (and make Fraction a builtin instead of in the standard library, of course): >>> Fraction('2.2') * Fraction('3.0') == Fraction('3.3') * Fraction('2.0') True
- pstch 10y ago
  The speed of these operations isn't on the same order of magnitude as floating-point operations. I do agree that literals for `Fraction` and `Decimal` would be interesting. Also, I think that '2.2' is better represented as `Decimal`, as it's a decimal number (which is a subset of rational numbers, that are usually better represented using `Decimal`) (edit: that of course depends on the use case, as Decimal uses fixed-point precision).

xapata 10y ago

> not ... something useful Intertype comparison is useful for sorting a list of heterogenous types. But for Python 3 they decided that use case wasn't so important.