バージョン別の実用的なガイド

Equarith ドキュメント。

Equarith のインストール、最初の探索、結果の理解、ワークフローの自動化、方程式の書き出しまで解説します。

このコンテンツは現在、英語でのみご覧いただけます。この言語のドキュメントはまだ公開されていません。以下に英語版を表示します。

Exporting data and formulas

Equarith exports locally, writes completed output to a neighboring temporary file, and replaces the destination atomically when the filesystem supports it, with a regular replacement fallback. You can export a selected solution or the complete Pareto front, edited data, predictions, charts, or logs.

Copy a result with Copy as

In the Search workspace, right-click a solution row in the Pareto front. The context menu provides three distinct actions:

  • Copy formula copies the ordinary Equarith expression as plain text.
  • Copy as copies that one expression in LaTeX or one of the 24 scientific, software, and industrial target syntaxes listed below.
  • Export formula… writes a complete file for the selected solution. Use File > Export Solutions… to export the complete Pareto front.

Copy as deliberately puts only the rendered expression in the clipboard. It does not include a function declaration, helper implementations, solution metadata, or a data-loading wrapper. This makes it convenient for a notebook, document, formula field, or existing function body. The Excel target is likewise formula-syntax text, not a workbook with input-cell bindings, and the receiving cell or tool may require a leading =. If the expression uses a protected operation that needs a helper in the target language, choose Export formula… instead; the file exporter emits the complete standalone module and required helpers.

CSV, JSON, and plain-text reports provide solution-level formulas and metadata and are therefore available through file export rather than Copy as. Copy and export both use the exact published expression shown for the selected result.

Formula and solution formats

Documentation and structured formats are:

  • CSV for a tabular solution inventory;
  • JSON for structured solution records;
  • plain text for readable formulas and metadata; and
  • LaTeX for mathematical typesetting.

Executable exports generate one scalar function per solution. Function parameters use stable alphabetical variable order. A variable that conflicts with a target-language reserved word is renamed safely for that target, and the mapping is documented in generated comments. Most targets use an eq_ prefix; Wolfram Language uses its target-appropriate eqName form.

Generated comments retain the solution identifier, complexity, objective values, and canonical formula. Helpers for protected or unavailable operations are emitted once per module.

Scientific targets

  • Python 3.10 or later, standard library only.
  • R 4.1 or later.
  • Julia 1.6 or later.
  • MATLAB R2016b or later, without toolboxes.
  • GNU Octave 7 or later.
  • SAS 9.4 using PROC FCMP.
  • Excel OOXML workbook without macros.
  • Wolfram Language 12 or later.

The Excel workbook has a Solutions sheet and one evaluation sheet per formula. Inputs are editable cells and the prediction remains unavailable until required inputs are present. Formulas use portable OOXML function names and Excel localizes their display.

Software targets

  • C99 and C++17.
  • Fortran 2008 using real64.
  • Java 8 or later.
  • Kotlin 1.8 or later.
  • Swift 5.9 or later with Foundation.
  • PHP 8.1 or later.
  • C# targeting .NET Standard 2.0.
  • Rust 2021 edition.
  • Go 1.20 or later.
  • JavaScript ECMAScript 2020 module.
  • TypeScript 5 targeting ES2020.
  • Lua syntax compatible with 5.1 through 5.5.

Industry targets

  • VBA7 module.
  • PostgreSQL 12 or later SQL.
  • IEC 61131-3 Structured Text using LREAL.

Numerical semantics

Exporters use double precision appropriate to the target. When a language lacks an operation with the exact Equarith semantics, the module provides a helper. This includes protected division, safe logarithm, safe square root, clamped exponential, real cube root, sign, truncated remainder, and selected hyperbolic or stability functions.

The generated function is scalar. Vectorization, data loading, input validation, process integration, and error handling belong to the calling application.

Native behavior can still differ outside the valid finite domain. Floating-point libraries, compiler flags, spreadsheet calculation settings, and database implementations can introduce small rounding differences. Test the exported target against Equarith with ordinary, boundary, and deliberately invalid inputs.

Expressions that cannot become executable code

Version 1.0.3 does not generate standalone executable code for:

  • history functions, because they need ordered-row state;
  • user-defined function bodies;
  • template placeholders; or
  • unknown named constants.

The export fails explicitly and does not replace an existing destination file. Readable presentation formats can still represent supported formula text, including history expressions where appropriate.

Other exports

  • Data exports the current edited dataset as CSV.
  • From Search, a prediction export evaluates the selected formula on all active-dataset rows and includes inputs, target, and prediction. From Prediction, it exports the current expanded custom grid with each formula’s text and result status.
  • Chart tools export PNG and the data represented by the chart as CSV.
  • Search results can be copied as a plain Equarith expression or with the target-language Copy as submenu.
  • The structured log can be exported as CSV for support.

Large interactive charts use a point budget for responsiveness. A chart-data export describes the plotted series; use the dedicated prediction export for complete prediction rows or the solution export for complete solution records.

Deployment checklist

  1. Export the exact published formula, not an earlier draft.
  2. Confirm variable names, alphabetical parameter order, units, and missing-value policy.
  3. Reproduce Equarith values on a representative sample.
  4. Test strict-domain boundaries and protected-function branches.
  5. Decide how the host system handles NaN, infinity, exceptions, and null input.
  6. Add tests for extrapolation limits and physically impossible results.
  7. Retain the project, version, solution identifier, and validation evidence.

For batch automation, see Automation, headless CLI, and SDK roadmap.