Matlab

MATLAB and GNU Octave

Use this skill to design or review numerical code, migrate MATLAB releases, prepare reproducible projects, and plan trusted execution. MATLAB and GNU Octave are distinct products: compatibility is partial, not a license or behavior guarantee.

Review scope

Reviewed against current MathWorks R2026b documentation and GNU Octave 11.3.0 sources on 2026-10-01. The bundled Engine planner and MATLAB examples retain an explicit R2026a baseline. R2026b supports CPython 3.10-3.14; do not reuse the R2026a Engine package for it. MATLAB/Octave examples are illustrative and were not executed in this review; the Python helpers have local synthetic tests. This skill uses local runtime APIs, with no remote service endpoint or API key.

Product and license gate

• MATLAB R2026a is proprietary. Do not assume MATLAB, MATLAB Online, a named toolbox, MATLAB Test, MATLAB Compiler, MATLAB Coder, Parallel Computing Toolbox, or an add-on is installed, licensed, or available to the user.
• MATLAB Runtime is not MATLAB. It runs compatible applications produced with MATLAB Compiler; it cannot run arbitrary source or host MATLAB Engine for Python. Building artifacts needs the applicable licensed compiler and every product used by the source.
• GNU Octave 11.3.0 is free software under GPLv3+. Octave packages are not MATLAB toolboxes. Similar names do not imply API, numerical, graphics, or licensing equivalence.
• Ask which runtime, release, platform, installed products, and license context the user actually has. Treat availability as unknown until confirmed.

See Octave compatibility and execution/product boundaries.

Nonnegotiable safety boundary

Never run an untrusted .m, .mlx, MEX binary, MAT file, project startup or shutdown action, package installer, or generated artifact. Static review does not prove safety.

Treat these as execution or code-loading surfaces:

• eval, evalin, assignin, text-derived feval, str2func, callbacks, timers, app callbacks, and dynamically modified paths;
• system, unix, dos, shell escape !, Java, .NET, Python (py.*, pyrun, pyrunfile), MEX, and native libraries;
• mex, codegen, MATLAB Compiler, build tasks, package/project startup, and generated code;
• load, object deserialization (loadobj, custom serialization), function handles, Java/System objects, and class code reachable from MAT files.

.mlx is an opaque archive for this toolkit and MEX is native executable code. Do not use Python pickle for exchange. Inspect first, isolate when appropriate, obtain explicit approval, then invoke a user-confirmed executable and license. Bundled scripts are static or dry-run tools: none launches MATLAB, Octave, Python Engine, a compiler, or a subprocess.

Default workflow

1. Clarify target. Record MATLAB release or Octave version, OS/architecture, base product versus required toolboxes/packages, expected inputs/outputs, numerical tolerances, and whether execution is authorized.
2. Inventory statically. Scan .m files, opaque artifacts, project paths, required products, and MAT headers before any runtime loads them.
3. Choose code form. Prefer functions with an arguments block for automation. Use scripts only for controlled orchestration and live scripts for reviewed interactive narratives.
4. Make semantics explicit. Record shapes, classes, units, missing-value rules, indexing, implicit expansion, RNG algorithm/seed, tolerances, and output formats.
5. Test without hidden state. Keep fixtures synthetic, paths project-local, graphics deterministic, and tests independent of base-workspace residue.
6. Plan execution. Generate an argv plan, review startup/path effects and licenses, and launch only after explicit approval outside these helpers.
7. Capture provenance. Hash named inputs/code and record release, products, RNG policy, tolerances, and command plan without dumping the environment.

Language and data checklist

Scripts, functions, and live scripts

• Scripts share the caller/base workspace and leave variables behind. Functions have local workspaces and explicit inputs/outputs.
• Live scripts (.mlx) mix code and rich output but are not plain-text review artifacts. Export reviewed code to .m for static inspection.
• Avoid clear all, broad addpath(genpath(...)), dependence on pwd, global variables, and silent name shadowing. Use project roots and fullfile.
• Validate sizes, classes, and values in arguments blocks. Remember that type declarations can convert inputs and size declarations can reshape or expand compatible inputs; validators check without converting.
• A main function file should match the main function name. Local functions are private to the file; since R2024a they can appear anywhere in a script outside conditional contexts.

function y = scaleSignal(x, options)
arguments
    x (:,1) double {mustBeFinite}
    options.Scale (1,1) double {mustBeFinite, mustBeNonzero} = 1
end
y = x .* options.Scale;
end

Read programming.

Arrays, indexing, and numerics

• MATLAB uses 1-based, column-major indexing. A(i,j), A(k), A(:,j), A{...}, and A.(name) have different semantics.
• *, /, \, and ^ are matrix operations; dotted forms are element-wise. Use A\b, not inv(A)*b.
• After a linear solve, inspect conditioning/rank and a scale-aware residual; backslash can continue after a singularity warning, and a small residual alone does not establish an accurate solution. For underdetermined systems, state whether minimum norm is required (lsqminnorm), rather than assuming A\b returns it. See the mldivide contract.
• Since R2016b, compatible dimensions expand implicitly. Assert intended shape before operations that could accidentally form an outer result.
• Preallocate when output size is known, but do not vectorize at the cost of huge temporaries or unreadable code. Measure with timeit or the profiler.
• Compare floating-point results with domain-chosen absolute and relative tolerances, not blanket == or a magic multiple of eps.
• Pin both random algorithm and seed. Use named RandStream substreams for independent parallel work; do not use time-based rng("shuffle") for a reproducibility claim.

Read arrays and mathematics.

Tables, timetables, and missing values

• A table has named, equal-height variables that may have different types. T(rows,vars) returns a table; T{rows,vars} extracts contents; T.Var selects one variable.
• A timetable additionally has row times. Sort, validate time zones and uniqueness, then use retime/synchronize intentionally.
• Missing sentinels are type-specific: NaN, NaT, <missing>, <undefined>, and empty character vectors. Integer and logical arrays have no standard missing sentinel.
• Define import options rather than relying on inference for production data. Preserve units, time zones, variable names, encodings, and missing rules.

Read data import/export.

Graphics and export

Use explicit figure/axes handles and tiledlayout; label units; set limits, color scales, font sizes, and colormaps deliberately. Prefer exportgraphics over saveas for publication output. In R2026a it exports raster, PDF/EPS/EMF, SVG, GIF, and interactive HTML; format capabilities differ. Specify ContentType="vector" for PDF/EPS/EMF; SVG is selected by its extension. Use Resolution for raster output. Review accessibility and embedded-raster behavior.

Read graphics and export.

MAT files and exchange

• Version 7 is the normal save default; matfile creates 7.3 by default. Versions 4/6/7/7.3 differ in types, compression, and per-variable limits. Users can change the save default in settings, so specify -v7 or -v7.3 explicitly in reproducible exchange workflows.
• Version 7.3 is HDF5-based, not an arbitrary HDF5 interchange contract. Partial access and chunking can help large arrays.
• Never load an untrusted MAT file. Inventory headers/datasets first. Objects can invoke class deserialization behavior; opaque/function/native content requires escalation.
• Prefer CSV/JSON/Parquet/HDF5 with a documented schema for simple exchange. Do not rename pickle payloads as MAT files and do not deserialize pickle.

Read data import/export.