[Dev] Digit exponents R²¹, R¹⁰⁰: keep the limit of 20 or read the exponent?

Aperta
  • Qualcosa non va?
#402 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@jbcaillau ci sta già lavorando.

Dal 1/11/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

feature

Written by Claude (Claude Code), at the request of ocots, from a question raised while documenting the dimensions in PR #397. The measurements are mine; the question is for the maintainers.

@jbcaillau: your opinion is asked, see the question at the end.

Context

The dimension of a state, a control or a variable can be written R^n (any expression) or with digit exponents, R², R³, … Julia reads R² as one identifier, so the parser does not read the exponent: it has a table of aliases, built by __init_aliases(; max_dim=20), that maps R² to R^2 and so on up to R²⁰. Anything above is an unknown name:

x ∈ R²⁰, state   # fine
x ∈ R²¹, state   # ParsingError: unknown syntax
x ∈ R¹⁰⁰, state  # same
x ∈ R^21, state  # fine

A related question, the automatic names of the components (x₁, x₂, … only up to 9 for a symbolic dimension), is a separate issue: #403.

Why 20? (looked into, no reason found)

  • The limit is in the first commit of the parser (f8d8c69, 2025-02-19, "added onepass + ctparser_utils"); no comment or later message gives a reason.
  • It is not a memory limit. The table has 20 entries (R¹ to R²⁰) and is built for every @def block. Measured on the current main (a @def block of six statements, a state x ∈ R^n):
n @def time aliases for the state
10 0.069 s 47
100 0.072 s 227
500 0.080 s 1027
1000 0.090 s 2027
2000 0.119 s 4027
  • What does grow with the dimension is the number of aliases of the components (two per component, x₁ and x1), and parse! substitutes every alias in every statement, so the cost is about the number of aliases times the number of statements. It is mild for these sizes. It is not a reason to cap the digit exponents (the table), which has nothing to do with the number of components.

Options

  1. Keep as is. R^n is the general spelling; the digit exponents are a convenience up to 20, documented in the page Dimensions and automatic names. Nothing to maintain.
  2. Read the digit exponents. Recognise any identifier made of R followed by superscript digits, and turn it into R^k (superscript digits to ASCII, then parse). R²¹ and R¹⁰⁰ would work, and the table goes away. A few lines and tests, no change for what works today. The result, for a dimension of 100, is a state with 100 components and 200 aliases, which is what R^100 gives already.
  3. Raise the table (max_dim), which keeps the arbitrary limit somewhere else.

The superscript letters (Rⁿ) are not part of this question: they are refused, on purpose, and pinned by a test in PR #397. There is no superscript q, no _ and few capitals, so a name like n_x could not be written, and a second spelling of a symbolic dimension is not wanted.

Question

For @jbcaillau: do you remember a reason for the limit of 20 (or for 9 on a symbolic dimension) that these measurements miss? If not, do you prefer option 1, 2 or 3?

Related: #60 and PR #397.

Lingua principale
Julia
Stelle
3
Fork
0
Merge medio
1g 32m
PR unite (30g)
18

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 control-toolbox/CTParser.jl

Tutte le issue di control-toolbox/CTParser.jl

Issue simili

Altre issue su Julia

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.