[bryantaustin13]

Problem

Every Quantity test for div and mod uses the same unit on both sides ('g' div 'g', 'cm' mod 'cm', …). So the suite can't tell whether an engine converts units at all. On the Java engine, for example, 250.0 'cm' div 1.0 'm' returns 250 'cm' and 1.0 'm' mod 30.0 'cm' returns 1 'm' (cqframework/clinical_quality_language#1860), but every existing Quantity div/mod test only checks the unit label.

The expected units follow FHIR-59659 ("Specify result unit determination for div and mod operators"), which asks for examples based on these tests:

Div should be unitless after converting arguments to common units in the same way as for division (because it is only a count: How many times does this quantity fit into that one)

Modulo should have the same units as it's operands after converting to common units in the same way as for division (because it is how many are left over of the original quantity, so it has the same units)

"In the same way as for division" refers to the FHIR-58137 rule (#161): convert to the most granular unit, which for a positive exponent is the smaller one.

Change

Seven tests in CqlArithmeticFunctionsTest.xml. They are marked version="1.5", since the Quantity overloads were introduced in 1.5, and they carry the same capabilities as their sibling Quantity tests. Each set has a comment quoting FHIR-59659 and linking the spec entry.

Truncated Divide (end of the group):

Test	Expression	Output
TruncatedDivide250CMBy1MQuantity	250.0 'cm' div 1.0 'm'	2.0 '1'
TruncatedDivideNeg250CMBy1MQuantity	-250.0 'cm' div 1.0 'm'	-2.0 '1'
TruncatedDivide10CMBy1MQuantity	10.0 'cm' div 1.0 'm'	0.0 '1'
TruncatedDivide7KGBy2GQuantity	7.0 'kg' div 2.0 'g'	3500.0 '1'

"The div operator performs truncated division of its arguments", so 250 cm ÷ 1 m = 2.5 truncates to 2, and −2.5 truncates to −2. The result is unitless ('1'), per FHIR-59659.

Modulo (end of the group):

Test	Expression	Output
Modulo1MBy30CMQuantity	1.0 'm' mod 30.0 'cm'	10.0 'cm'
Modulo1KGBy300GQuantity	1.0 'kg' mod 300.0 'g'	100.0 'g'
Modulo10GBy3Quantity	10.0 'g' mod 3	1.0 'g'

• Mixed units: the operands convert to the smaller unit, and the remainder stays in it: 100 cm mod 30 cm = 10 cm.
• An Integer divisor: 3 converts implicitly to 3 '1'. As in division (10.0 'g' / 3 is 3.33 'g'), '1' has no dimension to convert, so the remainder keeps the left operand's unit. FHIR-59659 doesn't spell this case out; Bryn confirmed the tests should be built on that ticket.

An earlier version of this PR compared the mixed-unit Modulo results with =, because the result unit wasn't specified. FHIR-59659 settles it, so they now expect exact units.

Verification

• CqlArithmeticFunctionsTest.xml validates against tests/testSchema.xsd.
• Run through cql-tests-runner:

Test	cql-execution 4.0.0-beta.1	Java engine 5.4.0 (clinical-reasoning 4.13.0, HAPI FHIR 8.12.0)
TruncatedDivide250CMBy1MQuantity	pass	fail (250 'cm')
TruncatedDivideNeg250CMBy1MQuantity	pass	fail (-250 'cm')
TruncatedDivide10CMBy1MQuantity	pass	fail (10 'cm')
TruncatedDivide7KGBy2GQuantity	pass	fail (3 'kg')
Modulo1MBy30CMQuantity	fail (null)	fail (1 'm')
Modulo1KGBy300GQuantity	fail (null)	fail (1 'kg')
Modulo10GBy3Quantity	not run; null expected (see below)	pass (1 'g')

• Java: the failures are the unit handling tracked in TruncatedDivide and Modulo on Quantities ignore the right operand's unit clinical_quality_language#1860. The existing same-unit Truncated Divide tests (TruncatedDivide10By5DQuantity and others) fail there too, returning the operand's unit instead of '1'.
• cql-execution: it returns null for every Quantity mod, including the existing same-unit ModuloQuantity and Modulo10By3Quantity, because its Modulo has no Quantity branch. That's tracked as Modulo is not implemented for Quantity arguments (always returns null) cql-execution#386, with a fix in Implement Modulo for Quantity arguments cql-execution#393. That fix returns null when the units differ after conversion, which includes 10.0 'g' mod 3, so Modulo10GBy3Quantity needs a change there; I've suggested one in a review on #393.

No other test changes.

🤖 Generated with Claude Code