Hacker News Reader

Comment by librasteve | Hacker News Reader

lol, here it is in the https://raku.org repl…

  Welcome to Rakudo™ v2025.06.1.
  Implementing the Raku® Programming Language v6.d.
  Built on MoarVM version 2025.06.
  
  To exit type 'exit' or '^D'
  [0] > 0.1 + 0.2 > 0.3
  False

View on HN

Raku uses a rational type by default for those which will give an exact value. If you use Python's Fraction type it would be equivalent to your Raku. The equivalent in Raku to the Python above would be:

  1e-1 + 2e-1 > 3e-1

Which will evaluate to True.

well, yes - but the funny thing is that the example chosen to illustrate the convenience of a REPL is - errr - factually wrong

a scientist knows that 0.1 + 0.2 is not greater than 0.3, only a computer geek would think that this is OK

You completely miss the point twice over.

The REPL example intends to show what the program does, not whether or not something is intuitive for you.

Second, using your same argumentation,

    >>> 010 + 006 == 14
    True

Is also wrong.

It's based on a misunderstanding of what representations of numbers in programming languages are.

In Python (and almost all other languages), 0.1 means the IEEE float closest to the decimal number 0.1, and arithmetic operations are performed according to the IEEE standard.

I am not “missing the point”, I am disagreeing with you. (Hopefully in an agreeable way)

I am making the point that using a decimal literal (eg 0.1) representation for a IEEE double is a bad choice and that using it as a representation for a Rat (aka Fraction) is a better choice.

I 100% accept your point that in Python 0.1+0.2>0.3 is true which is why I prefer Raku’s number system.

This is the third Raku reference I came across since morning.

Happy to see Raku getting some press.

I might be wrong, but I was under the impression that result is platform-dependent?

https://docs.python.org/3/tutorial/floatingpoint.html#floati...

Raku represents 0.1, 0.2, and 0.3 internally as rational numbers. https://docs.raku.org/type/Rat. 1/10 + 1/5 == 3/10

Note that "On overflow of the denominator during an arithmetic operation a Num (floating-point number) is returned instead." A Num is an IEEE 754 float64 ("On most platforms" says https://docs.raku.org/type/Num)

Python always uses IEEE 754 float64, also on most platforms. (I don't know of any Python implementation was does otherwise.) If you want rationals you need the fractions module.

  >>> from fractions import Fraction as F
  >>> F("0.1") + F("0.2") == F("0.3")
  True
  >>> 0.1 + 0.2 == 0.3
  False

This corresponds to Raku's FatRat, https://docs.raku.org/type/FatRat. ("unlike Rat, FatRat arithmetics do not fall back Num at some point, there is a risk that repeated arithmetic operations generate pathologically large numerators and denominators")

good explanation

that said, decimals (eg 0.1) are in fact fractions, and the subtlety that 0.1 decimal cannot be precisely represented by a binary floating point number in the FPU is ignored by most languages where the core math is either integer or P754

bringing Rational numbers in as a first class citizen is a nice touch for mathematicians, scientists and so on

another way to look at it for Raku is that

  Int → integers (ℤ)
  Rat → rationals (ℚ)
  Num → reals (ℝ)

"In fact" is a big strong, no?

"0.1" is what the language specification says it is, and I disagree with the view that it's ignored by most languages when it's often clearly and explicitly stated.

That most people don't know IEEE 754 floats, and do things like store currency as floats, is a different matter. (For that matter, currency should be stored as decimal, because account rules can be very particular about how rounding is carried out.)

Similarly, 3 * 4 + 5 may 'in fact' be 17 .. sometimes. But it's 27 with right-to-left precedence ... and 19683 in APL where * means power (3 to the power of 9). While 3 + 4 * 5 may be 35 or 23 (or 1027 in APL).

FWIW, FatRat is ℚ, not Rat. Rat switches to Num if the denominator is too high, as I quoted.

Bringing it back to Python, ABC (which influenced Python's development) used a ratio/fraction/FatRat natively, which handled the 0.1 + 0.2 == 0.3 issue, but ran into the 'pathologically large numerators and denominators' problem even for beginning students.

I see Rat as a way to get the best of both worlds, but I'm certain it has its own odd edge cases, like I suspect x + 1/13 - 1/13 might not be the original value if x + 1/13 caused a Rat to Num conversion.

when I was a kid in junior school, I was taught that 0.1 means 1/10 something like the . is a division sign, digits to the right are the numerator and the denominator is the position of the digit to the power of 10

true, in fact the syntax of Python consumes the literal '0.1' as a double [float64] ... so ok maybe I was a bit strong that my fact trumps the Python fact (but it still feels wrong to say that 0.1 + 0.2 > 0.3)

---

I welcome your correction on FatRat ... btw I have just upgraded https://raku.land/zef:librasteve/Physics::Unit to FatRat. FatRat is a very useful string to the bow and imo cool that it's a core numeric type.

See also https://raku.land/zef:librasteve/FatRatStr as my path to sidestep P754 literals.

---

We are on the same page that the Rat compromise (degrade to P754) is optimal.

---

As you probably know, but I repeat here for others, Raku has the notion of https://docs.raku.org/language/numerics#Numeric_infectiousne... which means that `x + 1/3' will return a Rat if x is an Int or a Num if x is a Num. All "table" operators - sin , cos, log and so on are assumed to return irrationals (Num).

You likely also learned in school that some calculators do left-right evaluation while other, more expensive ones, do PEMDAS. And a few do postfix instead. You might also have learned that most calculators didn't handle 1/3 as a fraction, in that 1 / 3 * 3 is 0.99999999.

Python is a fancy calculator.

To be clear, while in the mathematical sense, yes, sin, cos, and log generally return irrationals, in their IEEE 754 forms they return an exact value within 1 ulp or so of that irrational number. Num is a rational. ;)

  >>> x=5**0.5
  >>> x
  2.23606797749979
  >>> x.as_integer_ratio()
  (629397181890197, 281474976710656)

Scheme uses the phrase "numerical tower" for the same sort of implicit coercion.

I just realized that in school you likely also learned that 1.0 and 1.000 are two different numbers for physical measurements as the latter implies a higher measurement precision.

Reply on news.ycombinator.com