Generated reference › Polynomial Coefficients — Control Systems/Polynomials
kind: generated#block#control-systems-polynomials

Polynomial Coefficients — Control Systems/Polynomials

r → c

Control_Systems/Polynomials/Polynomial_Coefficients · 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 Coefficients

Control Systems / Polynomials

Builds the monic polynomial whose roots are the input. With L roots r, the output is ∏(x − ri) = xL + c₁xL−1 + … + cL, written in descending powers, so entry k is (−1)k·ek(r) – the sum of every product of k distinct roots – and entry 0 is exactly 1. This is MATLAB's poly.

It is the counterpart of the blocks that consume a coefficient vector: wire it into Curve Fitting / Evaluate Fit to evaluate the polynomial somewhere, or into Curve Fitting / Fit Derivative to differentiate it.

Ports

  • r – the roots, as a vector of L entries: a column [L,1] or a row [1,L]. Order does not matter. L is at most 8 – see Notes for why.
  • c – the coefficients, descending powers, with L + 1 entries and the same orientation as the input.

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.

Every entry is emitted as one flat sum of signed products of the input entries, so a generated core runs no recurrence, keeps no scratch array and performs no division. The three HDL targets are therefore genuine synthesizable Q16.16: each product is accumulated at full width and shifted back once per factor.

Simulink bridge

None (Support::None). poly is a MATLAB function, and the Symbolic Math Toolbox it is proposed from ships no Simulink library at all, so there is no library 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

  • Algebraic, with no state: the output depends only on the current input.
  • Eight roots is the ceiling, and the bound is on the generated FILE. The expansion is 2L − 1 products, unrolled in ten languages – 255 of them at L = 8. A longer root list is refused, with that reason, rather than truncated.
  • The roots are real. An ICore wire carries real doubles, so a complex conjugate pair cannot be written on one. For a complex pair, form its quadratic factor x² − 2·Re(r)·x + |r|² and multiply it in with Correlation And Convolution / Convolution, which is polynomial multiplication.
  • Monic by construction. Entry 0 is the literal 1 in every target. A polynomial with a leading coefficient other than 1 is this output scaled by it, which a Gain supplies.
  • The summation order is the expansion's, not MATLAB's. poly accumulates by a convolution recurrence; this adds the terms of each ek in subset order, so the two agree to rounding rather than bit for bit. Measured on r = [0.7 −1.3 0.45 2.1], R2026a reports [1, −1.95, −1.4950000000000001, 2.8874999999999997, −0.85994999999999999] and this expansion [1, −1.95, −1.4950000000000003, 2.8875, −0.85995] – about 2e−16 relative. All ten exported targets share this block's order, which is what the export comparison checks.
  • No state space: the map is a polynomial in the input rather than a linear one, so there is no A/B/C/D to merge and model reduction correctly declines it.

Code facts#

FactValue
registered typeControl_Systems/Polynomials/Polynomial_Coefficients
familyControl_Systems/Polynomials
solver environment classICoreBlock_0_Control_Systems_1_Polynomials_2_Polynomial_Coefficients
sourcesrc/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Polynomials/Polynomial_Coefficients/ICoreBlock_0_Control_Systems_1_Polynomials_2_Polynomial_Coefficients.cpp
headersrc/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Polynomials/Polynomial_Coefficients/ICoreBlock_0_Control_Systems_1_Polynomials_2_Polynomial_Coefficients.h
default size on canvas126 × 70 px
ports at insert1 in, 1 out
code generators implementedPython, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text

Ports#

#DirectionSignal typeDescription label
1inICoreDoubler
2outICoreDoublec

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#

No config variable beyond the Sampling Time (s) every block carries.

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.

supportSupport::None
Simulink path—
port-count rulePortsParam::None
SampleTime parameteryes

Caveat (shown to the user): building a polynomial from its roots is a MATLAB function (poly), not a Simulink library block -- the Symbolic Math Toolbox this block answers 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 lists agree. check_block_descriptions.py finds no disagreement between the description's Ports, Parameters, Code export and Simulink bridge lists and the code's.

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 Coefficients -- poly on a wire Entry k of the output is (-1)^k * e_k(r), the elementary symmetric polynomial of the L roots arriving on the input, so the output is the MONIC polynomial having exactly those roots written in descending powers. Entry 0 is the literal 1.

THE EXPANSION IS THE EXPORT STRATEGY. Every output entry is one flat sum of signed products of input entries, enumerated by ICorePolynomialTermsSupport from the input's LENGTH alone. No recurrence, no scratch array, no division: all ten targets emit straight-line multiply-accumulate and the three fixed-point ones carry it as genuine Q16.16.

Verified against MATLAB R2026a rather than asserted. On r = [0.7 -1.3 0.45 2.1]:

poly(r) 1 -1.95 -1.4950000000000001 2.8874999999999997 -0.85994999999999999 this expansion 1 -1.95 -1.4950000000000003 2.8875 -0.85995

⚠ THE SUMMATION ORDER IS THE EXPANSION'S, NOT MATLAB'S, and the last three entries above are what that costs: about 2e-16 relative. MATLAB builds the coefficients by a convolution recurrence and this block adds the terms of e_k in subset order, so the two agree to rounding rather than bit for bit. What matters here is that the block's own C++ reference uses the SAME order as the ten emitted bodies, which it does: one helper produces the term list for all eleven, and it is the reference the export comparison actually checks against.

Sample results#

Polynomial Coefficients — Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per samplePolynomial Coefficients — Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample0.90.9511.051.1-2-10123inputoutput
tin ICoreDouble-Out-0out ICoreDouble-Out-0 [2x1] entry 0
0-2[1, 2]
0.40.5[1, -0.5]
0.8-2[1, 2]
1.20.5[1, -0.5]
1.6-2[1, 2]
20.5[1, -0.5]
2.4-2[1, 2]
2.80.5[1, -0.5]
3.2-2[1, 2]
3.60.5[1, -0.5]
4-2[1, 2]
4.40.5[1, -0.5]
4.8-2[1, 2]
5.20.5[1, -0.5]

Every 4th of 60 samples, from the table stimulus.

The same rig also ran:

StimulusWhat it isOutput range
impulseImpulse: one sample of 1 at k = 5, 0 elsewhere (Repeating Sequence Stair)1 … 1
rampRamp: slope 1 from t = 01 … 1
sineSine Wave: amplitude 1, 2 rad/s, no phase, no bias1 … 1
stepStep: 0 -> 1 at t = 1 s1 … 1

Plotted: table — Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample

Category static · sample time 0.1 · 60 steps · commit ba0d5f47abbf16b9e248ecce5a0d14210ec2f9d7 · produced by docsSample --out <folder> --blocks Polynomial_Coefficients Characteristic_Polynomial Pade_Approximant --steps 60 · data docs/generated/samples/Control_Systems__Polynomials__Polynomial_Coefficients.json · the SVG is generated from those numbers by tools/docs/plot_svg.py, so it is a run and not a drawing (R-D10).