[SciPy-Dev] Pythonic Simulink clone... - how much interest?
Tue Nov 16 11:55:03 CST 2010
On Tue, Nov 16, 2010 at 12:29 PM, Joshua Holbrook
> On Tue, Nov 16, 2010 at 2:48 AM, burley <firstname.lastname@example.org> wrote:
>> Visual modeling support as offered by the Simulink/Matlab and Xcos/Scilab
>> suites is very powerful, for the modeler as well as in communicating
>> concepts and ideas to others. Neither is Pythonic or extendable by Python,
>> unfortunately (disregarding the prohibitively expensiveness of Sim/Matl).
>> Wouldn't it be *very* nice to have a free (LGPL++?), user extensible, Python
>> based Simulink alternative, based on Numpy, SciPy, Wx and/or Qt-like, and
>> the rest. All (e.g. most of) the algorithms are there, many would benefit. I
>> know of Viper (Tcl/Tk), Elefant (Bayesian Learning), ... but none of them is
>> general purpose or flexible in its use. Only a collaborative effort may make
>> that happen I would believe. What's the community interest in such an
>> effort? (I for myself am not a GUI programmer...).
>> -- Burley
>> SciPy-Dev mailing list
> I've done some thinking on this problem, though I haven't had the time
> to pursue anything directly. I started working on a graphical
> very far.
> I would say that there are two major issues that come in trying to
> build something simulink-esque. The first, obviously, is the issue of
> being able to build block diagrams in some sort of GUI and then
> translate those to a computer representation of a directed graph.
> While I think it's not something to be ignored, it's definitely been
> done before, and I think a nice way to describe these sorts of
> directed graphs in some sort of text format (python would work ;) )
> anyway--so, working from a computer representation first and making a
> gui tool tool to build said representations second could be the way to
> go. In fact, I think a generalized block diagram component would be
> pretty awesome, since there are many worthwhile variations of the
> graphical dataflow format besides Simulink (Yahoo! Pipes/Pypes,
> LabVIEW, PD, Excel).
> The other part, and the one that I think makes this actually
> difficult, is converting the block diagram into a solution. My
> understanding of what Simulink actually does to generate a solution is
> something like this:
> 1. Convert everything to be in the time domain (For example, transfer
> functions would need to be transformed).
> 2. Convert the graph to a state-space representation suitable for use
> with a RK-like method--that is, dx/dt = f(x) where x is a vector, and
> y = g(x), where y is a vector of all the things you want to put
> virtual O-scopes onto.
> 3. Apply an RK-like method to the state-space representation.
> 4. Profit!
> Matlab/Simulink give you lots of options for step (3), and this part
> can be looked up in any numerical methods textbook, so it's relatively
> easy to get a handle on. In fact, I'm sure scipy has RK methods in it
> somewhere if it can claim to be anywhere near complete. Similarly, I
> would hope part (1) to be fairly straightforward. The part that I
> didn't have much luck on is step (2), but my guess is that you would
> have to traverse the graph and try to unroll any loops using rules
> specific to 'special' blocks, such as "1/s" blocks. I'm not sure it
> can get any more general than that.
this sounds a bit what pylab works tries to do
Compared to graphical programming (and UML and Excel), programming
directly in Python is a lot more fun and flexible in my opinion. There
isn't a whole lot of boiler plate code to automate away.
> My $0.02,
> SciPy-Dev mailing list
More information about the SciPy-Dev