Running a search

EquarithEngine performs the symbolic-regression search locally. A search owns its dataset snapshot, configuration, worker resources, Pareto archive, and checkpoint lifecycle.

Readiness checks

Before Start becomes available, Equarith verifies:

• one target and at least one input are selected;
• the metric is supported for numerical regression;
• enough rows are finite in every required column;
• the requested train/test split is possible;
• structural bounds are internally consistent;
• function choices and complexity costs are valid; and
• Demo row and variable limits are respected.

Warnings should be reviewed even when they do not prevent a run. Save or export the configuration when the exact experiment matters.

Start, monitor, and stop

Select Start or press F5. The search runs outside the JavaFX application thread, so charts and controls remain responsive. The live status reports:

• elapsed time;
• number of evaluated candidates;
• evaluations per second;
• current best objective; and
• lifecycle or checkpoint messages.

The Pareto table is updated in bounded batches rather than once for every internal candidate. A newly displayed result has been evaluated under the publication rules; with progressive evaluation, that includes the complete training partition.

Select Stop or press Shift+F5 to request cooperative cancellation. Workers finish bounded work, release resources, and write a checkpoint when possible. If shutdown exceeds the safety window, Equarith may interrupt workers. Results published before stopping remain available, but the most recent internal progress may not be resumable.

An enabled time limit uses the same orderly stop path. The optional time limit is disabled until you turn it on in the search configuration.

What the engine optimizes

The search balances two distinct goals:

• the selected training objective; and
• expression complexity under the configured operation costs.

The in-memory Pareto archive contains at most 256 entries and keeps one best representative per complexity. A candidate can enter only if it improves the trade-off rather than merely duplicating a more accurate or simpler expression.

Training drives selection. Test metrics are computed for reporting and comparison when a held-out partition exists. They should not be used repeatedly to tune every choice without reserving further validation data.

Progressive evaluation

With progressive evaluation enabled, inexpensive screening uses a rotating stratified subset of training rows. Promising candidates are promoted and evaluated on all training rows. Only full-training evaluations can become published solutions.

This reduces work on obviously poor candidates while preserving the meaning of published scores. Screening order and evaluation rate can differ from a full-evaluation run, so treat the strategy as part of the reproducibility record.

History values always use original row positions. Sampling and random splitting select evaluation rows; they do not compress time or change the lag between observations.

Normalization and coefficient fitting

When normalization is active, the engine searches in a numerically conditioned space and transforms published formulas back to the source units. The displayed expression is the expression you should evaluate and export.

Coefficient optimization refines constants using the selected Fast, Balanced, or Accurate preset. Invalid domains and non-finite predictions still reject a candidate. If integer-only or decimal-place restrictions are enabled, the published restricted coefficients are evaluated, not just the unrestricted internal fit.

Resource use

Search is CPU-intensive. The desktop search uses every processor exposed to the application; the CPU workers preference applies to other shared background calculations, not to the search engine.

• Use a shorter stop budget or a more focused function set if the desktop becomes unresponsive or memory pressure rises. Use the headless CLI with --threads=<n> when the search itself needs a processor limit.
• Close unrelated high-memory applications before a large search.
• A high evaluation rate does not guarantee a better formula; simple operations and small samples naturally produce more evaluations per second.
• Dataset width, eligible rows, functions, history windows, objective, and coefficient preset all affect cost.

There is no external computation service and no runtime network dependency for search.

Revising a running experiment

The active search uses an immutable snapshot. Data import, pasting, grid edits, structure changes, undo, and redo are disabled while it runs. Configuration controls may be adjusted for the next run, but those changes never mutate the active search. When ready, stop it and select Start to apply the revised configuration.

You can copy a discovered expression or load it as a seed. Seed formulas influence starting material but are not guaranteed to survive selection. Keep independent records of important expressions before beginning a substantially different experiment.

Resume behavior

Equarith writes automatic checkpoints at bounded intervals and during an orderly stop when possible. There is no separate Resume command: after a cooperative stop, or after loading a project with a compatible unfinished checkpoint, Start continues from it automatically. Changing data, split, metric, functions, costs, constraints, or another compatibility field invalidates the pending continuation, so Start begins a new search rather than silently resuming incompatible state.

Reproducibility expectations

With the same dataset, settings, seeds, runtime, and execution environment, seeded runs are designed to repeat. Results may diverge when worker count, thread scheduling, hardware, Java version, Equarith version, or floating-point environment changes.

For publication or audit:

1. Save the project and configuration.
2. Preserve the source dataset or verified fingerprint.
3. Record both split and search seeds.
4. Record worker count and software versions.
5. Export the chosen formula and validation predictions.
6. Re-evaluate it independently on representative and boundary cases.

Continue with Understanding results and analysis.