This looks slightly more lengthy than this one; I wonder if I was missing something (other than infinite slopes).

This PR draws a line with "infinite" length, similarly to axvline and axhline: even if you manually (or programatically) zoom out, the line will still go from one edge of the axes to another, rather than being limited to the original view limits.

Sure, I understand that. And I compared it to a previous solution to this, which does not calculate as much stuff as this one, and now I am wondering why yours is so much longer. One obvious thing is that this one here takes two points instead of a slope and hence allows infinite slopes - is this what makes it complicated?

Oh, sorry, I saw the accepted solution in the SO thread which just uses xlim/ylim.
Regarding your solution it looks like it suffers from similar problems as #9321, namely

• if the infinite line is the only thing drawn, axes limits still go from 0 to 1 in each direction (which may not even show any of the plotted line), but if you add some other artist to the plot (e.g. ax.plot([5, 6], [7, 8]) -- remove the scatter() in your example) then the autolimits encompass both the additional artist and the x=0-1, y=whatever range; in other words x=0-1 is "leaking" into the other artists limits.
• afaict it does not work for log-log scales.

Fixing these is what makes this solution so complex (plus a dozen of lines for handling the fully vertical/horizontal case in a manner that makes it possible to update xy1/xy2 a posteriori on the artist).

discussed during the call:

• docs could mention that this also works in log space.
• replace "straight line" in docstring?
• include in hline/vline tutorial?

Looks good.

Improved docs a bit and added example. Admittedly an example showcasing e.g. a power-law in log-log scale would be nice, but that's a bigger endeavour.

Anybody can merge after CI pass.

🎉 at last, many thanks to everyone who has worked on this over the years(!)

I guess it might by too late ... but in many cases a (slope, intercept) parameterization would be more convenient than (xy1, xy2). Is there any appetite for expanding this function to include that? Or building on this work with a separate axabline (taking the nomenclature from R) that offers that parameterization?

Slope / intercept is degenerate for vertical lines, so if forced to pick one this is the right one. Origin / direction would somewhat address my comment above, but isn't very different.

There was a discussion on xy1, xy2 vs. intercept, slope, but I cannot find the related issue. AFAIR the arguments were:

• We don't want to support both signatures in one function. This would be quite messy.
• We don't want two separate functions, one with each signature.

So it should only be one of the two. Additionally,

• If you know slope and intercept, getting two points is easy

  p1 = 0, intercept
  p2 = 1, interept + slope
  

• If you have two points, calculating slope and intercept is more tedious

  slope = (p1[1] - p2[1]) / (p1[1] - p2[1])
  intercept = p1[1] - slope * p1[0]
  

Additionally, vertical lines (infinite slope) would need special handling.

Are axhline and axvline being deprecated? (Please say no...)

No. They stay. Horizontal and vertical lines are relevant enough that they can be dedicated methods. Also, deprecation would break a lot of existing code, which would not be justifiable.

OK. I don't really understand the motivation for the decision, but it's your library...

@mwaskom, I agreed with you during the original discussion.

The typical use case for me is that I'd know the slope and intercept (usually from something theoretical, a paper, or if I ran polyfit) and want to plot the line. No one cites in their paper two points, they cite the slope and the intercept. polyfit doesn't return two points, it returns the slope and the intercept.

So, with this implementation, what I'd bet are 98% of the use cases make folks do a bit of math to come up with the two points, with the only gain being that they can use this function instead of axvline(x0) for the infinite slope case. As for the tedious math going the other way, 98% of the time you want to quote the result of that tedious math in your final results, and you would do so a slope, intercept.

For me there are two issues with slope/intercept: they don't work for vertical lines, and more importantly they only work (effectively) for linear scales, whereas I explicitly wanted to be able to draw exponential decays in semilog scale and power laws in loglog scale.

But again, those are rarely described by the user as two points.

Agreed, but I don't know of a better parametrization which actually works in all three cases.

I see the logic of favoring a slightly more general function that is less convenient for the large majority of use cases, even though it is the kind of API decision that makes people think matplotlib is annoying to use. But I don't really understand the hard constraint on adding two functions. There's already going to be axline, axhline and axvline. How much marginal confusion is added by a fourth option, axabline?

Another suggestion: I agree that having both parameterizations in one function is confusing. But the signature to axline could be

axline(xy1, xy2=None, slope=None, ...)

Such that when you have slope m and intercept b, you only need write

axline((0, b), slope=m)

