Start to handle matplotlib.pyplot for graphs

[rocky]

What's needed to start handling matplotlib graphics.

I imagine this will be useful in iwolfram too.

[mmatera]

Indeed, this is more or less the way I am using in Iwolfram to produce graphics from mathics. However, I think that if we want to really handle properly text inside graphics, we should use the asymptote output or, (but this would take much more effort) to rewrite all the graphics interface to use the low-level matplotlib engine. I plan to face that once we have better support for control keywords and list handling.

[mmatera]

On the other hand, as a first shot, I think that it is OK to merge it as it is by now.

[mmatera]

Apart from my previous comment, this looks quite nice.

[rocky]

Indeed, this is more or less the way I am using in Iwolfram to produce graphics from mathics.

I don't understaand. Without the recent change to Mathics to leave the result unformatted, how can you do this?
When we looked at various graphs they were inline SVG's.

Maybe if you can point me to specific places in IWolfram this will get across the idea more clearly.

However, I think that if we want to really handle properly text inside graphics, we should use the asymptote output or, (but this would take much more effort) to rewrite all the graphics interface to use the low-level matplotlib engine. I plan to face that once we have better support for control keywords and list handling.

Right now, I'm looking at and dealing with a more limited problem: graphs. And there, I am using networkx's interface (largely) into matplotlib.

As we've noted in the past, and not at least for me, it has become very clear that was a big mistake to try undertake drawing reinventing things yet another time. Yes, there was an advantage that Mathics didn't need to rely on networkx, or matpotlib, but the disadvantage is a lot of complexity, no one working on this code, and worse overall results, except in very limited cases: networkx doesn't seem to handle "mixed" graphs. A graph in networkx is either directed or undirected.

If you want a mixed graph, and I doubt it is that important, I supposed you would work with an undirected (multig)raph and add some sort of directed property on the edges. But mixed graphs aren't that important.

In compensation you get tons of other stuff. For example look at all of the graph generators networkx comes with. And each of these is pretty easily added. I have't gotten there, but I believe the same is true with graph properties (node and edge labels and styles) and graph layout properties. That's probably what I'll look at next.

In sum, Mathics wasn't letting networkx or mathplot lib the work (and in truth maybe 4 years ago there was less available). But Mathics should just focus on translating one style of parameter handling to the other, and live with the fact that networkx and maatplotlib are a required dependencies. If you can't handle networkx and matplolib, fine, just don't load the graph package.

Something similar will happen in mathicsscript: plan to let sympy handle text rendering of things like integrals and superscript if that is desired. Thanks to @mmatera I now have session setting handling in mathicsscript under control.

As I've said before, I believe all of the mechanisms will be useful in interfacing with Jupyter. Right now with all of the overwhelming complexity (even after simplifying how to handle graph functions, and graphics), there is still a bit to get under control. Adding a Jupyter wire protocol and a client/server protocol right now just adds more complexity while we don't have a number of the basics under control.

[mmatera]

Indeed, this is more or less the way I am using in Iwolfram to produce graphics from mathics.

I don't understaand. Without the recent change to Mathics to leave the result unformatted, how can you do this?
When we looked at various graphs they were inline SVG's.
The thing is I use IOHooks to convert every output to a b64 encoded string, in a way that formating is more or less trivial.

Maybe if you can point me to specific places in IWolfram this will get across the idea more clearly.

For IWolfram, I use Metakernel to control a mathics / WolframScript terminal session. Metakernel handles much of the wiring if all the output from the terminal is just a ASCII string. Then, with WL each line is interpreted, evaluated, and formatted, and finally codified as a b64 string. Graphics are processed by exporting the native graphic to a SVG / PNG string representation, and then translated to b64.

One day that we have more time I can explain a little bit better

However, I think that if we want to really handle properly text inside graphics, we should use the asymptote output or, (but this would take much more effort) to rewrite all the graphics interface to use the low-level matplotlib engine. I plan to face that once we have better support for control keywords and list handling.

Right now, I'm looking at and dealing with a more limited problem: graphs. And there, I am using networkx's interface (largely) into matplotlib.

As we've noted in the past, and not at least for me, it has become very clear that was a big mistake to try undertake drawing reinventing things yet another time. Yes, there was an advantage that Mathics didn't need to rely on networkx, or matpotlib, but the disadvantage is a lot of complexity, no one working on this code, and worse overall results, except in very limited cases: networkx doesn't seem to handle "mixed" graphs. A graph in networkx is either directed or undirected.

If you want a mixed graph, and I doubt it is that important, I supposed you would work with an undirected (multig)raph and add some sort of directed property on the edges. But mixed graphs aren't that important.

In compensation you get tons of other stuff. For example look at all of the graph generators networkx comes with. And each of these is pretty easily added. I have't gotten there, but I believe the same is true with graph properties (node and edge labels and styles) and graph layout properties. That's probably what I'll look at next.

In sum, Mathics wasn't letting networkx or mathplot lib the work (and in truth maybe 4 years ago there was less available). But Mathics should just focus on translating one style of parameter handling to the other, and live with the fact that networkx and maatplotlib are a required dependencies. If you can't handle networkx and matplolib, fine, just don't load the graph package.

Something similar will happen in mathicsscript: plan to let sympy handle text rendering of things like integrals and superscript if that is desired. Thanks to @mmatera I now have session setting handling in mathicsscript under control.

As I've said before, I believe all of the mechanisms will be useful in interfacing with Jupyter. Right now with all of the overwhelming complexity (even after simplifying how to handle graph functions, and graphics), there is still a bit to get under control. Adding a Jupyter wire protocol and a client/server protocol right now just adds more complexity while we don't have a number of the basics under control.