AI Rules for MATLAB and Simulink

Why MATLAB Needs Specific AI Rules

MATLAB is an interpreted language optimized for matrix operations — its performance model is fundamentally different from C, Python, or JavaScript. Code that uses vectorized operations runs 10-100x faster than equivalent for-loop code. AI assistants, trained on imperative languages, generate MATLAB with for-loops for everything — producing code that's correct but orders of magnitude slower than idiomatic MATLAB.

The most common AI failures in MATLAB: for-loops where vectorized operations exist, arrays that grow inside loops without preallocation, scripts instead of functions, outdated syntax (using the function keyword style from the 1990s), ignoring MATLAB's built-in toolbox functions, and generating code that doesn't integrate with Simulink.

MATLAB is also used in regulated industries (aerospace, automotive, medical devices) where code quality and traceability requirements are strict. AI rules for MATLAB need to address both performance and compliance.

Rule 1: Vectorize Everything

The rule: 'Use vectorized operations instead of for-loops for all element-wise computations. Instead of looping over array elements, operate on the entire array: result = A .* B + C. Use logical indexing instead of if-statements inside loops: A(A > threshold) = threshold. Use matrix operations (*, /, \) for linear algebra — never loop over rows/columns. Use bsxfun or implicit expansion for broadcasting.'

For common patterns: 'Instead of looping to sum: use sum(A). Instead of looping to find max: use max(A). Instead of looping to apply a function: use arrayfun or cellfun (but prefer vectorized alternatives when they exist). Instead of growing arrays in loops: preallocate with zeros() or NaN() before the loop.'

Vectorization is MATLAB's superpower. The interpreter is slow for scalar operations but fast for matrix operations (which call optimized LAPACK/BLAS under the hood). A rule that forces vectorization turns 10-minute scripts into 1-second scripts.

• Element-wise operations: .*, ./, .^ — not for-loops
• Logical indexing: A(A > 0) = 0 — not if inside for
• Matrix operations: A * B, A \ b — not row-by-row loops
• sum(), max(), mean(), std() — not manual accumulation loops
• arrayfun/cellfun as last resort — prefer vectorized alternatives

Rule 2: Preallocate Arrays

The rule: 'Always preallocate arrays before loops that fill them. Use zeros(n, m), ones(n, m), NaN(n, m), or cell(n, 1) to create arrays of the correct size before the loop starts. Never grow arrays inside loops — result = [result; newRow] copies the entire array on every iteration, turning O(n) operations into O(n^2).'

For dynamic sizes: 'If the final size isn't known, overallocate and trim: result = zeros(1000, 1); count = 0; ... result = result(1:count). Or use cell arrays to collect results and vertcat at the end: results = cell(n, 1); ... results = vertcat(results{:}). Both are dramatically faster than incremental growth.'

This is the second most impactful MATLAB rule after vectorization. Growing an array inside a loop is O(n^2) because MATLAB copies the entire array into a new larger block on every append. Preallocation makes it O(n).

Rule 3: Functions Over Scripts

The rule: 'Write functions, not scripts, for all reusable code. Functions have their own workspace (no variable leaking), can be unit-tested, support input validation with arguments blocks (R2019b+), and enable MATLAB's JIT compiler to optimize more aggressively. Scripts are only for top-level orchestration — never for logic that should be reusable.'

For the arguments block: 'Use the arguments block (R2019b+) for input validation: arguments; x (1,:) double {mustBePositive}; name (1,1) string = "default"; end. This replaces manual inputParser and narginchk — it's clearer, faster, and the IDE provides autocompletion.'

For project structure: 'Organize code in packages: +mypackage/myfunction.m. Use namespaces to avoid function name collisions. Put shared utilities in a +utils package. Entry points (scripts that run the analysis) go in the project root or a scripts/ directory.'

Rule 4: Modern MATLAB Features

The rule: 'This project uses MATLAB R2023b (specify your version). Use string arrays ("text") instead of character arrays ('text'). Use table and timetable for structured data instead of cell arrays of mixed types. Use the dictionary type (R2022b+) for key-value data. Use enumeration classes for fixed categories. Use the arguments block for function signatures.'

For string handling: 'Use string functions: contains(), replace(), split(), join(). Never use strfind, strrep, or regexp for simple string operations — string functions are clearer and often faster. Use compose() for formatted strings instead of sprintf when building string arrays.'

For data: 'Use readtable/readtimetable for file I/O — never textscan or fscanf for structured data. Use table operations: sortrows, join, groupsummary, rowfun. Tables have named columns, type safety, and metadata — cell arrays have none of this.'

• String arrays ("text") over char arrays ('text')
• table/timetable for structured data — not cell arrays
• dictionary for key-value (R2022b+) — not containers.Map
• arguments block for input validation — not inputParser
• readtable for file I/O — not textscan/fscanf
• enumeration classes for categories — not magic strings

Rule 5: Simulink Model Conventions

The rule: 'Use Simulink model referencing for large models — break into subsystems with Model Reference blocks. Use Bus Objects for structured signal routing between subsystems. Name all signal lines — never leave unnamed wires. Use enumerated types for mode signals. Follow the MAAB (MathWorks Automotive Advisory Board) modeling guidelines for industry compliance.'

For code generation: 'If generating C code from Simulink (Embedded Coder), configure models for code generation from the start: use fixed-step solvers, specify data types explicitly (no doubles for embedded targets), and use Simulink.Signal and Simulink.Parameter objects for calibratable values.'

For testing: 'Use Simulink Test for model testing. Define test harnesses for each subsystem. Use signal builder blocks for test inputs. Run back-to-back testing (SIL/PIL) to verify generated code matches model behavior. Achieve MC/DC coverage for safety-critical models (DO-178C, ISO 26262).'

Complete MATLAB Rules Template

Consolidated rules for MATLAB and Simulink projects.

• Vectorize: .*, logical indexing, matrix ops — for-loops only when unavoidable
• Preallocate arrays with zeros/NaN before loops — never grow with [result; new]
• Functions over scripts — arguments block for validation — packages for namespacing
• Modern MATLAB: string arrays, tables, dictionary, readtable — specify R version
• Simulink: model referencing, Bus Objects, named signals, MAAB guidelines
• Code generation: fixed-step, explicit types, Signal/Parameter objects
• Simulink Test: test harnesses, SIL/PIL back-to-back, MC/DC coverage
• mlint/checkcode clean — Code Analyzer zero warnings — MATLAB Unit Test framework