Move away from SLICOT?

[murrayrm]

Reported by Clancy Rowley on 2014-07-26
I'm considering rewriting some of the routines in python-control so that it will no longer depend on SLICOT. The main reasons for this are that 1) because SLICOT is written in Fortran, installation can be a pain (see several other comments in this forum); 2) SLICOT has apparently now gone closed-source; 3) most of the key functionality SLICOT provides (e.g., solving Lyapunov equations and Riccati equations) is now included in scipy.linalg, so I'm thinking this might not be too much of a pain.

Does anybody have thoughts or opinions on this?

[murrayrm]

Reported by Richard Murray on 2014-07-26
It would be great to get some input here from @repagh, @jgoppert and @robertobucher, since they have all been making contributions to the toolbox and working with SLICOT/slycot in various ways.

My feeling matches yours: the SLICOT interface is clunky and if we can do things in another way (especially using standard functionality in scipy) that would be preferred. The way we have things configured now, it should be possible to install python-control without using SLICOT, in which case you just lose the ability to call those functions that currently require SLICOT. So one way to approach this would be to simply start to replace functions that require SLICOT with python versions until we end up implementing everything in python. And if there is some advanced function that really requires SLICOT, we just leave that in as something that requires an optional package.

One things we should be careful about is that we don't require super recent versions of SciPy in order to run python-control. Do you know what versions of python and scipy are required to get the functions we will need. I think we want to maintain compatibility with python2.7 (widely used) and probably scipy0.13 or scipy0.14.

[murrayrm]

Reported by Clancy Rowley on 2014-07-28
The routines I was thinking of using from scipy.linalg (specifically, solve_lyapunov, solve_continuous_are, etc) appeared in SciPy version 0.11, which was released in Sep 2012. I think it would be reasonable to require at least this version of SciPy.

[repagh]

James Goppert (@jgoppert) added pypi support for slycot. This could be one
way of easing slycot problems, then for most people slycot would be
installable without much effort.

