<div dir="ltr">I think sympy has plotting functions that basically work this way, right? (Though they might only work with sympy function and variable objects, and not generic callables and arrays). Might be worth looking into what they have done, as they've probably wrestled with some of these API problems along the way.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 18, 2015 at 9:01 AM, Andy Buckley <span dir="ltr"><<a href="mailto:andy.buckley@cern.ch" target="_blank">andy.buckley@cern.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 17/09/15 22:46, Thomas Caswell wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Andy,<br>
<br>
This is exactly the right place to post things like this.<br>
</blockquote>
<br></span>
Phew :-)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Fernando Perez has proposed something similar to me in person. As part<br>
of the label data un-packing discussion there was talk of allowing users<br>
to write expressions in (ex plot('x', 'sqrt(x)', data=df) would plot a<br>
square root function) which is sort of related to this.<br>
</blockquote>
<br></span>
That looks like all sorts of more dangerous to me -- it would presumably involve an exec() or equivalent, with security implications. But sure, str funcdef args could be added on top of callables, by the users if not mpl itself!<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What follows is a rather rambling brain dump of me thinking about this ;)<br>
<br>
Do you want the functions to be evaluated at Artist creation time or<br>
Artist draw time?<br>
<br>
If it is at creation time, see<br>
<a href="https://github.com/matplotlib/matplotlib/pull/4829" rel="noreferrer" target="_blank">https://github.com/matplotlib/matplotlib/pull/4829</a> for how we<br>
implemented something similar for unpacking labeled data. That might be<br>
a reasonable template for how to do this. Would tooling to easily bind<br>
plotting functions to the computation be good enough? For controlling<br>
any additional args/kwargs to the mapping function we can just use `partial`<br>
<br>
If it is at _draw_ time, I am a bit more skeptical. But if you can<br>
change the x data, the rest of the data _should_ recompute so that would<br>
probably be a better way to do it long term, but will require much more<br>
invasive changes to the library.<br>
</blockquote>
<br></span>
Heh, I hadn't really been thinking in that sort of detail. I don't really use mpl interactively, and would I *expect* values to update dynamically? Not based on the current behaviour at least, which by construction always requires an explicit recalculation. But I'd defer to interactive users whether (re)draw-time calculation would add enough to be worth the extra trouble. If it's much easier, I guess creation time is the place to start.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We already have a fair number of mapping functions internally (ex, the<br>
whole transform stack and the data -> norm -> cmap chain), I wonder if<br>
there is a way to generalize any of that?<br>
</blockquote>
<br></span>
Beyond my mpl expertise, I'm afraid!<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am also a bit concerned that this will balloon quickly, for example,<br>
for people plotting histograms, they may want the yerr to be a function<br>
of the y-value (ex Poisson error), not the x-value. The complexity<br>
required to express everything that would need to be done once we start<br>
to go down this road is a bit daunting.<br>
</blockquote>
<br></span>
Yes, this occurred to me, too.<br>
<br>
Maybe it's not ambitious enough, but I would be very happy with just parameterising everything on x.<br>
<br>
But, thinking aloud, a more advanced possibility would be that a ys=callable arg would operate on just x values, an xs=callable arg would operate on just ys, and any other callables would operate on a 2-arg pair (x,y). Obviously only one of xs and ys would be able to be callable.<br>
<br>
I would hold off generalising beyond that -- YAGNI!<br>
<br>
Thanks for the quick & positive reply :-)<br>
<br>
Andy<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
I have been thinking for a while (like a year) about a massive API<br>
re-working (which I owe the list a long write up on!), I have heard you<br>
and will think about how to integrate this.<br>
<br>
One other concern is that our top-level API is _too_ magical rather than<br>
not magical enough.<br>
<br>
Tom<br>
<br>
On Thu, Sep 17, 2015 at 4:39 PM Andy Buckley <<a href="mailto:andy.buckley@cern.ch" target="_blank">andy.buckley@cern.ch</a><br></span><span class="">
<mailto:<a href="mailto:andy.buckley@cern.ch" target="_blank">andy.buckley@cern.ch</a>>> wrote:<br>
<br>
Hi,<br>
<br>
Not sure if this is the best place to post this, but I have an API<br>
suggestion: as well as iterables, mpl plotting functions could accept<br>
callable objects to generate y values, errors, etc..<br>
<br>
Specifically, I'm thinking that the list of x values would always need<br>
to be specified as an iterable like now, but that the other arguments<br>
which currently require an iterable of the same length as the xs could<br>
alternatively accept callables that are mapped on to the xs list. The<br>
presence of __iter__ or __call__ attributes could be used to determine<br>
which approach to use.<br>
<br>
I searched a bit and couldn't find any previous mention of this idea,<br>
and there are callable arguments already used in matplotlib. Thoughts?<br>
I'd be happy to help with implementation if there is any interest.<br>
<br>
Best wishes,<br>
Andy<br>
_______________________________________________<br>
Matplotlib-devel mailing list<br></span>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a> <mailto:<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a>><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
<br><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow<br>
Particle Physics Expt Group, University of Glasgow</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
</div></div></blockquote></div><br></div>