matlab-fit-curve

# Interactive Curve and Surface Fitting

Guides interactive curve and surface fitting through the Curve Fitter app as part of the Curve Fitting Toolbox. Covers the full in-app workflow of selecting data, exploring fit types, modifying with fit options, inspecting fits visually and numerically, then exporting results.

## When to Use

**No-code fitting**
- Users who want to fit curves or surfaces without writing code
- Users who want to start interactively and generate code later to continue in the command line

**Interactive exploration**
- Exploring fit types when the best model is unknown
- Iterating on fits with visual feedback
- Maintaining and comparing multiple fits in a single session
- Discovering available fit types, options, and features

**App-specific features**
- Exporting fits to Simulink lookup tables (only available through the app)
- Excluding data points or regions iteratively with visual feedback
- Loading or continuing a saved session (`.sfit`) for convenience or collaboration

## When NOT to Use

**CLI workflows (no app involvement)**
- User is already writing code and does not want the app involved
- Using `fit()`, `fittype()`, `fitoptions()` directly in their own scripts/functions
- The desired fit type, data, and options are already known and the user wants code
- Many fits that would be difficult to manage in the app

**Spline workflows**
- Spline CLI functions (`csapi`, `csaps`, `fnbrk`, etc.)
- `splinetool` or `bspligui` apps

**Other tools and domains**
- Base MATLAB functions — `interp1`, `pchip`, `scatteredInterpolant`, `griddedInterpolant`, `spline`, `smoothdata`
- Basic Fitting tool — polynomials, spline interpolant, pchip interpolant; built into MATLAB figures
- Statistics and Machine Learning Toolbox — statistical modeling, cross-validation, dataset partitioning, separate test data (`fitlm`, `fitnlm`, `cvpartition`)
- Optimization Toolbox — any workflow using Optimization Toolbox functions (`lsqnonlin`, `fmincon`, `lsqcurvefit`, `lsqlin`)

If CLI is the better approach, do not suggest app workflows. If neither section clearly applies, use these signals to disambiguate:

| Signal | Recommendation | Why |
|--------|---------------|-----|
| User says "compare" fits | **Depends** | Visual curve comparison -> CLI (overlaid on same axes). Comparing goodness of fit metrics -> App (Table of Fits). Interactive adjustment -> App. |
| User just wants to visualize a single fit | **CLI** | CLI plotting handles this well |
| User wants to overlay multiple fits on same axes | **CLI** | App shows fits in separate figures only |
| User needs to exclude outliers by visual inspection | **App** | Point-and-click exclusion is easier than computing indices |
| User needs formal validation data | **App** | The app has explicit validation data support |

**User instructions always take precedence.** If the user explicitly asks for CLI code — even mid-app-workflow — write CLI code. The agent may also offer CLI as an alternative when the controller cannot fulfill a request.

Do not spontaneously switch between app and CLI mid-workflow. If the user's intent is still unclear after consulting the table above, ask whether they prefer working interactively in the app or with code.

If the user asks how to perform a workflow themselves, where to find a feature in the UI, or whether a capability is available in the app, see `references/curve-fitter-layout.md` for the full layout and feature locations.

## Must-Follow Rules

### Release Compatibility

1. **Use `cftool` for R2021b and earlier; `curveFitter` for R2022a+** — never instruct the user to use both in the same workflow. Users often say "cftool" out of habit on R2022a+ — still use `curveFitter` or the controller regardless of user terminology.
2. **`CurveFitterAppController` (`scripts/CurveFitterAppController`) requires R2022a+** — it will error on earlier releases. On R2021b and earlier, the agent CANNOT read or write app state programmatically. The only programmatic interaction is `cftool` input arguments (`cftool(x, y)`, `cftool(x, y, z)`, etc.). All other actions (changing fit types, excluding points, exporting) must be performed by the user through the app UI — guide them using general knowledge of cftool, don't promise action. `getFittypeTable()` still works independently for discovering fit types. On R2022a+, prefer the controller's `open*` methods to launch the app (they handle version checking internally). On pre-R2022a, set expectations upfront: everything besides launching the app or launching the app with data is unsupported for agentic workflows on this release — you can guide the user through the UI but cannot perform actions for them. Offer CLI fitting as an alternative path. Don't let users discover limitations one by one.

   **Critical for pre-R2022a:** On these releases, ALL of the following apply:
   - Refer to the app ONLY as "cftool" or "the Curve Fitting Tool" — never "Curve Fitter"
   - Do not mention ANY controller method names (setExclusionRule, setFittype, etc.) — they do not exist on this release
   - Do not imply you can perform actions inside the app — you cannot
   - If the user says "Curve Fitter" on R2021b or earlier, say "The Curve Fitter app isn't available in [release]. I'll use cftool instead."

### API Usage

3. **Drive the app workflow via the controller API — do not spontaneously switch to CLI** — once the app is open or the user is working in the app, fitting, comparison, and exclusion work goes through the controller. Do not spontaneously generate CLI `fit()` code as a substitute for app actions. Do not pause and instruct users to click UI elements. Exceptions:
   - The user explicitly requests CLI code (user instructions always take precedence)
   - The controller has no API for the requested action — guide the user through the app UI via `references/curve-fitter-layout.md` first. Only offer CLI as an alternative if the feature isn't available in the app or the workflow is trending towa