Written while working out what should happen before 2.0. Each of these looks self-contained and is not — settling one changes what is possible or cheap elsewhere. Measurements are on master (21f0d16).
1. Whether a new node type is breaking — #248 — gates three other issues
Entity is a public abstract record whose hierarchy is open (InitDirectChildren is protected, so external code can derive). Nothing states whether adding a subtype is a breaking change.
If it is, then none of these may ship in a minor version:
and the roadmap waits on 3.0 for years. Detail and a suggested wording in #248. This is the one to settle first, because three other issues cannot be scheduled until it is.
2. #204 is the simplifier's objective function, not a display choice
Roots versus fractional powers reads like a printing decision. It is not, because Simplify generates candidates and returns the shortest by Complexity, which is node count:
|
Complexity |
sqrt(x) |
3 |
x ^ (1/2) |
5 |
sqrt(x) + sqrt(y) |
7 |
x ^ (1/2) + y ^ (1/2) |
11 |
A radical written as a fractional power costs nearly twice as much, and the gap grows with the number of radicals. So the representation decides which candidate wins, everywhere a radical can appear — not merely how the winner prints. Switching to fractional powers would silently re-rank a large part of the simplifier, and the effect is not visible in any individual rule.
Whatever is decided, it wants measuring against simpsweep and casbench rather than reasoning about, and it should be decided before 2.0 since the printed form of every radical is user-visible.
3. #326 collides with a guarantee 2.0 is about to make
Stringize round-tripping was fixed this cycle — BREAKING-CHANGES.md now promises that powers, lambdas, applications and piecewises parse back from their own output. Changing piecewise syntax after 2.0 ships breaks expressions users have already saved, which is exactly what that guarantee is for.
It is also worse than it looks today: the syntax #326 records as current does not parse, and a near-miss of it crashes with a NullReferenceException rather than a parse error (#813).
So #326 is not a free-standing style question — it is the last cheap moment to move the syntax, and there is a crash sitting on the same grammar rule.
4. #721 and #812 are the same statement told twice
#812 is a wrong answer: abs(x) = -1 returns a non-empty set whose members do not satisfy it, because the inversion is missing an a >= 0 guard.
Expressing that guard needs a decision that is #721's: is "this holds only where the argument is non-negative" a Providedf condition on the node, or a consequence of MathS.Settings.Codomain? Fixing #812 without settling #721 means picking one mechanism by accident and then having two mechanisms for one statement — which is the situation #721 was opened to end.
Fix #812 first if it must be fixed first (it is a wrong answer, so it outranks tidiness), but write down which mechanism was chosen and why, so #721 inherits a decision rather than a mess.
5. The spine's third customer is the polynomial layer, and it is the expensive one
The monoid-algebra spine landed in #778 with two customers: the boolean minimiser and symbolic quantum states. AGENTS.md already records that the polynomial representation "is already a monoid algebra in all but name", and that most of the remaining backlog — #381 characteristic polynomials, #475 Diophantine equations, multivariate GCD, factorisation, #55 — sits behind that layer.
The caveat is also already recorded and is worth repeating here because it decides the order of work: GatherMonomialInformation is on the hot path for solving, long division and simplification. So this is the one place where "unify the representation" cannot be done on the strength of the argument that it is the same structure. Build the benchmark before the change, not after — otherwise there is no way to tell a regression from noise, and the change is large enough that it would not be obvious.
None of these is a request to do the work. They are the couplings I would want known before anything schedules the features on either side of them.
Written while working out what should happen before 2.0. Each of these looks self-contained and is not — settling one changes what is possible or cheap elsewhere. Measurements are on
master(21f0d16).1. Whether a new node type is breaking — #248 — gates three other issues
Entityis apublic abstract recordwhose hierarchy is open (InitDirectChildrenisprotected, so external code can derive). Nothing states whether adding a subtype is a breaking change.If it is, then none of these may ship in a minor version:
floor,ceil,round, and possiblymin/max/gcdand the roadmap waits on 3.0 for years. Detail and a suggested wording in #248. This is the one to settle first, because three other issues cannot be scheduled until it is.
2. #204 is the simplifier's objective function, not a display choice
Roots versus fractional powers reads like a printing decision. It is not, because
Simplifygenerates candidates and returns the shortest byComplexity, which is node count:Complexitysqrt(x)x ^ (1/2)sqrt(x) + sqrt(y)x ^ (1/2) + y ^ (1/2)A radical written as a fractional power costs nearly twice as much, and the gap grows with the number of radicals. So the representation decides which candidate wins, everywhere a radical can appear — not merely how the winner prints. Switching to fractional powers would silently re-rank a large part of the simplifier, and the effect is not visible in any individual rule.
Whatever is decided, it wants measuring against
simpsweepandcasbenchrather than reasoning about, and it should be decided before 2.0 since the printed form of every radical is user-visible.3. #326 collides with a guarantee 2.0 is about to make
Stringizeround-tripping was fixed this cycle —BREAKING-CHANGES.mdnow promises that powers, lambdas, applications and piecewises parse back from their own output. Changing piecewise syntax after 2.0 ships breaks expressions users have already saved, which is exactly what that guarantee is for.It is also worse than it looks today: the syntax #326 records as current does not parse, and a near-miss of it crashes with a
NullReferenceExceptionrather than a parse error (#813).So #326 is not a free-standing style question — it is the last cheap moment to move the syntax, and there is a crash sitting on the same grammar rule.
4. #721 and #812 are the same statement told twice
#812 is a wrong answer:
abs(x) = -1returns a non-empty set whose members do not satisfy it, because the inversion is missing ana >= 0guard.Expressing that guard needs a decision that is #721's: is "this holds only where the argument is non-negative" a
Providedfcondition on the node, or a consequence ofMathS.Settings.Codomain? Fixing #812 without settling #721 means picking one mechanism by accident and then having two mechanisms for one statement — which is the situation #721 was opened to end.Fix #812 first if it must be fixed first (it is a wrong answer, so it outranks tidiness), but write down which mechanism was chosen and why, so #721 inherits a decision rather than a mess.
5. The spine's third customer is the polynomial layer, and it is the expensive one
The monoid-algebra spine landed in #778 with two customers: the boolean minimiser and symbolic quantum states.
AGENTS.mdalready records that the polynomial representation "is already a monoid algebra in all but name", and that most of the remaining backlog — #381 characteristic polynomials, #475 Diophantine equations, multivariate GCD, factorisation, #55 — sits behind that layer.The caveat is also already recorded and is worth repeating here because it decides the order of work:
GatherMonomialInformationis on the hot path for solving, long division and simplification. So this is the one place where "unify the representation" cannot be done on the strength of the argument that it is the same structure. Build the benchmark before the change, not after — otherwise there is no way to tell a regression from noise, and the change is large enough that it would not be obvious.None of these is a request to do the work. They are the couplings I would want known before anything schedules the features on either side of them.