Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Five decisions whose consequences reach past their own issue

Aperta
  • Qualcosa non va?
#814 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
backend

Direzione di ricerca

Inizia leggendo AGENTS.md e BREAKING-CHANGES.md, quindi segui le issue collegate #248, #204, #326, #721, #812 e #778. Confronta le dipendenze dichiarate con le misurazioni di simpsweep e casbench e con il comportamento del parser e del solver referenziati. Il lavoro è completato quando le decisioni e l'ordine tra le issue sono stati stabiliti esplicitamente, non quando è stata implementata una delle funzionalità elencate.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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 (21f0d16f).

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:

  • #809 — floor, ceil, round, and possibly min / max / gcd
  • #286 — functions as separate entities
  • #495 — lambdas and functions as entities

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.

Lingua principale
C#
Stelle
831
Fork
79
Merge medio
2h 22m
PR unite (30g)
507

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ASC-Community/AngouriMath

Tutte le issue di ASC-Community/AngouriMath

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.