From @AlexDaniel

Code​:
say 2.5 lcm 5

Result​:
10

Looking at the implementation, it calls .Int on both arguments before doing a normal lcm ( https://github.com/rakudo/rakudo/blob/d56501a65dab442acd64ad00d52483a53ed7fe40/src/core/Numeric.pm#L250 ).

I don't think that giving a seemingly wrong answer is a good idea. I'd much rather prefer it to complain that the argument is not Int, and let the user decide if he wants to Int-ify the numbers or use a different solution.

Another option is to make it return 5 (kinda DWIM), but this is a yet another rabbit hole…

From @zoffixznet

Thank you for the report. However, there's no bug here and I'm going to reject this ticket.

Another option is to make it return 5 (kinda DWIM)

No, it's not another option because that doesn't make any sense mathematically.

The math operations lcm[^1] and gcd[^2] ops perform apply to integer operations. The ops are speculated,
implemented, and clearly documented to be operations coercing to integral types to match that.

As there's no calculation result that can be expected from non-integral types, throwing on non-Ints
will only force the user to add Int coercers to their code all the time, which is quite annoying.

[1] https://en.wikipedia.org/wiki/Least_common_multiple
[2] https://en.wikipedia.org/wiki/Greatest_common_divisor

The RT System itself - Status changed from 'new' to 'open'

@zoffixznet - Status changed from 'open' to 'rejected'

From @AlexDaniel

Does it mean that ``div`` and ``mod`` ops should also coerce arguments to ints? Otherwise I'm failing to see any consistency.

Anyway, no, it does not necessarily have to be applied to integers only. Example​: http://www.wolframalpha.com/input/?i=gcd(3%2F7,12%2F22) (perl6 currently says 0)

See this for more information​: http://math.stackexchange.com/questions/151081/gcd-of-rationals

On 2017-03-21 17​:52​:49, cpan@​zoffix.com wrote​:

Thank you for the report. However, there's no bug here and I'm going
to reject this ticket.

Another option is to make it return 5 (kinda DWIM)

No, it's not another option because that doesn't make any sense
mathematically.

The math operations lcm[^1] and gcd[^2] ops perform apply to integer
operations. The ops are speculated,
implemented, and clearly documented to be operations coercing to
integral types to match that.

As there's no calculation result that can be expected from non-
integral types, throwing on non-Ints
will only force the user to add Int coercers to their code all the
time, which is quite annoying.

[1] https://en.wikipedia.org/wiki/Least_common_multiple
[2] https://en.wikipedia.org/wiki/Greatest_common_divisor

@AlexDaniel - Status changed from 'rejected' to 'open'

From @AlexDaniel

By the way, lcm(2.5, 5) should actually be 10, so my initial snippet (and assumption) is wrong. But one can take any other rats, e.g. 0.5 and 1.0.

On 2017-03-21 18​:37​:05, alex.jakimenko@​gmail.com wrote​:

Does it mean that ``div`` and ``mod`` ops should also coerce arguments
to ints?
Otherwise I'm failing to see any consistency.

Anyway, no, it does not necessarily have to be applied to integers
only.
Example​: http://www.wolframalpha.com/input/?i=gcd(3%2F7,12%2F22)
(perl6
currently says 0)

See this for more information​:
http://math.stackexchange.com/questions/151081/gcd-of-rationals

On 2017-03-21 17​:52​:49, cpan@​zoffix.com wrote​:

Thank you for the report. However, there's no bug here and I'm going
to reject this ticket.

Another option is to make it return 5 (kinda DWIM)

No, it's not another option because that doesn't make any sense
mathematically.

The math operations lcm[^1] and gcd[^2] ops perform apply to integer
operations. The ops are speculated,
implemented, and clearly documented to be operations coercing to
integral types to match that.

As there's no calculation result that can be expected from non-
integral types, throwing on non-Ints
will only force the user to add Int coercers to their code all the
time, which is quite annoying.

[1] https://en.wikipedia.org/wiki/Least_common_multiple
[2] https://en.wikipedia.org/wiki/Greatest_common_divisor

@zoffixznet - Status changed from 'open' to 'rejected'