Re: How to combine Mathematica graphics and Python code?

*To*: mathgroup at smc.vnet.net*Subject*: [mg113376] Re: How to combine Mathematica graphics and Python code?*From*: Zach Bjornson <bjornson at stanford.edu>*Date*: Tue, 26 Oct 2010 05:33:18 -0400 (EDT)*References*: <ia3mu5$rp2$1@smc.vnet.net>

Hi, I think the prettiest thing (though still not "easy" per se) would be to use MathLink to call Mathematica's plotting functions from Python. There's an extensive MathLink developer's guide in the documentation. (No, I take that back. The prettiest thing would be to get your colleagues to switch from Python to Mathematica.) A step down from MathLink in Py would be to use Python's system commands (equivalents to Run and RunThrough in Mathematica) to interact with math (the kernel, not Mathematica the front-end). This is probably the easiest thing you could do. You could either require Mathematica code to be fed to the kernel, or write a translation function to go from Py to M as it suits you. Depends if the things you'll be plotting are all similar or if each graph will require tailoring; for the former a translator would be less practical. In py it would probably go something like: def mathematicaplot (data, options): # export your data using e.g. csvwriter and tempfile.tempdir as the location os.popen('math -noprompt Export["(*some temp file*).PDF", Plot[ Import[(*wherever you exported your data above*)], options]') os.popen('(*your temp file*).PDF') return A step-up would be to make your own front end or IDE that controls both Python and Mathematica. Again MathLink can be used for this; I doubt there's an equivalent for Python, but the source code is available so you can do whatever you want. You could also entirely build Python into Mathematica (again refer to the external connectivity documentation from Wolfram). I think this would take a while... :) Trafficking symbols/variables/objects between the two kernels (which will be in a non-shared memory space) is going to be a trick. The ideas above using MathLink will handle this, but using unmanaged communication (2nd option) means exchanging data via stdin or files, as done in the mini example. Unfortunately there's no native specification shared by the two languages (like Mathematica has .mx). Hope that helps, Zach On 10/25/2010 3:42 AM, kj wrote: > I have been given the task of developing a data visualization system > for a large academic experimental biology lab. In this lab they > generate a lot of specialized high-throughput data, and they need > a custom system for organizing, analyzing, and visualizing it. > (Many such systems already exist, of course, but for a wide variety > of reasons the lab's directors decided to go with a custom, home-grown > alternative.) > > I have decided to develop the system primarily in Python, for a > couple of reasons.[1] The big downside of Python, however, is that > it does not have, in my opinion, a sufficiently good support for > scientific graphics.[2] > > In my experience Mathematica is the gold standard for scientific > graphics, and wondered if there was some way in which I could > combine Python code with Mathematica graphics. > > The absolute ideal system would be something that looked likei a > (highly stripped down) Mathematica GUI, but receiving Python code > instead of Mathematica code. I.e. basically a cross between the > standard Python interactive text-based interpreter and a Mathematica > graphics-enabled GUI. > > A less attractive possibility (but still adequate) would be for > the Python system to generate the necessary Mathematica code on > the fly, and somehow get Mathematica to generate and display a > figure for it. > > A third alternative would be to build a Python interpreter that > could be run within Mathematica, but this is pushing beyond my > level of expertise, both with Python and with Mathematica. > > At this stage I'm interested in finding out of similar attempts to > use Mathematica's graphics capabilities in a non-Mathematica app, > and perhaps learn from their experience. > > Technical issues aside, there are also thorny licensing issues. > If anyone has any experience with that, I would love to read your > comments. > > TIA! > > ~kj > > > [1] The choice of Python is motivated by two reasons: 1) the lab > already has a significant code base in Python that I can re-use > for this project; and 2) I expect that in certain special cases > not covered by the system's base functionality, its users (most of > whom have no programming experience at all) may need to write very > simple scripts, and I find Python is particularly easy to teach to > people with no programming background. > > [2] The best Python for scientific graphics is matplotlib, which > is loosely based on another system. matplotlib is adequate for relatively > simple graphics tasks, but it is not flexible enough for the type > of visualization that I think will be needed. (I think this > inflexibility is the result of some pretty fundamental design flaws > in matplotlib.) >