Perhaps it's annoying enough to feel like matplotlib, but useful enough to make most people happy.

I am personally not strongly opposed to axabline() (however you want to call it), I guess just -0, someone just needs to write it (and hopefully check that it behaves sensibly (possibly erroring out) in log scale). Shoehorning this into axline() looks not so nice, though.

I'm actually considering if a generalization of axline() would be the way to go.

Small extension

def axline(xy1, xy2=None, *, slope=None, **kwargs)
    """
    Add an infinitely long straight line. 

    The line can either be defined by one point and a slope or by two points.
    """
    xy1, xy2 = _to_points(xy1, xy2, slope)

With the private _to_points() doing all the checking and calculation. This has the advantage, that you can easily draw a tangent, which is a line with a known slope going through a given point.

Valid usages:

axline(xy1, xy2)
axline(xy, slope=2)

For the slope, intercept case, this simplifies at least to axhline((0, intercept), slope=slope).

Theoretically, one could go as far as also supporting intercept directly as an additional kw-only arg.

Larger extension

def axline(xy1=None, xy2=None, *, slope=None, intercept=None, **kwargs)
    """
    Add an infinitely long straight line. 

    The line can either be defined by
   
    - two points
    - one point and a slope
    - a slope and an intercept
    """
    xy1, xy2 = _to_points(xy1, xy2, slope, intercept)
    ...

Valid usages:

axline(xy1, xy2)
axline(xy, slope=2)
axline(intercept=3, slope=2)

I'd tend to go with the first one, which seems a straight forward generalization (extending to the second one is always possible later). But I also wouldn't be be opposed going all the way to the second. The API is a bit overloaded, but as discussions show, there are multiple valid opinions/usecases.

Your post is going back and forth between axhline and axline in a confusing way. Which function are you proposing to generalize? I think axline would be the more obvious function to overload, both because it has the more general name and because it's new. Adding functionality to axhline would be less discoverable.

Edit: Sorry for the confusion. It should all be axline - fixed above. Tim

@timhoffm I think your "Small extension" is the way to go. The "Larger extension" has no advantages from the ease-of-use and readability standpoint, and is more complicated. @mwaskom, all this relates to axline; I'm sure the axhline references are just typos.

I like that approach. But I think we'd need to think about what slope and intercept mean in the loglog and semilog cases. ie if the scales are loglog, slope/intercept could/should mean intercept * x^slope. In general, I'm not sure (i.e. logit scales?, etc etc).

Even when specifying two points, the meaning of a "straight line" is unclear and it's usefulness in the current implementation is questionable: The line does not represent a simple relation between the x and y data coordinates anymore.

import matplotlib.pyplot as plt
import numpy as np
x = np.linspace(1, 1000, 21)

plt.semilogx(x, x, 'o')
plt.axline((1, 1), (1000, 1000))

I propose to not support any non-linear axes and raise an error instead. If there's some request and a plausible use case, we can always add such functionality later.

Edit: I just read the docstring of axline()

This draws a straight line "on the screen", regardless of the x and y
scales, and is thus also suitable for drawing exponential decays in
semilog plots, power laws in loglog plots, etc.

While technically, that's possible, I think it's not a good API. Does anybody really need "exponential decay through two points" or "powerlaw through two points"? I suspect that these would better be separate explicit functions. Therefore I stand by my claim that axline() should only be used with linear scales.

However, if there is consensus that we should keep two-point-non-linear-scale, I would also be ok to just not allow slope, intercept for non-linear scales.

Well, I wrote this explicitly with the intent of supporting exponential and loglogs, and yes, two-point is not a great parametrization of such things, but there is no canonical parametrization of such things (for exponentials, do you want to use the rate? the mean lifetime? the half-life? do you want to have an implicit minus in front of the rate, which would help those (likely the majority) plotting decays, but look weird when you're not?), so two-point is not actually that bad IMO.

Reading through the discussion here, I wonder if what people want might be a general purpose function plotter, something like

 Axes.plot_function(func, xrange=None, yrange=None, in_autoscale=None, density=1)

which would evaluate func either over a given range or over the current datarange of the axes at draw time. For a line with slope and intersept, it would then be about calling
ax.plot_function(lambda x: slope*x + intercept).

That would in principle be interesting, but only if it would automatically resample or directly draw the function in the backend. For fixed sampling and ranges ˋax.plot(x, f(x))ˋ already works.

Resampling or direct drawing is a much more complex topic than defining/calculating a line once and drawing it to infinity.