Repository navigation
Specialize feedback index keywords for strict compilation - #1097
Conversation
|
This is an automated message.
|
|
This is an automated message.
|
|
This is an automated message.
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1097 +/- ##
=======================================
Coverage 92.29% 92.29%
=======================================
Files 42 42
Lines 6177 6177
=======================================
Hits 5701 5701
Misses 476 476 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
This is an automated message.
|
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>






























The objective is to compile numerical state-space interconnections to WebAssembly with strict trim verification. This draft specializes the state-space
feedbackindex keywords explicitly, for exampleU1::TU1=:withwhere TU1. It contains no inlining annotations and no frequency-response changes.Colon <: Function. Without explicit keyword type parameters, the tested feedback entry point reaches indexing with arguments inferred as abstractFunction. Strict trim verification then fails into_index(::Function)and generic function display. Explicit keyword type parameters remove this abstract indexing path without inliningfeedbackor adding a constant-propagation annotation.A separate diagnostic path still interpolates
Colonvalues into the dimension errors, which reaches generic function display. The two dimension errors therefore identify the argument names without interpolating their values.Validation of this revision:
feedbackfails strict trim verification with the original implementation. Typed keywords remove the abstract indexing diagnostics; typed keywords plus the reduced error messages compile and execute in Node.Additional investigation, outside this diff:
extended_gangoffour(P, C, false)instead ofgangoffour. The unusedpos=truebranch exposes an inference failure through block concatenation (typed_hvcatstores block rows inVector{Any}). A call-site@inlineonextended_gangoffourmakes the small example and the motor analysis compile, but both trap during execution invcat. Consequently the extended-system replacement is not yet validated for the application. Nogangoffourorextended_gangoffourannotation is proposed here.freqresploop was a workaround using StaticArrays linear algebra. The vector method is the intended performance direction: one Hessenberg reduction followed by workspace reuse across frequencies. A small vector-frequency example with dense matrices fails WasmCodegen compilation on unsupported foreign calls, including LAPACKdgehrd_64_anddorghr_64_. A static-matrix example encounters inference failure through the balancing path. These are separate from feedback specialization.@constprop :aggressiveon scalarfreqrespmakes a small scalar entry point compile without inlining eitherfreqrespor_balance, but that exploratory change is excluded from this PR because the vector method should be investigated instead.Related: ModelingToolkit.jl issue 5316, ModelingToolkit.jl PR 5320, ModelingToolkit.jl PR 5324, and WasmCodegen.jl issue 5.
Host: demeter2
Session: Codex 01a16eb7-f44a-7760-b6e2-65dd2fa345bd
Working directory: /home/baggepinnen/repos/ControlSystems-wasm-pr