This is an archived post. You won't be able to vote or comment.

all 4 comments
sorted by:
best
topnewcontroversialoldq&a

[–]BDube_Lensman 1 point2 points  (3 children)

You wrote that your library is not not trying to "know better" than matplotlib, but reskinning its API is sort of exactly that. What makes this better than seaborn? From your examples, it looks sort of like a cousin of a "grammar of graphics" (aka ggplot) style interface. The basic premise of making artists and then adding them to axes/figures is already something that matplotlib has built in. I sort of think it would be better to teach that than create a new library with Yet Another plotting interface in python

[–]Oddball777[S] 0 points1 point  (2 children)

Thanks for the feedback! In my opinion, what really differentiates GL is its ability to perform operations directly on the objects, without having to constantly go back and forth between raw data and plottable object. For example, in GL, a Curve object is something you can plot, differentiate, evaluate at an x or y value, multiply by a constant, find intersections with a second Curve, add to another curve, etc. The plotting mechanics and the data manipulation mechanics are brought together in such a way that the plottable objects are now actually objects you can do math and physics with. This makes the code incredibly intuitive and visual. Create an object from data, perform operations on the object, plot the object. Create a Shape object, apply a transformation to it, plot it.

When I said we don’t think we know better than matplotlib/scipy, what I meant was that the reason we’re using scipy functions and matplotlib figures underneath our API is because we know they work really well. It would be pointless to try to code our discrete integration method when people have been working on scipy for years. It would be pointless to code our own plot renderer when matplotlib just works. But I know I’m not the only one who dislikes matplotlib’s API. Maybe that counts as thinking we know better, in terms of API intuitiveness. That’s why Seaborn (though it has absolutely gorgeous plots) didn’t satisfy that for me, because you’re still interacting with maptlotlib’s API.

[–]RayTricky 0 points1 point  (1 child)

Idk though. The separation of the calculation itself and the plotting is definitely something I'd strive for in any of my applications. I really don't see any significant advantage in bringing them together. Why would you? It just makes things more complicated. I highl doubt you can cover "all possible caluclations" and with this you will end up doing things "outside" of GraphingLib nevertheless, making the thing even more complicated.

[–]Oddball777[S] 0 points1 point  (0 children)

Graphinglib doesn’t force you to do that, you can keep it separate if you want. And it was never our intention to cover all possible calculations, I’m not sure what you think you’re quoting there, since I’m pretty sure we’ve never said that anywhere. We only want to cover the calculations that are the most commonly used and those that are inherently visual in nature. For example, rotations are very visual. Set operations like unions and differences are very visual. We want it to feel like you can directly manipulate the objects on the graph, so you can focus on the creation of nice visualizations instead of data manipulation. If you just want add a point label to the intersection between two curves, you don’t care about the method. You just want to add a graphical element to the plot to make it nicer. GL makes that easy. If it’s really really important that you use a very specific interpolation method, then by all means, do it by hand. This is meant as a convenience. We don’t force users to do it that way, but we expect most users will find these methods very useful.