[Rafael-SOWNet]

Closes #1133.

The issue offered three options and did not pick one, because option 3 "changes what documented examples do and would want measuring against the wiki's samples first". That measurement inverts the concern.

The wiki already documents option 3

By default it applies aggressive operators which override the +, -, *, /, ** operators for any pair of object. This is not an F# console, but AngouriMath terminal, after all.

Five operators. The comparisons are not in that sentence and never were — and the Terminal's page has no code samples at all, so there is nothing documented to break. The code rebinds eleven; the documentation describes five. This makes the code match.

What the extra six were costing

Measured on one kernel, with and without AngouriMath loaded:

	before	now
if 1 < 2 then 1 else 0	typecheck error: expected bool, got Entity	1
let b: bool = 1 < 2	typecheck error	True
[1;2;3] |> List.filter (fun x -> x > 1)	typecheck error	[2; 3]
seq { 1..100 } |> Seq.filter (fun x -> x % 7 = 0) |> Seq.length	typecheck error	14
an active pattern with n % 2 = 0	typecheck error	e

And the reading the Terminal exists for is untouched — x + 1, 3 / 2 → 3/2, x ** 2, solutions, derivative all unchanged.

AggressiveOperators is not touched

It is public surface, its comparison overloads are deliberate and covered by their own tests, and Jupyter users may well want x > 0 to be an inequality. All 18 of its tests still pass.

The old behaviour is one line at the prompt, and that is measured rather than asserted: x > 0 is an ordinary comparison until open AngouriMath.Interactive.AggressiveOperators, and an inequality after it. That is option 2 from the issue, obtained without adding any API.

What this does not fix

Rebinding arithmetic has the same shape of cost, and it is the cost the tool exists to pay. Once + and * build expressions, a function whose branches mix an Entity with an int does not typecheck, and List.sum over expressions has no + it can use:

let rec fib n = if n < 2 then n else fib (n-1) + fib (n-2)
  → still does not compile

fib was the issue's headline example and it still fails — on the arithmetic now rather than on the comparison. Rather than let that be discovered as an overclaim, it is pinned as a test whose remark says so, and which fails if it ever starts working so the remark gets rewritten.

Five of the issue's seven cases compile now. The two that do not are the trade the tool actually makes, and it is the documented one.

The wiki

The Terminal page's sentence becomes accurate with this change rather than needing an edit. Worth adding a line about open AngouriMath.Interactive.AggressiveOperators for whoever wants the comparisons, but that is the wiki repo rather than this one.

Failed: 0, Passed: 41 in TerminalUnitTests, and Failed: 0, Passed: 18 in InteractiveWrapperUnitTests.

🤖 Generated with Claude Code

https://claude.ai/code/session_012sonx8iAspMiwRwokT1Ura

[Rafael-SOWNet]

fib compiles now

The PR above left fib failing and said so. That was honest but not finished — the trade can be made per session rather than once, and then fib is available:

open Microsoft.FSharp.Core.Operators              // fib 20 is 6765, and 3 / 2 is 1
open AngouriMath.Interactive.ArithmeticOperators  // back: x + 1 is an expression, 3 / 2 is 3/2

Measured in one session, either following the other, any number of times. operators () prints both lines, so it is discoverable from the prompt rather than from a wiki page.

Why not by default

Rebinding arithmetic and writing ordinary F# are mutually exclusive, measured rather than reasoned: with F#'s own operators fib 20 is 6765 and 3 / 2 is 1; with arithmetic rebound 3 / 2 is 3/2 and x + 1 is an expression, and fib does not typecheck. One operator cannot have both return types.

I tried to have both before concluding that. A witness-constrained SRTP operator over a base class carrying the general case does resolve the simple cases, and resolves them simultaneously:

1 + 1	2 — an int
x + 1	x + 1 — an expression
3 - 1	2
x * x	x ^ 2
1 + 4.5	11/2

It does not resolve let rec: the operator must be picked while the function's own type is still being inferred, so it falls to the general case and fib fails anyway. Annotating the parameter and the return type does not help — checked, not assumed. That is a negative result about this mechanism rather than about every mechanism, and I would happily be shown a third one.

The test that recorded fib as broken now runs it, and fails if fib ever starts compiling by default — which would mean this reasoning had stopped being true and the remark wants rewriting.

Failed: 0, Passed: 41.