3 ms·

lol, here it is in the https://raku.org https://raku.org repl… Welcome to Rakudo™ v2025.06.1. Implementing the Raku® Programming Language v6.d. Built on

lol, here it is in the https://raku.org 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

mbrameld 1y ago
I might be wrong, but I was under the impression that result is platform-dependent? https://docs.python.org/3/tutorial/floatingpoint.html#floating-point-arithmetic-issues-and-limitations https://docs.python.org/3/tutorial/floatingpoint.html#floati...
- eesmith 1y ago
  Raku represents 0.1, 0.2, and 0.3 internally as rational numbers. https://docs.raku.org/type/Rat 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 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 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")
  - librasteve 1y ago
    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 (ℝ)
    - eesmith 1y ago
      "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.
      - librasteve 1y ago
        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 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 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_infectiousness 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).
Jtsummers 1y ago
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.
- librasteve 1y ago
  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
  - emil-lp 1y ago
    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.
    - librasteve 1y ago
      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.
reddit_clone 1y ago
This is the third Raku reference I came across since morning. Happy to see Raku getting some press.

mbrameld 1y ago

I might be wrong, but I was under the impression that result is platform-dependent? https://docs.python.org/3/tutorial/floatingpoint.html#floating-point-arithmetic-issues-and-limitations https://docs.python.org/3/tutorial/floatingpoint.html#floati...

eesmith 1y ago
Raku represents 0.1, 0.2, and 0.3 internally as rational numbers. https://docs.raku.org/type/Rat 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 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 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")
- librasteve 1y ago
  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 (ℝ)
  - eesmith 1y ago
    "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.
    - librasteve 1y ago
      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 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 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_infectiousness 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).

Jtsummers 1y ago

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.

librasteve 1y ago
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
- emil-lp 1y ago
  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.
  - librasteve 1y ago
    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.

reddit_clone 1y ago

This is the third Raku reference I came across since morning. Happy to see Raku getting some press.