Matlab is a real pain: switch to Python?

[jeanluct]

The Matlab version with MEX files is a real pain in the ass to distribute. Mathworks has not been very helpful with some of our problems.

So should we consider rewriting the whole thing in Python? (or Julia?)

How much work would that be? Just opening an issue to ponder this.

Pros:

• easier to distribute (no compiler version headaches, hopefully?);
• presumably nicer interface to C, C++ (though I don't have much experience);
• nicer OOP environment; (Matlab's is fairly primitive)
• class structure could probably be ported almost as is.

Cons:

• more experienced with Matlab;
• it's a lot of work;
• I'm still annoyed at this Python 2.7 vs 3 controversy;
• some Matlab functionality might be difficult to duplicate.

Would we need to modify the C++ code a lot? It's written with MEX in mind currently, but most of it would stand on its own as is.

For reference, I think we have about 1300 lines of C/C++, which could remain more or less as is. However, there are about 6600 lines of Matlab (though a lot of this is usage and comments).

Maybe as a test try to rewrite a minimal braid class in python, see how I feel about it.

[jeanluct]

From Jean-Luc Thiffeault on 2014-09-30 18:59:42+00:00

Here's a couple more questions:

• Would the non-C++ code be slower? Matlab vectorizes well. But I suppose very little of the code depends on heavy vectorization.
• Would this increase or shrink the userbase? More people use Python (and it's free), but Matlab is popular for data analysis.
• Is it completely out of the question to support both? Sounds a bit nuts.

[jeanluct]

From Marko Budisic on 2014-09-30 19:53:01+00:00

I would say that until this becomes a noticeable issue, i.e., until people start complaining that they cannot use braidlab on their machines, even though they would, it should not be a high priority thing.

Python will likely not work perfectly either and neither will julia. Although I'm all-for breaking away from corporate software (and I like Python plenty), I think the cost/payoff in this case is prohibitive.

As far as people in our community go: I'd guess that Matlab is a more popular tool than Python (LCS, GAIO all have Matlab interfaces, not Python).

I do think it would be nice if we could release some fast portions of the code as independent libraries, e.g., colorbraiding algorithm, so people can plug them into their own code if they want to go beyond what braidlab offers. (Or at least, include them in such a way that this is easy-ish to do)

[jeanluct]

From Jean-Luc Thiffeault on 2014-09-30 20:06:47+00:00

Well, there are some complaints already... Also many people might not even mention it and not even try it.

About releasing as a library: that's a possibility, as an intermediate step. I do have a C++ braid implementation and we could use that as a starting point.

[jeanluct]

From Marko Budisic on 2014-10-03 14:36:05+00:00

Perhaps this is not the exactly right thread for this, but since we're talking distribution woes, here's the latest post from MATLAB central file of the week.. It's about distributing toolboxes. I haven't gone through it in details, but it does mention some resources that might be worth while considering.

[jeanluct]

From Jean-Luc Thiffeault on 2014-10-11 14:24:55+00:00

Wow, the subscript overloading required to address #71 was so awful. I'm not sure it won't turn out to be a maintenance nightmare, with little bugs creeping up forever. Add that to the reasons to maybe eventually move away from Matlab.

[jeanluct]

Perhaps Marko should add his thought on dealing with exceptions in Matlab! But anyways, closing this discussion for now, to be reopened in the distant future, or added to as needed.