[viraptor]

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

Accuracy problems in floating-point computations: https://en.wikipedia.org/wiki/Floating_point#Accuracy_proble...

[viraptor]

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]

> 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

[greggyb]

There is another snippet near that section which evaluates the following.

    >>> float > float('infinity')
    True

[viraptor]

Bah, you're right, missed that example :(

[amyjess]

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]

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