Moving from Nerdamer 1.xx

Version 2.xx is a TypeScript rewrite. Much everyday code still looks familiar, but package loading, structured value handling, stored state, solving results, scripting, and lower-level extension APIs have changed enough that a migration deserves more than a version-number swap.

Migrating to 2.xx provides first-class TypeScript support, explicit package entry points, a separate parser build, more cohesive structured values, and structured solver results.

Every effort has been made to carry forward the functionality available in 1.xx. Because 2.xx is a complete rewrite rather than a modification of the previous codebase, some features, aliases, edge cases, or less commonly used APIs may have been missed or may no longer be present. If you find functionality that existed in 1.xx but is missing from 2.xx, please file an issue on GitHub and include a small example showing the previous behavior.

If you cannot migrate yet, version 1.xx is still being maintained by the Nerdamer-Prime fork.

What changes most often

Loading the library

var nerdamer = require('nerdamer');
require('nerdamer/Algebra');
require('nerdamer/Calculus');
require('nerdamer/Solve');
require('nerdamer/Extra');

import nerdamer from 'nerdamer';

import nerdamer from 'nerdamer';
import { Expression, Rational } from 'nerdamer/core';
import { Polynomial, gcd, partfrac } from 'nerdamer/algebra';
import { diff, integrate, limit } from 'nerdamer/calculus';
import { solve, PolynomialSolver } from 'nerdamer/solve';
import { Matrix, Vector, ValuesSet } from 'nerdamer/structures';
import { Parser } from 'nerdamer/parser';

The parser package

nerdamer/parser is a supported smaller composition point. It shares the symbolic parser with the complete package and includes scripting, assumptions, structures, polynomial and complex operations, and general math functions without loading the higher-level algebra, calculus, and solver domains.

import { Parser } from 'nerdamer/parser';

const value = Parser.parse('sqrt(x^2+1)');
console.log(value.text());

The browser build mirrors this split: dist/bundle.js is the complete package and dist/parser.js is the parser target.

The main call has two arguments

Version 1.xx accepted nerdamer(expression, substitutions?, option?, location?). Version 2.xx uses nerdamer(input, values?). Use methods on the returned value for operations that were previously requested through the third argument:

// 1.xx

nerdamer('(x+1)^3', undefined, 'expand');

// 2.xx

nerdamer('(x+1)^3').expand();

The old location argument disappeared with the stored-expression history.

Structured parser results are more cohesive

Version 2.xx keeps a parsed value as its actual type. Code that can receive more than an ordinary algebraic expression should narrow the returned ParserEntity before calling type-specific methods.

Stored expression history is gone

The related global history helpers are not part of 2.xx:

nerdamer.expressions();
nerdamer.getExpression(...);
nerdamer.getEquation(...);
nerdamer.clear();
nerdamer.flush();
nerdamer.numExpressions();
nerdamer.numEquations();

Store results in normal JavaScript variables instead.

Variables, constants, settings, and user functions

nerdamer.setVar('a', 5);
nerdamer.getVars();
nerdamer.clearVars();

nerdamer.setConstant('g', 9.81);
nerdamer.getConstant('g');
nerdamer.setConstant('g', 'delete');

nerdamer.setFunction('f', ['x'], 'x^2+1');

A substitution supplied directly to nerdamer(...) takes priority over an assigned variable. The old single-value getVar() helper is not on the 2.xx root object.

Root functions: what stayed and what moved

Solving returns structured results

Single-equation solving returns a SolutionSet. System solving uses solveSystem() and returns a Vector containing a Dictionary for each solution:

const solutions = nerdamer.solveSystem(
  ['x+y=3', 'x-y=1'],
  ['x', 'y']
);
// [{x => 2, y => 1}]

solveeqs(...) remains the compatibility name. solveEquations is not part of the 2.xx public API.

Scripting changed internally

Nerdamer scripting in 2.xx supports functions, assignments, local bindings, conditionals, loops, blocks, logical operations, return, break, continue, and error handling. Multiline scripts use semicolons as statement separators.

Control-flow operations that produce no mathematical value use an internal null signal. That signal is distinct from valid mathematical values such as an empty vector. Code that depended on undocumented 1.xx control-flow internals should be revalidated.

Deferred simplification

The parser has a DEFER_SIMPLIFICATION mode for workflows that need an unevaluated parse structure, including instructional tooling. It is a specialized mode with limitations and should not be treated as an alternate canonical internal representation.

Expression compatibility details

Common methods such as text(), toTeX(), evaluate(), sub(), variables(), solveFor(), arithmetic methods, expand(), simplify(), and factor() remain familiar. equals() constructs an Equation, while eq() checks equality.

Per-call presentation ordering is available through text({ sort: true }) without changing the expression or global term-order setting.

Replace low-level 1.xx extension hooks

The following 1.xx hooks are not restored as 2.xx root APIs:

getCore()</nregister()
replaceFunction()
addPeeker()
removePeeker()
load()
tree()
htmlTree()
rpn()

Use the supported package APIs instead. setFunction() remains available for symbolic user functions, and isReserved(name) is available for the supported reserved-name check.

Migration checklist

1. Replace the 1.xx core-plus-add-ons loading sequence with the 2.xx complete package or documented package entry points.
2. Remove use of the third and fourth nerdamer(...) arguments.
3. Replace stored-expression-history calls with ordinary JavaScript variables.
4. Review code that assumes every parsed value is an Expression.
5. Update code that expects the old array shape from system solving.
6. Replace getCore(), register(), and similar internal hooks with supported APIs.
7. Check dependencies on removed Extra statistics helpers.
8. Revalidate scripting code that depended on undocumented control-flow behavior.
9. Revalidate code that depended on undocumented numeric, polynomial, solver, assumption, or set internals.
10. Choose the complete package or parser entry point/build according to the functionality actually required.

Where to go next