IsHermitian — Control Systems/Matrix Operations
Control_Systems/Matrix_Operations/IsHermitian · 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.
IsHermitian
Control Systems / Matrix Operations
A test, not a transform: the output is 1 when the input matrix passes and 0 when it does not.
- Hermitian – u(i,j) = conj(u(j,i)) for every entry, i.e. u = uH.
- Skew-Hermitian – u(i,j) = −conj(u(j,i)) for every entry, i.e. u = −uH.
On an ICore signal this is the symmetry test, and that is not an
approximation. Every ICore signal is real, and conj(x) is
x for a real number – so the two conditions above are
symmetry and skew-symmetry, and this block computes exactly what
IsSymmetric computes. Simulink's own IsHermitian handed real matrices
answers the same way. The block keeps its own identity so that a Simulink model
containing one imports, runs and exports back to an IsHermitian rather than being
quietly rewritten into the other block.
A non-square input is not an error: it cannot be Hermitian under either test, so the answer is 0. Simulink's block answers the same way.
Ports
- u – the matrix to test, of any size [m,n]. Only a square one can pass.
- Output – a 1×1 signal carrying 1 or
0. ICore has no boolean signal type – every signal is a double
– so the verdict arrives as those two values rather than as a logical.
Simulink's block emits a genuine
boolean, which is the one difference across the bridge and costs nothing, since 1 and 0 are what a boolean compares equal to.
Parameters
- Hermitian Type – which test to apply. This selects the code path
rather than retuning one, so each option is a separate branch in all ten export
targets.
- Hermitian – u = uH. The default, as in Simulink.
- Skew-Hermitian – u = −uH. A skew-Hermitian matrix has an imaginary diagonal in general; on a real signal imaginary means zero, so here every diagonal entry must be exactly 0 and a matrix with any nonzero on its diagonal fails. That last part is the signal model talking, not the mathematics.
- 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. Nothing is exposed as a tunable parameter: which entries are compared is structural and is fixed into the generated code at export time, as one explicit comparison per entry pair rather than a call to each language's own Hermitian helper. Where the input's SHAPE already decides the answer – a non-square input, or a 1×1 – every target emits the constant instead of a comparison. The three HDL targets are fully synthesizable: exact comparisons and two constants, with no arithmetic.
The HDL cores test QUANTIZED values, which is worth knowing before reading a red row. An HDL port carries Q16.16, so two entries that differ by less than one quantum (1.5×10−5) arrive equal and the hardware answers 1 where the reference answers 0. A matrix built by scaling one signal – where the entries differ by a fixed factor rather than a small one – is unaffected.
Simulink bridge
Import and export, mapped to simulink/Matrix Operations/IsHermitian.
"Hermitian Type" goes to Mode, one option for one option
(Hermitian, Skew-Hermitian), so that round trip is lossless.
The rate does NOT cross: Simulink's IsHermitian defines only
Mode, with no SampleTime, so the entry sets
hasSampleTimeParam = false and "Sampling Time (s)" stays on the
ICore side. Writing that parameter anyway would be a hard set_param
error in MATLAB rather than a warning, aborting the whole generated script.
Notes
- Algebraic, with no state: the output depends only on the current input.
- The comparison is EXACT, as Simulink's is – neither side has a
tolerance parameter. A matrix assembled by floating-point arithmetic is usually
only Hermitian to within a rounding error, so expect this block to answer 0 for
one that is Hermitian on paper:
A + A'is exactly so, but a product such asC'·Cgenerally is not. - On ICore's real signals this block and IsSymmetric compute the same thing, the conjugate of a real number being itself. Both exist so that a Simulink model containing either imports and exports back to the same block rather than being quietly rewritten into the other.
- No state space: the block is a comparison, not a linear map, so no D·u represents it and model reduction reports it as unmergeable.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Matrix_Operations/IsHermitian |
| family | Control_Systems/Matrix_Operations |
| solver environment class | ICoreBlock_0_Control_Systems_1_Matrix_Operations_2_IsHermitian |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Matrix_Operations/IsHermitian/ICoreBlock_0_Control_Systems_1_Matrix_Operations_2_IsHermitian.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Matrix_Operations/IsHermitian/ICoreBlock_0_Control_Systems_1_Matrix_Operations_2_IsHermitian.h |
| default size on canvas | 75 × 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 | — |
| 2 | out | ICoreDouble | — |
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 |
|---|---|---|
Hermitian Type | Hermitian%~%Skew-Hermitian~~Hermitian | Mode |
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::Both |
| Simulink path | simulink/Matrix Operations/IsHermitian |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Hermitian Type | Mode | Hermitian → Hermitian, Skew-Hermitian → Skew-Hermitian |
Caveat (shown to the user): the rate does not cross: Simulink's IsHermitian defines only Mode, with no SampleTime, so "Sampling Time (s)" stays on the ICore side. Simulink's output is a genuine boolean where ICore's is a 1/0 double, every ICore signal being a double.
Catalog contract: src/ICoreSDK/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).
IsHermitian block -- 1 when the input matrix is Hermitian, 0 when it is not Two tests, chosen by "Hermitian Type": Hermitian u(i,j) = conj(u(j,i)) for every i, j Skew-Hermitian u(i,j) = -conj(u(j,i)) for every i, j
ON ICORE'S REAL SIGNALS THIS IS THE SYMMETRY TEST, and that is not an approximation. conj(x) is x for a real number, so the two conditions above ARE symmetry and skew-symmetry, and this block computes exactly what IsSymmetric computes. It was confirmed against the real Simulink block rather than assumed: fed the real [1 2; 2 3] its Hermitian mode answers true, and fed the real [0 2; -2 0] its Skew-Hermitian mode answers true -- the same verdicts IsSymmetric gives.
SO WHY HAVE BOTH. Because the Simulink library has both, as separate blocks, and the bridge maps a type to exactly one counterpart. A model containing an IsHermitian has to import, run and export back to an IsHermitian; folding it into IsSymmetric would silently rewrite the user's model into a different one that happens to agree on real signals. It is the same argument Hermitian Transpose makes next door, and the same one Squeeze makes.
NOTE THE ONE PLACE THE TWO BLOCKS' DEFAULTS DIVERGE FROM EACH OTHER'S NAMES: this block's skew test does NOT force a zero diagonal in general -- a Hermitian matrix has a REAL diagonal and a skew-Hermitian one an IMAGINARY diagonal -- but on real signals imaginary means zero, so here it does. The description says which of those is the signal model talking and which is the mathematics.
A NON-SQUARE INPUT IS NOT AN ERROR. It cannot be Hermitian under either test, so the answer is simply 0 -- confirmed against the real Simulink block, which returns false for a 3x2 rather than refusing to compile. The shape is known at export time, so the generated cores for such a rig emit the constant 0 rather than a comparison that could never be true.
THE COMPARISON IS EXACT, as Simulink's is: neither block has a tolerance parameter. That is the block's one sharp edge for a user, because a matrix ASSEMBLED by floating-point arithmetic is usually only Hermitian to within a rounding error -- A + A' is exactly so, but C'*C generally is not. The description says so where it will be read.
WHY THE PREDICATE IS A LIST OF PAIRS. Every test in this family (this block, IsSymmetric and IsTriangular) reduces to "these entries must equal these entries, possibly negated". Emitting from that list rather than from a hand-written condition per language is what keeps the ten backends agreeing about which pairs are compared and in which direction.
Sample results#
| t | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 |
|---|---|---|
| 0 | -2 | 1 |
| 0.4 | 0.5 | 1 |
| 0.8 | -2 | 1 |
| 1.2 | 0.5 | 1 |
| 1.6 | -2 | 1 |
| 2 | 0.5 | 1 |
| 2.4 | -2 | 1 |
| 2.8 | 0.5 | 1 |
| 3.2 | -2 | 1 |
| 3.6 | 0.5 | 1 |
| 4 | -2 | 1 |
| 4.4 | 0.5 | 1 |
| 4.8 | -2 | 1 |
| 5.2 | 0.5 | 1 |
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 ccf005c8 · produced by docsSample --out <folder> --steps 60 · data docs/generated/samples/Control_Systems__Matrix_Operations__IsHermitian.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).