From an email exchange about plotting arcsec, slightly out of order:

The immediate context for this issue is a couple of problems that include, among other things, graphing arcsec and its derivative (in one case), arcsec and arccsc (in the other). Since the range of intended functions is known, it appears that this would work if the students follow instructions (big if). But more generally, we want students to have total control over their "graphing calculator" -- at least over the input boxes we provide -- so there's nothing stopping them from entering arcsec(x/2) or something else that we can't anticipate.

The underlying problem is that the plotting code ignores everything
between -1 and 1 (since those values aren't real), but then simply
connects (-1,3) and (1,.2) (or so) with a line segment when it's done. I
have a couple ideas for fixing this, but they won't help you in the near
term.

One workaround for your @interact would be to select an option for
exclude based on the function: I'm thinking of something like this:

@interact
def foo(fn=textbox(), ....):
setup stuff...

if fn == 'arcsin':
    exclude=[]
elif fn == 'arcsec':
    exclude=[-1,1]

plot(fn, ...., exclude=exclude)

The idea is just to look at the function being plotted and set a list of
points to exclude based on that. It would be tedious to code, but would
work.

I think that fixing this is possible. I spent about a half hour looking at http://hg.sagemath.org/sage-main/file/9ab4ab6e12d0/sage/plot/plot.py just now and I am pretty sure that one could extract bad points like nan in generate_plot_points. Currently we just do

data = [data[i] for i in range(len(data)) if i not in exception_indices]

which means we completely ignore them, but presumably we could keep this data somehow and return it as part of generate_plot_points (not sure whether that would have to be deprecated) so that we could add that somehow to the exclude data around http://hg.sagemath.org/sage-main/file/9ab4ab6e12d0/sage/plot/plot.py#l1279

The problem is that there could be a lot of these, and that could slow things down a lot to check all of them, but checking for a "consecutive series" would also take some time.

Anyway, it's at least doable in principle, but would take some time and care to implement, making sure it didn't cause any other regressions.

Apply to devel/sage:

1. attachment: trac_13246-rebase.patch
2. attachment: trac_13246-parametric.patch

Depends on #16439

CC: @dandrake @ppurka @jondo @vbraun

Component: graphics

Author: Punarbasu Purkayastha

Branch/Commit: 384b5a2

Reviewer: Ralf Stephan, Karl-Dieter Crisman

Issue created by migration from https://trac.sagemath.org/ticket/13246