Polynomial Coefficients — Control Systems/Polynomials
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.
polyaccumulates 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#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Polynomials/Polynomial_Coefficients |
| family | Control_Systems/Polynomials |
| solver environment class | ICoreBlock_0_Control_Systems_1_Polynomials_2_Polynomial_Coefficients |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Polynomials/Polynomial_Coefficients/ICoreBlock_0_Control_Systems_1_Polynomials_2_Polynomial_Coefficients.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Polynomials/Polynomial_Coefficients/ICoreBlock_0_Control_Systems_1_Polynomials_2_Polynomial_Coefficients.h |
| default size on canvas | 126 × 70 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 | r |
| 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#
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.
Simulink bridge#
| support | Support::None |
| Simulink path | — |
| port-count rule | PortsParam::None |
SampleTime parameter | yes |
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#
| t | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 [2x1] entry 0 |
|---|---|---|
| 0 | -2 | [1, 2] |
| 0.4 | 0.5 | [1, -0.5] |
| 0.8 | -2 | [1, 2] |
| 1.2 | 0.5 | [1, -0.5] |
| 1.6 | -2 | [1, 2] |
| 2 | 0.5 | [1, -0.5] |
| 2.4 | -2 | [1, 2] |
| 2.8 | 0.5 | [1, -0.5] |
| 3.2 | -2 | [1, 2] |
| 3.6 | 0.5 | [1, -0.5] |
| 4 | -2 | [1, 2] |
| 4.4 | 0.5 | [1, -0.5] |
| 4.8 | -2 | [1, 2] |
| 5.2 | 0.5 | [1, -0.5] |
Every 4th of 60 samples, from the table stimulus.
The same rig also ran:
| Stimulus | What it is | Output range |
|---|---|---|
impulse | Impulse: one sample of 1 at k = 5, 0 elsewhere (Repeating Sequence Stair) | 1 … 1 |
ramp | Ramp: slope 1 from t = 0 | 1 … 1 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | 1 … 1 |
step | Step: 0 -> 1 at t = 1 s | 1 … 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).