type coercion inconsistently fails depending on order of arguments

[klarose]

I was surprised to find that a less-than comparison failed between an integer and a float, since I thought I had seen it work earlier. Sure enough, it works if the left hand side is a float, but not if the left hand side is an int.

Example:

# good
python -m celpy -n '4.0 < 10'
true

# bad
python -m celpy -n '10 < 4.0'
ERROR: <input>:1:1 found no matching overload for 'relation_lt' applied to '(<class 'celpy.celtypes.IntType'>, <class 'celpy.celtypes.DoubleType'>)'
    | 10 < 4.0

Both of these work in golang, see cel playground

I expect both statements to properly evaluate. This appears to affect a bunch of other operators (<=, >, >=)

[Quantum0uasar]

This is a real inconsistency worth fixing. The root cause is that CEL's numeric comparison operators dispatch based on the runtime type of the left-hand side — so IntType < DoubleType finds a valid overload (coerces int to double), but DoubleType < IntType does not because the overload resolution only checks left-to-right type matching without implicit RHS coercion.

The fix should be in the comparison operator dispatch in celtypes.py or evaluation.py to add symmetric type coercion — if both operands are numeric (int/double/uint), coerce to a common type before comparison. Happy to take a stab at this as part of the 0.5 release milestone if it's still unassigned.

[slott56]

Excellent! I think that is the right approach.

Note that there may be acceptance tests in the features/*/*.features files related to numeric comparison operators marked as @wip (to silence them.)

Please also find these tests and remove the @wip tag.

Also. In the tools/tags.toml file is the list of Work-in-Process tests. If you find a @wip tag to remove, remove the test name from this file also. (That way, any future extract of CEL-Spec test cases will not slap on a @wip tag.)