back to table · edit · history · where entries came from · files · download
2426 bytes, as of the version from 2026-10-28 08:03 (current). Recorded here, not run.
## Polynomial variable names must be a letter followed by optional digits
What happened: issue #228 requested the formal indeterminate `alpha`, but
NumberDB's parser and the vendored client's parser tokenize variable names as
`[A-Za-z][0-9]*`. `alpha*x1^2` is therefore not readable as one named parameter.
A lookup written with `alpha` returned HTTP 500; renaming it `a` returned normally.
The build keeps the mathematical symbol alpha and explicitly writes `a=alpha`
in the table's spelling convention. It does not evaluate alpha numerically.
What the skill says now: name the variables and check the six-variable limit.
It does not state the accepted spelling of a polynomial variable.
What it should say: a stored polynomial's variable names must be a single
ASCII letter optionally followed by digits. Use `a` for a formal alpha and
explain that spelling in the definition. Test one representative serialization
before claiming that a symbolic variable name is supported.
Evidence: T575; `lookup-screening.json`, `convention.md`, and the regex `_TOKEN`
in `clients/python/numberdb/_polynomial.py`. The HTTP 500 response is a site
error; the spelling restriction itself also affects local client users.
## Initialize the symbolic ring before calling Symmetrica through named imports
What happened: `numberdb.sage` plus named ring and `SymmetricFunctions` imports
failed while converting a Jack polynomial to the monomial basis. The lazy
Symmetrica initialization encountered a circular import in `sage.symbolic`
and the process exited with status 139. Importing
`from sage.symbolic.ring import SR` before `SymmetricFunctions` made the same
small control work. The actual generator uses explicit power-sum arithmetic;
the independent checker and the table's Sage example include this import.
What the skill says now: importing numberdb.sage initializes the rings, but
named imports can leave symmetric-function expansion machinery unavailable.
What it should say: when using named SymmetricFunctions imports in a check or
example, explicitly initialize the symbolic ring before converting or expanding
bases if the Symmetrica backend requires it. Run a small nonzero control first.
Evidence: `probe.log`, `probe-initialized.log`, and `checks-local.log` in this
run's work directory; SageMath 10.9 and numberdb 0.1.10. The latter two logs
show the correct integral J_(2) and J_(2,1), then all selected comparisons.