[ENH]: callable arguments to the high level plot functions #20926
Comments
|
Specifically in the case of defining a grid for plt.plot(x:=np.linspace(xmin, xmax), f(x))*Should clarify: you could user keyword arguments to rearrange things so that whatever variable you're defining the grid on comes first: plt.scatter(y=(y:=np.linspace(xmin, xmax)), x=f(y))But |
|
Great idea! This should indeed cover most of the relevant use cases. |
|
We have had at least 2 attempts to add If this is something you do all the time, I suggest putting something like def my_cleverly_named_plotting_of_functions_function(x, f, *, ax=None, **kwargs):
if ax is None:
import matplotlib.pyplot as plt
ax = plt.gca()
return ax.plot(x, f(x), **kwargs)in a local library. For plotting to feel "fluid" it the API needs to be closely tuned to your needs and data, which means the API needs to be opinionated and bake a lot of assumptions in. While there are some cases (like seaborn) where this can be done across a pretty big domain, I think all users should embrace writing mini-libraries exactly tuned to their needs (exactly like we all do with analysis)! It might also be worth looking at sympy which has a plotting layer that understands sympy objects and "does the right thing" in many cases. Enabling this sort of thing more generally is one of the goals of @story645 's thesis work. By pulling all of the data management into a dedicated class (rather than stored ad-hoc on the Arstist as now), we will be able to at draw-time query that object with the current view limits (in data space) and axes size (in screen space) to get the relevant data. This will enable things like smart (re-)sampling of the underlying data to be injected into all Matplotlib artists (rather than having to live in the Artist implementation). |
|
I was thinking that with AI and modern algorithms could possible made an advancement in like age progression photography.--Sent from my Android phone with mail.com Mail. Please excuse my brevity.On 8/28/21, 12:50 PM Thomas A Caswell ***@***.***> wrote:
We have had at least 2 attempts to add fplot (#1143 and #737) but if I recall correctly they got bogged down in the numerics / theory of how to smartly sample around shape peaks.
If this is something you do all the time, I suggest putting something like
def my_cleverly_named_plotting_of_functions_function(x, f, *, ax=None, **kwargs):
if ax is None:
import matplotlib.pyplot as plt
ax = plt.gca()
return ax.plot(x, f(x), **kwargs)
in a local library.
For plotting to feel "fluid" it the API needs to be closely tuned to your needs and data, which means the API needs to be opinionated and bake a lot of assumptions in. While there are some cases (like seaborn) where this can be done across a pretty big domain, I think all users should embrace writing mini-libraries exactly tuned to their needs (exactly like we all do with analysis)!
It might also be worth looking at sympy which has a plotting layer that understands sympy objects and "does the right thing" in many cases.
Enabling this sort of thing more generally is one of the goals of @story645 's thesis work. By pulling all of the data management into a dedicated class (rather than stored ad-hoc on the Arstist as now), we will be able to at draw-time query that object with the current view limits (in data space) and axes size (in screen space) to get the relevant data. This will enable things like smart (re-)sampling of the underlying data to be injected into all Matplotlib artists (rather than having to live in the Artist implementation).
—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe.
|
Problem
I often find myself using an equivalent of this code:
This is unnecessarily verbose, and if written in one line has redundancy:
Proposed solution
It would be convenient if
.plotand similar high level plotting routines identified callable arguments and if possible evaluated those with array arguments. I imagine the amount of meaningful combinations would be limited.Additional context and prior art
Providing functions as input to plotting routines and letting those take care of the evaluation is a common pattern.
The text was updated successfully, but these errors were encountered: