Repository navigation
gcd and lcm compile at whole arguments; the binders are refused alike, saying to evaluate first - #2443
Merged
Conversation
…, saying to evaluate first gcd and lcm compile in FastExpression and in the LINQ compiler, over Complex and over double: exactly at whole arguments, rounded once by EFloat, and NaN at any other. Evaluation takes them over the rationals too, but a compiled argument is a double, and the double nearest 0.1 is not 1/10. A whole double past 2^53 is read as the integer it is. Both are non-negative, as evaluation gives them: gcd(-4, 6) = 2, gcd(0, 5) = 5, gcd(0, 0) = 0, lcm(-4, 6) = 12, lcm(0, 3) = 0. gcd(12, 18, 8) is gcd(gcd(12, 18), 8) and compiles nested. The calculus nodes and the binders -- derivative, integral, limit, sum, product, a sum, a maximum, a minimum, argmax and argmin over a set, apply and lambda -- stay refused with UncompilableNodeException, by one check both compilers run, whose message names the node and says to call .Evaled or Simplify() first and compile the result. The LINQ compiler said the bound variable was not among the arguments, and FastExpression asked for a bug report for a sum, a product or a lambda. The tests compare all three compiled forms with evaluation exactly, as doubles, at every pair of 14 whole arguments, among them -12, 0, 2^60, 3 * 2^58 and two numbers near 10^15 whose lcm is past 2^53; check NaN at 1/2, 5/2, -3/2, i, 1 + i, NaN and infinity beside 0, 1 and 6; and assert the refusal and its message for each binder in both compilers, and that the evaluated expression compiles. gcd(x, 6) at 4, by Compile: UncompilableNodeException (2.7.0), (2, 0) now. Part of #2195. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #2443 +/- ##
==========================================
- Coverage 86.93% 86.93% -0.01%
==========================================
Files 315 316 +1
Lines 70509 70574 +65
Branches 20606 20613 +7
==========================================
+ Hits 61297 61353 +56
- Misses 4941 4948 +7
- Partials 4271 4273 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #2195: the two decisions left open in the last note there.
gcdandlcmcompile at whole arguments,NaNat any other, in FastExpression and the LINQ compiler, overComplexand overdouble, the way #2217 compilesmobiusandprime. Evaluation takes them over the rationals, but a compiled argument is a double, and the double nearest0.1is not1/10. A whole double past 2^53 is read as the integer it is, and the result is rounded once byEFloat(not by(double)BigInteger, #2218). The signs follow evaluation, measured on 2.7.0:gcd(-4, 6) = 2,gcd(0, 5) = 5,gcd(0, 0) = 0,lcm(-4, 6) = 12,lcm(0, 3) = 0.The calculus nodes and the binders stay refused:
derivative,integral,limit,sum,product, a sum or extremum over a set,applyandlambda. Both compilers now refuse them by one check, withUncompilableNodeExceptionas before, and the message names the node and says to call.EvaledorSimplify()first and compile the result. The LINQ compiler said the bound variable was not among the arguments, and FastExpression asked for a bug report. For a maximum, minimum, argmax or argmin over a set,.Evaledcurrently leaves the node as written, so the advice does not yet help there.Measured: unit tests 19776 passed, MCP/Terminal/Interactive/F# green, AOT smoke 78/78; boundcheck 0 disagreements, rootcheck 596/596, casbench 0 wrong, propcheck 0 failures of 1355, simpsweep 10463/10463, rulecheck 0, canoncheck and confluence on baseline.
work/compilecheckon this branch: FastExpression 68 of 75 numeric nodes, LINQ 68 overComplexand 67 overdouble, statements 16 of 16, 0 disagreements;gcdandlcmnow compile in all three.🤖 Generated with Claude Code