Polynomial Fit — Control Systems/Curve Fitting
Control_Systems/Curve_Fitting/Polynomial_Fit · 1 input / 1 output port(s) at insert · exports to Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text
Description#
The block's own DESCRIPTION_HTML, rendered verbatim — the same text the config dialog's info panel and the library navigator show. Fix a wrong sentence in the block's .cpp (R-D9), never here.
Polynomial Fit
Control Systems / Curve Fitting
Fits a least-squares polynomial of degree N to the last W samples and emits its coefficients, in descending powers: ŷ(x) = c₀·xN + c₁·xN−1 + … + cN. The newest sample sits at x = 0 and the sample i steps back at x = −i·h, so the curve is written in the window's own coordinates and the constant term is the fitted value at the present instant.
This is polyfit on a stream. It emits the curve rather
than one point of it, which is what a slope, a curvature, an extrapolation or an
area needs; the fitted VALUE alone is already
Signal Smoothing / Savitzky-Golay Filter.
Ports
- u – the sampled signal being fitted. Scalar: one channel and its own window – see Notes.
- c – the coefficient column, [N+1, 1], in descending powers. Its height follows Polynomial Degree alone and does not depend on the input, which is scalar.
Parameters
- Window Length – W, how many samples the fit sees. A whole number from 2 to 101, and it must be greater than Polynomial Degree: a polynomial of degree N needs more than N points to be determined. Bounded above because the dot products are unrolled at export.
- Polynomial Degree – N, the degree fitted. A whole number from 0 to 6, and less than Window Length. Degree 0 makes the single coefficient the window's mean; degree 1 makes the pair a slope and an intercept.
- Abscissa Step – h, the spacing between consecutive samples on the fitted axis. A single positive number. Leave it at 1 and the curve is written per sample, so a derivative comes out per sample; set it to the block's sampling period and the curve is written in seconds, so a derivative comes out per second. It rescales the coefficients exactly – the coefficient of xj carries h−j – and changes no fitted value.
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text.
The (N+1)×W coefficient bank is structural and is inlined into the arithmetic at export time rather than exposed as a tunable parameter: it follows from all three settings, and changing any of them changes how many multiplies and how many outputs the core contains, which no runtime parameter can do. Re-export after changing them.
The three HDL targets are genuine synthesizable Q16.16: a shift register and one fixed multiply-accumulate per coefficient, with the products accumulated at full width and shifted back once per row rather than per term. No solve reaches the hardware – it happened at export time. Note that a small Abscissa Step scales the higher coefficients by h−j, so a step well below 1 at degree 5 or 6 can leave the top coefficient outside the Q16.16 range; leave the step at 1 for the hardware targets and rescale downstream if that matters.
Simulink bridge
None (Support::None). Neither the Simulink standard
library nor the Curve Fitting Toolbox ships a block that fits a polynomial to a
running window – polyfit and fit are MATLAB
functions, and the toolbox has no Simulink library at all, so there is no path a
diagram could name. The bridge reports this block rather than dropping it
silently, and it therefore has no parity testbench; code export
verification still covers it across all ten languages. No configuration of it
crosses either, including "Sampling Time (s)", which has no counterpart to be
written to.
Notes
- Stateful, and discrete by nature
(
setDiscreteOnlyBlock(true)): the window advances once per sample. - One solve, then arithmetic. A least-squares coefficient vector is a linear function of the window, so the small normal-equation system is solved once when the configuration loads and every sample afterwards is (N+1) fixed dot products. Nothing inverts a matrix per sample, here or in any exported core.
- Verified against MATLAB. For the nine-sample window
[1.2 −0.7 2.5 0.3 −1.9 0.8 1.1 −2.2 0.45] at degree 3 and step
0.4 this block's coefficients match
polyfitto 4.4e−14 relative in R2026a; at degree 2 and step 1 over an eight-sample window, to 5.1e−15. - The window is zero-prefilled, and the zeros count. The first
W−1 coefficient vectors of a run are a startup transient in which
the fit sees samples that were never measured. A batch
polyfithas no such phase because it is handed the whole vector at once; a stream cannot. The convention matches Moving Median, Detrend and Savitzky-Golay Filter. - Scalar only. One channel and its own history; wire one block per channel. A shared window would mix them.
- Fitting is not smoothing. A high degree over a short window follows the noise: at degree N over W samples the fit has W−N−1 degrees of freedom left to reject anything with, and at W = N+1 it interpolates the window exactly and rejects nothing.
- No state space. The block is linear in its input, but its output depends on W past samples through a fixed filter bank rather than through an A/B/C/D pair, so it carries none and model reduction correctly declines to merge it.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Curve_Fitting/Polynomial_Fit |
| family | Control_Systems/Curve_Fitting |
| solver environment class | ICoreBlock_0_Control_Systems_1_Curve_Fitting_2_Polynomial_Fit |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Curve_Fitting/Polynomial_Fit/ICoreBlock_0_Control_Systems_1_Curve_Fitting_2_Polynomial_Fit.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Curve_Fitting/Polynomial_Fit/ICoreBlock_0_Control_Systems_1_Curve_Fitting_2_Polynomial_Fit.h |
| default size on canvas | 130 × 72 px |
| ports at insert | 1 in, 1 out |
| code generators implemented | Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text |
Ports#
| # | Direction | Signal type | Description label |
|---|---|---|---|
| 1 | in | ICoreDouble | u |
| 2 | out | ICoreDouble | c |
Ports the constructor creates. A block whose port list changes with its configuration adds or removes ports at load time; the count above is the one a freshly inserted block has.
Configuration variables#
| Config variable | Default | Simulink parameter |
|---|---|---|
Window Length | 8 | — |
Polynomial Degree | 2 | — |
Abscissa Step | 1 | — |
Every block also carries Sampling Time (s) from ICoreBlockSolverEnvironment: zero or less inherits the solver's rate, a positive value runs the block at that period.
Simulink bridge#
| support | Support::None |
| Simulink path | — |
| port-count rule | PortsParam::None |
SampleTime parameter | yes |
Caveat (shown to the user): fitting a polynomial to a running window is a MATLAB function (polyfit, fit), not a Simulink library block -- the Curve Fitting Toolbox ships no Simulink library at all -- so there is no path a diagram could name; the block is reported rather than dropped when a model crosses
Catalog contract: src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The checker has a blind spot here — it could not resolve something (a grouped port bullet, a computed config name), which is reported and never counted as a pass. A reader has to settle it:
B0no sample under docs/generated/samples/ — nothing to cross-check (P8.1)
The verdict above is
tools/docs/check_block_descriptions.py(P7.1), which compares LISTS. It cannot read a sentence: "stateless" on a block with a state, an initial-value semantic the recursion does not implement, a "not synthesizable" caveat the HDL banner contradicts. That is the agent audit (P7.3) on BLOCK_DESCRIPTION_AUDIT.md, and this tool's green is not a substitute for one.
File banner (developer view)#
The top comment of the block's .cpp — the maths, the realization and the export strategy, addressed to whoever changes it. It must not contradict the description above (P7.5).
Polynomial Fit -- the least-squares polynomial through the last W samples, as COEFFICIENTS MATLAB's polyfit(x, y, N) with the abscissa pinned to the sample grid: the newest sample at x = 0, the sample i steps back at x = -i*h. Output is the coefficient column in DESCENDING powers, which is the order polyfit returns and the order Base_Blocks/Polynomial consumes.
The whole normal-equation system is solved ONCE per configuration load. What every backend carries is (N+1) fixed dot products over one shift register -- see the header for why that is exact rather than an approximation, and why the solve runs in a scaled variable.
Measured against R2026a rather than assumed. For the nine-sample window [1.2 -0.7 2.5 0.3 -1.9 0.8 1.1 -2.2 0.45] at degree 3 and step 0.4, this derivation matches polyfit to 4.4e-14 relative; at degree 2, step 1 over an eight-sample window, to 5.1e-15.
Sample results#
No sample run is committed for this block. Samples come from the headless harness (DOCS_PLAN.md P8.1) into docs/generated/samples/; until one exists this block's behaviour is witnessed by the parity and export-verification suites, not by a plot here.