Evaluate Fit — Control Systems/Curve Fitting

Evaluate Fit

Control Systems / Curve Fitting

Evaluates a polynomial whose coefficients arrive on a port: y = c₀·x^L−1 + c₁·x^L−2 + … + c_L−1, entry by entry over x, with the coefficients in descending powers. This is MATLAB's polyval with the first argument taken from a signal.

It is the reading half of Curve Fitting: wire Polynomial Fit into c to read a fit that is recomputed every sample, or put Fit Derivative or Fit Integral in between to read the slope or the area instead.

Ports

• c – the coefficients, descending powers, as a vector of L entries: a column [L,1] or a row [1,L]. A scalar is a constant polynomial, and the output is then that constant everywhere.
• x – where to read the curve. Any size [m,n], applied entry by entry, so one block can read the same curve at several points at once.
• y – the value, of the same size as x. The block never reshapes a signal; the coefficient port does not affect the output's size.

Parameters

• 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. There is nothing to tune, so nothing is exposed as a parameter on the generated core – the coefficients are a signal, not a setting.

Every target evaluates by Horner's rule – the nested form ((c₀x + c₁)x + c₂)x + c₃ – and not by summing powers. The two are not the same computation in floating point, so this is what keeps the ten targets agreeing with each other and with this block's own simulation.

The three HDL targets are simulation-only. Horner needs nothing but multiplies and adds, which the Q16.16 datapath has, but a polynomial multiplies the signal by itself once per order and that format saturates at ±32768 while resolving only 1.5×10⁻⁵ – and here the coefficients are a signal, so their magnitude is not known at export time and no scaling can be folded in to compensate. The generated cores convert at the port boundary and evaluate in real arithmetic: correct in simulation, but not offered as synthesizable. Base Blocks / Polynomial makes the same call for the first of those two reasons.

Simulink bridge

None (Support::None). Simulink's own Polynomial block takes its coefficients as a dialog parameter, so it cannot represent this block – a mapping onto it would silently drop the port that makes this block different. polyval itself is a MATLAB function with no library path a diagram could name, and the Curve Fitting Toolbox ships no Simulink library at all. 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. For a diagram that must cross with constant coefficients, use Base Blocks / Polynomial, which is bridged.

Notes

• Algebraic, with no state: the output depends only on the current inputs.
• Use Base Blocks / Polynomial instead whenever the curve is fixed. That block inlines its coefficients, costs less in every target, and is bridged to Simulink. This one exists for a curve that changes every sample, which is the one thing a dialog parameter cannot hold.
• Reading outside the window is allowed and is not checked. Polynomial Fit writes its curve on x = −i·h with the newest sample at x = 0, so a negative x reads back into the window and a positive x extrapolates past its end – one-step prediction is exactly x = +h. Extrapolation is a legitimate use and also where a high-degree fit goes wrong fastest: the error grows like x^L−1.
• Horner's rule, in all ten targets. Not an optimization – it is what keeps the ten exports agreeing with each other and with this block.
• No state space. The relation is linear in the coefficients but polynomial in x, so the block carries none and model reduction correctly reports it as unmergeable. Fabricating a feed-through would let a reduction replace a curve with a straight line.