In some fields its quite common to implement state machines in an imperative style with if-blocks and flags. That should be possible with Copapy by having decorated functions where the decorator parses the AST and replaces if-blocks with cp.iif() to end up with branchless code.
However, from my experience this programming style is ok for simple state machines, but it’s definitely not great, and if things get more complex, it’s getting really hard to keep it comprehensible and correct.
I think the main challenge is the design of an API that fits state machines. Concerning the WCET, branchless code should be on average not worse than branched code.
Casadi uses either an interpreter or emits c-code, where Copapy directly runs machine code. Would be very interesting to benchmark Copapy against compiled Casadi c-code – looking into it.
Thanks for your comment, I'll give a full write up a try.
I think for deterministic control applications this concept has a sweet spot. While in conventional code the number of branch combinations can blow up easely, here you need to be able to guarantee worst case execution time which forces you anyway to be very carefull with branching.
On https://copapy.nonan.net/compiler.html is the how-it-works readme section extended with the generated machine code for stencils and a simple example.
What about correlating transmitted wireless frames with a LED flashing pattern? If the glasses stream video with a variable bitrate codec over wireless, flashing vs. non-flashing should change bandwidth and therefore frame frequency. However, with searching over all channels this might be quite slow in practice.
For non-professional application it’s not the cheapest option, however on the used marked I payed 82 € for my last ethernet bus cupper plus 3 digital IO terminals. Often used Beckhoff variants of the functional identical terminal are a little bit cheaper than WAGO – might have to do with the different market segment they targeting. In a professional setting the hardware costs compensate often easily for saved working hours in debugging flimsy screw terminal connections and dubious firmware flaws. Also, the cheap options often need more than 5 times the control cabinet real estate per IO, witch alone can compensate for the higher price.
To avoid the discussion where around the critical point it is a gas or not a gas ;) Sure, for ideal gases it’s quite clear; however I’m looking for adding real gas behavior to capture high density supercritical fluids - being able to model high pressure processes. For example for the synthesis of hydrocarbons and chemical compound made from nitrogen and hydrogen.
I would say it depends on the application: For energy stuff, ideal gas + water/steam might be sufficient. Rolling a lightweight process simulation framework (e.g. on top of gaspype and pint) easily competes with the costs for an aspen license. For other applications, that requires solving multiple phases of mixtures, the tradeoff shift quite allot.
That looks like a valuable resource, thank you! I already mostly stuck to a subset supported by NumPy and JAX (because that's the array libraries I'm familiar with). I hope the other are not to far off...
However, from my experience this programming style is ok for simple state machines, but it’s definitely not great, and if things get more complex, it’s getting really hard to keep it comprehensible and correct.
I think the main challenge is the design of an API that fits state machines. Concerning the WCET, branchless code should be on average not worse than branched code.