I agree the interface is clunky, but that is only a problem for
development, not for the end user. Slycot is more or less frozen (in the
sense that no-one is working on updates of the FORTRAN algorithms, and
using a newer version of the slicot fortran code involves all kinds of
vague license issues, seehttp://slicot.org/obtaining-slicot). Slycot
algorithms are however for the most part MIMO, which I would not like to
give up on, and the library as a whole (we are using and have implemented
python interfaces to only a small fraction) is quite comprehensive.

If alternative options are available that would reduce functionality, e.g.
MIMO to SISO, then I think slycot should remain 1st choice, and the
alternative would be a fallback/catch case for when slycot is not available.

If an alternative option becomes or is available, a transition from slycot
should be accompanied by one or more tests, to check that both
implementations produce the same result.

Should we have some check/init function, that checks for the proper scipy
implementation and the presence/version of slycot and or other used
libraries? That also simplifies the communication with people seeking help
for their problems.

All in all, I think reducing the dependency on slycot is no problem.

Greetings,

René

[murrayrm]

Even with PyPI support, don't you still have to have a FORTRAN compiler on your machine? That seems like the part that is problematic.

Agree that we want to support MIMO. Doing something where we check for slycot and use that if needed seems like a reasonable approach. If we get to the point where slycot is never needed, we can remove the dependency.

[jgoppert]

I agree that Slycot should be optional since a lot of users give up trying
to install Slycot on windows. I would still like to keep support for
Slycot as a back-end since the FORTRAN is much faster than native python or
c implementations and some users may want that performance. To ease the
install process on windows we could release Slycot binary installers.

The binary windows installer for Slycot could be created on a windows
machine with a fortran compiler with bdist:
python setup.py bdist --format=msi. Since it is fairly stable, hopefully we
wouldn't have to update this often.

For linux users python-control with Slycot can be installed with the
commands:
sudo apt-get install gfortran pip
sudo pip install python-control

So that is pretty smooth, but it takes awhile to compile.

-James

On Sun, Aug 10, 2014 at 9:44 PM, Richard Murray notifications@github.com
wrote:

Even with PyPI support, don't you still have to have a FORTRAN compiler on
your machine? That seems like the part that is problematic.

Agree that we want to support MIMO. Doing something where we check for
slycot and use that if needed seems like a reasonable approach. If we get
to the point where slycot is never needed, we can remove the dependency.

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

[roryyorke]

Dragging this discussion back from #77, here's my two cents:

• I understand @murrayrm's proposal is to fork Slycot under the "python-control" (Control Systems Library for Python) group, i.e., to (currently non-existent) http://github.com/python-control/Slycot
• GPL-licensed Slycot (probably?) can't be simply bundled into MIT-licensed python-control/python-control
• Slycot is currently languishing somewhat, e.g., unmerged bugfix Sb10ad fix synthesis.pyf jgoppert/Slycot#4 (by yours truly) and enhancement Added new wrappers for AB13BD, AB13DD, AB13ED and AB13FD jgoppert/Slycot#6 both date from mid-2015
• keeping track of forks on Github is not too difficult, e.g., https://github.com/avventi/Slycot/network; I imagine if a single project started incorporating improvements from the various forks, it would become the focus of development
• replacing SLICOT with a pure-Python alternative is a noble goal, but beware of discounting the value of such a large body of working code
• Windows builds of Slycot are available at [1], though I haven't tried them myself. I'm not sure what the implication of the "NumPy-1.10+MKL" dependence is

[1] http://www.lfd.uci.edu/~gohlke/pythonlibs/

[jgoppert]

I'm fine with moving slicot fork to python control. That way more of us
can maintain it.
On Mar 9, 2016 11:56 AM, "Rory Yorke" notifications@github.com wrote:

Dragging this discussion back from #77
#77, here's my
two cents:

• I understand @murrayrm https://github.com/murrayrm's proposal is
  to fork Slycot under the "python-control" (Control Systems Library for
  Python) group, i.e., to (currently non-existent)
  http://github.com/python-control/Slycot
  https://github.com/python-control/Slycot
• GPL-licensed Slycot (probably?) can't be simply bundled into
  MIT-licensed python-control/python-control
• Slycot is currently languishing somewhat, e.g., unmerged bugfix
  Sb10ad fix synthesis.pyf jgoppert/Slycot#4 Sb10ad fix synthesis.pyf jgoppert/Slycot#4 (by
  yours truly) and enhancement Added new wrappers for AB13BD, AB13DD, AB13ED and AB13FD jgoppert/Slycot#6
  Added new wrappers for AB13BD, AB13DD, AB13ED and AB13FD jgoppert/Slycot#6 both date from mid-2015
• keeping track of forks on Github is not too difficult, e.g.,
  https://github.com/avventi/Slycot/network; I imagine if a single
  project started incorporating improvements from the various forks, it would
  become the focus of development
• replacing SLICOT with a pure-Python alternative is a noble goal, but
  beware of discounting the value of such a large body of working code
• Windows builds of Slycot are available at [1], though I haven't
  tried them myself. I'm not sure what the implication of the
  "NumPy-1.10+MKL" dependence is

[1] http://www.lfd.uci.edu/~gohlke/pythonlibs/

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

[murrayrm]

I think it is fine to have SLICOT maintain its GPL license and python-control be BSD3-licensed, since they are separate repositories (just both maintained under the python-control project). So they are only bundled in the sense that python-control developers would maintain a fork (to @jgoppert's point about having more people maintaining it).

Long term, it seems like we should move away from SLICOT (requires FORTRAN compiler, not maintained, no longer open source, etc). But maybe better in the short term to pull things here so that features like issue #77 can be implemented quickly? Or will that just get us further mired into SLICOT...

[cwrowley]

This all sounds good to me. Even though we use only a small fraction of what is in SLICOT, rewriting even that portion would be a fair amount of work, so probably good to have a short term solution in the meantime. Might make a nice summer project for a student to work on writing new implementations of these routines, either in pure python/numpy, or cython.

[pmli]

Dear all,

I was genuinely surprised last year when I first saw that this issue exists here, in a control toolbox project. Now, I am even worried about what might happen if this project stops using SLICOT, as is being seriously purposed here. I believe the time and effort necessary to produce good numerical code is being greatly underestimated here. By "good code", I don't just mean "fast" (as is the case with SLICOT/FORTRAN), but much more. There is actually a whole list of disasters caused by numerical errors, costing immense amounts of money and even human lives! It is especially easy to imagine things going horribly wrong in control engineering due to poor implementations.

But, I don't want to just sound overly dramatic. First, I want to point out that SLICOT is a library developed and maintained for over 10 years (the earliest reference I found is from 1997) by numerical linear algebra experts, and used by Matlab (since version 7, released in June 2004), Octave, and Scilab. Next, I will go over concerns raised here and in issue #77.

"SLICOT is difficult to install"

This is not an issue of SLICOT or FORTRAN, but of Windows, in my opinion (I have no experience with Mac). I think that even people behind Windows can admit this, since they are introducing Bash to Windows.

On the other hand, I guess that most of the Matlab users do not use Linux, and if we want to convert them to Python, forcing them to also install Linux would likely not be very effective. But, if Matlab, Octave, and Scilab managed to create binaries for Windows and Mac, I don't see why it wouldn't be possible for python-control. @jgoppert and @roryyorke already proposed solutions here.

It was mentioned here and in #77 that SLICOT/Slycot requires a FORTRAN compiler to be installed. I'm not sure why is this an issue, since there is at least one free FORTRAN compiler.

@cwrowley made an interesting comment in issue #77:

[...] Last year I was encouraging students in my controls class to use python-control instead of Matlab, but everybody except the one or two Linux users had issues with installing SLICOT, and almost all gave up and went back to Matlab. [...]

I believe an ideal solution in this situation is providing students with a Linux virtual machine (using VirtualBox or a similar tool) with everything preinstalled. This way, students can focus on the real work, while being introduced to Linux and useful tools such as the terminal and Git. Also, all students then basically use the identical operating system, so it's much easier to resolve issues if they come up.

"SLICOT became closed source"

True, SLICOT was open source until version 5.0 (which is used in Slycot, and also in Octave), and later versions are available for no fee only for academic and non-commercial uses. But, a critical point is that version 5.0 was released in 2009, which means that this code matured and was battle-tested for at least 12 years.

Of course, this doesn't mean that development and maintenance of SLICOT can stop. Fairly recently, level-3 BLAS variants of Lyapunov equation solvers were developed. On the darker side, there is a bug in numerical rank revealing codes that persisted since LINPACK in the 1970s and spread to other libraries (including SLICOT), before being relatively recently discovered. Importantly, this is a known bug with a known fix. Optionally, SLICOT 5.5 released in 2012 can be obtained with no cost for academic and non-commercial use where this bug is fixed. Then, src folder in Slycot can be (privately) changed, or slicot/src folder can be linked to from Slycot. More changes in SLICOT can be found in the release notes.

"SLICOT is easy to replace with Python or SciPy"

From comments in this thread by @murrayrm, citing @cwrowley:

I'm considering rewriting some of the routines in python-control so that it will no longer depend on SLICOT. The main reasons for this are [...] 3) most of the key functionality SLICOT provides (e.g., solving Lyapunov equations and Riccati equations) is now included in scipy.linalg, so I'm thinking this might not be too much of a pain.

The routines I was thinking of using from scipy.linalg (specifically, solve_lyapunov, solve_continuous_are, etc) appeared in SciPy version 0.11, which was released in Sep 2012.

After taking a look at the current source code of SciPy, one can see that it's far from optimal. Function solve_lyapunov, for example, calls solve_sylvester, which sounds good in theory, but in practice it means that the Schur decomposition is computed twice for the same matrix. Moreover, function solve_continuous_are uses inv twice, even though it can (and should) use it zero times. Furthermore, SciPy functions do not support generalized matrix equations (with "E matrices").

Interestingly, solve_sylvester directly calls a LAPACK function, so my suggestion for SciPy would be to continue using FORTRAN codes and simply call SLICOT/Slycot functions.

As a side note, not only SciPy, but also python-control has dubious numerical codes, e.g. computing eigenvalues by finding roots of a characteristic polynomial, Bode plot computation speed up by converting state space form to transfer function form, and again using inv when it's not necessary.

From issue #77:

Only a few routines from SLICOT are used by python-control though (e.g., pole placement, Riccati solvers), so it wouldn't be too crazy to reimplement those in pure python or cython.

I already commented on Riccati solvers, but it is nice that pole placement was mentioned. This is probably the classic example of a numerically difficult problem arising in control theory. To illustrate this, there is a paper titled "Placing Plenty of Poles is Pretty Preposterous".

In short, ...

...using SLICOT and fixing known bugs is better than reinventing the wheel that will sacrifice both performance and numerical stability and accuracy.

[ilayn]

I actually wrote some SLICOT MIMO equivalents and there is no reinvention of the wheel. The code is much clearer and readable. And I can spot what went wrong almost instantly. With a language like Fortran 77 that is very very very difficult if you can have the code that is. As you mention, also SLICOT is not error-free so it has to give in for debugging at some point which currently does not. Besides, closed source is really a no go.

I actually follow very closely what Varga, Sima, Mehrmann and others publish (whom I respect greatly by the way) and it is not that dramatic at all. For control purposes if you need speed, say solving Riccati's for MPC and so on, even SLICOT is slow. You need to talk to your embedded system engineer and come up with a very very complicated FPGA implementation. Otherwise there is no major speed difference at all for regular synthesis purposes. Thus, for industrial speed (which I constantly seek) none of them is fast and for regular usage all are fast enough.

Finally, moving away from SLICOT is a must for any commercial setting which Matlab is already blocking currently. And it is unfortunate that SLICOT went that way with its license. Compare it with LAPACK license which is virtually everywhere .

If SLICOT doesn't give up on that license, I'm very afraid all those efforts from amazing numerical analysts will perish for others in the open source community and eventually people as happening here will look for alternatives.

In short, no it isn't better for many many individuals. I am actually coding Schmid, Nguyen, Pandey MIMO Pole placement right now and I truly appreciate the help from Amid and it basically surpasses MATLAB performance and accuracy. So openness always helps.

[pmli]

I actually wrote some SLICOT MIMO equivalents and there is no reinvention of the wheel. The code is much clearer and readable. And I can spot what went wrong almost instantly. With a language like Fortran 77 that is very very very difficult if you can have the code that is. As you mention, also SLICOT is not error-free so it has to give in for debugging at some point which currently does not. Besides, closed source is really a no go.

I believe you that your Python code is clearer and more readable, and that it is easier to debug. This is a general theme when comparing interpreted and compiled languages. That doesn't mean that people program in compiled languages just for the pain.

Debugging Fortran can be done, using a -g compilation flag and a debugger. And, the error I mentioned, was already debugged.

I actually follow very closely what Varga, Sima, Mehrmann and others publish (whom I respect greatly by the way) and it is not that dramatic at all. For control purposes if you need speed, say solving Riccati's for MPC and so on, even SLICOT is slow. You need to talk to your embedded system engineer and come up with a very very complicated FPGA implementation.

Embedded systems are special, with special temporal and spatial constraints. If SLICOT is too slow in this setting, I don't see how rewriting SLICOT to Python will help in any way, or are you proposing that python-control includes FPGA implementations? From the name "python-control", and seeing that there is a "matlab" folder, I'm guessing that the purpose of this project is to attract Matlab/Octave users and give them the functionality they would expect, only in Python (someone please correct me if I'm mistaken).

Otherwise there is no major speed difference at all for regular synthesis purposes. Thus, for industrial speed (which I constantly seek) none of them is fast and for regular usage all are fast enough.

I'm not sure that all are fast enough. I gave an example of scipy.linalg.solve_lyapunov that computes the Schur decomposition twice, so it will be at least two times slower than SLICOT.

Anyhow, what I'm more concerned with is numerical stability and accuracy. And, looking at the current state of SciPy and python-control, I'm worried that rewriting SLICOT would not be done properly. Using inv instead of, e.g. scipy.linalg.solve, might seem fast and accurate enough for small (state dimension of about 10) problems, but it's just extra computation which is not needed, and it costs time and accuracy. Computing eigenvalues with numpy.poly and numpy.roots, instead of scipy.linalg.eigvals, will not be accurate (especially when some eigenvalues are close) and will take more time or plainly won't work (already for problems of size a few hundred).

Finally, moving away from SLICOT is a must for any commercial setting which Matlab is already blocking currently.

I imagine, in a commercial setting, you would buy a commercial license of SLICOT.

And it is unfortunate that SLICOT went that way with its license.

It's unfortunate, but infrastructure, such as slicot.org, isn't free. Also, this way more research can be funded and developers can get paid.

Compare it with LAPACK license which is virtually everywhere .

Well, people who want high performance in linear algebra computations prefer to buy vendor's library license, e.g. Intel Math Kernel Library or AMD Core Math Library.

If SLICOT doesn't give up on that license, I'm very afraid all those efforts from amazing numerical analysts will perish for others in the open source community and eventually people as happening here will look for alternatives.

What would those alternatives be? SciPy? Other Python implementations? Main point I was trying to get across is that it will take great effort to replace SLICOT, even version 5.0, and that people with some knowledge of numerical linear algebra would need to be involved.

In short, no it isn't better for many many individuals. I am actually coding Schmid, Nguyen, Pandey MIMO Pole placement right now and I truly appreciate the help from Amid and it basically surpasses MATLAB performance and accuracy. So openness always helps.

My point with pole placement was to illustrate that it is difficult to implement proper numerical code. You saying that the author helped you supports this claim, kind of (it brings up the issue of code reproducibility).

If this project was called "python-pole-placement", I might agree to replace SLICOT (looking briefly at the paper you mentioned, it seems that the "span" method greatly sacrifices runtime, making it not very scalable, unlike SLICOT, which I guess is satisfactory in your case). But, as far as I'm aware, the goal of this project is to replicate Matlab/Octave control toolboxes, and I don't see enough reasons to forsake SLICOT 5.0 entirely.

[cwrowley]

@pmli, thanks very much for pointing out those places where we are doing things poorly. (Some of those are really embarrassing, such as calculating the poles!) I'm not sure I agree that in order to compute a frequency response, it's bad to convert to a transfer function--seems like this is more efficient, and I don't immediately see why this is bad numerically. But if there are reasons why this is bad, feel free to start a new issue about it.

[ilayn]

@pmli All you have mentioned were also valid when SLICOT started, look where it is now. The point is not accuracy or precision it is the inconvenience it is causing both in terms of installation/closed code and its incompatible license. It might take a great effort but I don't see any other way. Plus there are people who know numerical algebra in these projects too. It's a matter of initiative. Note that, these are still version 0 packages.

[pmli]

@cwrowley Thank you for your response. In fact, speeding up frequency response raises a few interesting issues. One is that, if system matrices are sparse, one can use sparse solvers, which are usually much faster than dense solvers. The issue is that StateSpace only allows dense matrices. Also the Matlab control toolbox forces dense matrix format, which I dislike (thankfully, sss toolbox addresses this).
About converting to transfer function for dense systems, simply said, I learned to be skeptic of any method involving polynomials of order higher than 3. To demonstrate that this skepticism is valid here, I will use the Niconet benchmark collection. For the Clamped beam model (n = 348), converting to a transfer function fails (most of the coefficients are nan). Converting the Building model (n = 48) to a transfer function will work, but what one finds is that coefficients vary greatly. The difference between the smallest and largest coefficient is more than 70 orders of magnitude. This signals some loss of accuracy during the conversion. Also, even though basic operations are involved in evaluating the polynomials, these huge differences in coefficients will cause losses in accuracy, especially when subtraction occurs. To my knowledge, the "standard" numerically stable method is transforming the state space such that A is a Hessenberg matrix (or, for generalized systems, A is upper Hessenberg and E upper triangular) and then solving linear systems with Hessenberg matrices. Computing the Hessenberg form is expensive (cubic complexity in n) and solving linear systems with Hessenberg matrices is cheep (quadratic in n). The form can be computed with scipy.linalg.hessenberg and solving linear systems can be done with SLICOT (SciPy doesn't have solve_hessenberg, and I didn't manage to find a corresponding function in LAPACK).

@ilayn The difference, to when SLICOT started, is that there was no SLICOT 5.0 around. I don't understand why the whole of SLICOT 5.0 needs to be ignored. Installation is easy if you are on Linux (openness helps, as you said). If you want, you can easily get a free academic license to use SLICOT 5.5 privately (as I suggested before).

[ilayn]

@pmli Don't get me wrong, if I could I would treat SLICOT just as I treat BLAS/LAPACK family as a basis for any control purposes. It is a magnificent library. I also wish I could use some solvers from NAG too.

But SLICOT has positioned itself as such with its license and has closed its source. So I can't do anything other than rolling up my sleeves. If the analogy would do any justice; it's like asking Octave, Scilab developers why they even bother since Matlab is around. Just look at data scientists: within 5 years or so Python is now "the" tool and they surpassed matlab and R which are again incredibly useful. But anyway I guess we shouldn't flood here with the discussion. If you would like to continue, I would be very happy if you can contact me via email or Gitter etc.

[pmli]

@ilayn I have trouble understanding why "rolling up sleeves" is the only option, with free SLICOT 5.0 or academic/commercial SLICOT 5.5, especially when you say it's "a magnificent library" and that it's almost certain that you lose efficiency or accuracy by reimplementing Fortran codes in Python.

Anyway, I will continue using SLICOT/Slycot (I have no plans of implementing, e.g. the BBBS algorithm for H_infinity norm computation), and it's up to the owners of python-control to decide where this project will go.

We might have flooded this thread, but I find it was necessary. I got a feeling that implementing numerical code was being taken very lightly here, and seeing some obvious numerical mistakes in python-control and scipy.linalg didn't particularly comfort me.

@ilayn I believe the big reason Python gained such popularity is its easy interfacing to libraries written in other languages (e.g. Fortran).

[ilayn]

@pmli Just because some people decided to move away does not mean that SLICOT is bad or it has to die. It is just unsuitable for massive use. Also 5.0 doesn't have the completely free license. I still think SLICOT is amazing and I still think it is very unfortunate that the license choice is as is. That should not make anybody sour. It is what it is. At this era, open source is the only way and I think you might have been underestimating people other than the SLICOT team. Once there is enough motivation, people do code properly and mistakes will be fixed. Remember that scikit-learn people deal with millions by millions matrices within Python! Our problems seem funny to them. So that's not fair to say open source dudes can't code.

PS: Incidentally I've implemented BBBS here and because it is MIT licensed nobody needs to sign up to something or bother if it is commercial use or anything else.

I would be grateful if you can also stress test it or can send me comments should you spot any mistake. And also there are two better methods than BBBS with which one of them I am busy with (see the docstring for the references)

[pmli]

What does "massive use" mean? Matlab uses SLICOT, so I guess that SLICOT is already massively used.
GPL license has its benefits. It mostly means (as far as I'm aware) that the original developer must be informed of the changes made, which can be good for the community if a company does some modifications.
In my opinion, size doesn't matter. It only matters if you know how to use them. (Also, dense and sparse matrices have different problems.) BTW, how big are your matrices?
Not using inv for solving linear systems is basically the first thing students learn in a numerical linear algebra lectures. I guess that's why I was being skeptic of open source dudes implementing numerical codes...

PS: Thank you very much for pointing me to your code! I didn't notice it before... I tested harold.system_norm with the same benchmarks I mentioned above (Clamped beam and Building models from the NICONET benchmark collection). For the Clamped beam model, the function fails, because you also convert state space to transfer function representation in the frequency response computation. For the Building model, the function does work. On my laptop, it takes 70.7 ms, while Slycot does it in 15.3 ms, so there is a difference. Notice that the Building model is small (n=48), so a much bigger difference can be expected for medium size models (n~1000).

[ilayn]

Ah yes, that conversion issue was also bothering me so I coded Misra, Patel, SIAM 1988 but somehow forgot completely to upload. Thanks a lot for reminding that. I should upload the better version. I also have some todos within the function as you can see so I should do some speedup tricks to fix the "~five times slowness" . Melina's method is faster than BBBS but haven't manage to make it robust enough yet.

Now I have also seen that I don't handle the discrete time case properly either. Great that you have caught it.

By "massive use" I meant individual and commercial uses but not the embeddings. One particular annoyance with matlab usage is that even if you would like to embed 10kB of compiled .m code anywhere you have to carry around 300+MB of runtime library overhead for compatibility etc. That's the whole reason I've started using Python actually.

[pmli]

Melina's method is faster, but it is in the end only a locally convergent method, i.e. it will find a peak, but there is no guarantee that it will find the biggest one. As far as I understand, the goal of Melina and her collaborators was to develop a method for large and sparse systems. I believe you need good arguments for replacing BBBS with a locally convergent method when working with dense systems.

This is also a good reason for using SLICOT/Slycot. Yes, some methods there can seem outdated (some might really be outdated), but before deprecating them, newer implementations should be rigorously tested and compared to SLICOT implementations. SLICOT above all, even speed and memory performance, strives for robustness and numerical stability and accuracy (see point 4 here). If your implementation is more robust, stable, and accurate, then great! If it is also similarly fast (for dense matrices barely fitting in RAM, currently between order 10^3 or 10^4), then amazing! Otherwise, I think there will be people who would rather use SLICOT implementations.

[repagh]

On the topic of building slycot; for my students I created an installer for Windows, with slycot, PyDSTool and python-control, installs on top op python(x,y).
For the latest version (Python(x,y) 2.7.10) I am using OpenBLAS and MinGW for compilation of slycot. As far as I can tell, all slycot functionality works.

Here is the binary, this folder also contains the InnoSetup files to create the installers (with comments on the building process)
packages
And here are instructions for the students; also including detailed install instructions for Mac OSX, which I based on a macports python install
install instructions

[ilayn]

@pmli In case you are still interested, I've fixed the MIMO freqresp for state representations and clamped model now works. The value is computed as 4548.658313697244 as opposed to matlab's 4554.83550695767. Also norm computation takes ~3.74s as opposed to matlab taking ~4.45s on 2011b. Thanks for drawing attention.

[beachdweller]

If you are interested, here is a piece of code I could used to check python-control and slycot source files.

https://gist.github.com/201446b77e45e4ea569762752f449675.git

Hope this helps & I would welcome any comments and/or suggestions

[beachdweller]

• Additionally I am personally working on python scripts analyzing fortran source code files with limited intention to generate a python source code (hopefully Cython compatible). (the script above was a part of them before)
• As someone suggested, I could find f2c repository claiming that it is mirroring the netlib. However, at this point, it might be a little early to state the direction I want to proceed.