[Matplotlib-devel] Suggestion: accept callables as non-xs values arguments

[Andy Buckley]

On 17/09/15 22:46, Thomas Caswell wrote:
> Andy,
>
> This is exactly the right place to post things like this.

Phew :-)

> Fernando Perez has proposed something similar to me in person.  As part
> of the label data un-packing discussion there was talk of allowing users
> to write expressions in (ex plot('x', 'sqrt(x)', data=df) would plot a
> square root function) which is sort of related to this.

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!

> What follows is a rather rambling brain dump of me thinking about this ;)
>
> Do you want the functions to be evaluated at Artist creation time or
> Artist draw time?
>
> If it is at creation time, see
> https://github.com/matplotlib/matplotlib/pull/4829 for how we
> implemented something similar for unpacking labeled data.  That might be
> a reasonable template for how to do this.  Would tooling to easily bind
> plotting functions to the computation be good enough?  For controlling
> any additional args/kwargs to the mapping function we can just use `partial`
>
> If it is at _draw_ time, I am a bit more skeptical. But if you can
> change the x data, the rest of the data _should_ recompute so that would
> probably be a better way to do it long term, but will require much more
> invasive changes to the library.

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.

> We already have a fair number of mapping functions internally (ex, the
> whole transform stack and the data -> norm -> cmap chain), I wonder if
> there is a way to generalize any of that?

Beyond my mpl expertise, I'm afraid!

> I am also a bit concerned that this will balloon quickly, for example,
> for people plotting histograms, they may want the yerr to be a function
> of the y-value (ex Poisson error), not the x-value.  The complexity
> required to express everything that would need to be done once we start
> to go down this road is a bit daunting.

Yes, this occurred to me, too.

Maybe it's not ambitious enough, but I would be very happy with just 
parameterising everything on x.

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.

I would hold off generalising beyond that -- YAGNI!

Thanks for the quick & positive reply :-)

Andy


> I have been thinking for a while (like a year) about a massive API
> re-working (which I owe the list a long write up on!), I have heard you
> and will think about how to integrate this.
>
> One other concern is that our top-level API is _too_ magical rather than
> not magical enough.
>
> Tom
>
> On Thu, Sep 17, 2015 at 4:39 PM Andy Buckley <andy.buckley at cern.ch
> <mailto:andy.buckley at cern.ch>> wrote:
>
>     Hi,
>
>     Not sure if this is the best place to post this, but I have an API
>     suggestion: as well as iterables, mpl plotting functions could accept
>     callable objects to generate y values, errors, etc..
>
>     Specifically, I'm thinking that the list of x values would always need
>     to be specified as an iterable like now, but that the other arguments
>     which currently require an iterable of the same length as the xs could
>     alternatively accept callables that are mapped on to the xs list. The
>     presence of __iter__ or __call__ attributes could be used to determine
>     which approach to use.
>
>     I searched a bit and couldn't find any previous mention of this idea,
>     and there are callable arguments already used in matplotlib. Thoughts?
>     I'd be happy to help with implementation if there is any interest.
>
>     Best wishes,
>     Andy
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>
>     https://mail.python.org/mailman/listinfo/matplotlib-devel
>


-- 
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow