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.)
>