fast_float yields infinity when Python does, but should handle bigger numbers

[nthiery]

It sounds like the adaptative algorithm fails to find suitable
evaluation points when plotting large functions (like exp) in loglog
scale. In the following example, the exp function gets drawn with only
three points:

sage: plot([n^2,exp(n)], xmin=1, xmax=10^5, ymin=1,ymax=10^10, scale="loglog")
verbose 0 (2397: plot.py, generate_plot_points) WARNING: When plotting, failed to evaluate function at 198 points.
verbose 0 (2397: plot.py, generate_plot_points) Last error message: ''

If xmax is replaced by 10^10, the function is not even drawn:

sage: sage: plot([n^2,exp(n)], xmin=1, xmax=10^10, ymin=1,ymax=10^10, scale="loglog")
verbose 0 (2397: plot.py, generate_plot_points) WARNING: When plotting, failed to evaluate function at 199 points.
verbose 0 (2397: plot.py, generate_plot_points) Last error message: ''

On the other hand, the equivalent semilogy plot works smoothly:

sage: plot([10^n,exp(10^n)], xmin=0, xmax=5, ymin=1,ymax=10^10, scale="semilogy")
verbose 0 (2397: plot.py, generate_plot_points) WARNING: When plotting, failed to evaluate function at 86 points.
verbose 0 (2397: plot.py, generate_plot_points) Last error message: ''

(Such plots are typically useful in classes about algorithmic complexity http://combinat.sagemath.org/doc/thematic_tutorials/agregation-option-calcul-formel/tris_et_complexite.html)

Depends on #15030

CC: @eviatarbach

Component: basic arithmetic

Keywords: agregation

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

[nthiery]

Changed keywords from none to agregation

[ppurka]

comment:2

It is not a problem with loglog. There is the same problem with normal plots.

sage: var('n')
sage: plot([n^2,exp(n)], xmin=1, xmax=10^5, ymin=1,ymax=10^10)
verbose 0 (2395: plot.py, generate_plot_points) WARNING: When plotting, failed to evaluate function at 198 points.
verbose 0 (2395: plot.py, generate_plot_points) Last error message: ''

FYI, the change to loglog/semilog* scale happens only during the very end when show() is called. This happens after the generation of the plot points. Though I can't understand why semilogy is working fine for you (you still get the warnings though).

[nthiery]

comment:3

Replying to @ppurka:

FYI, the change to loglog/semilog* scale happens only during the very end when show() is called. This happens after the generation of the plot points.

Really??? Ouch! In a x log scale one certainly would want to disperse ploting points differently.

[kcrisman]

comment:4

FYI, the change to loglog/semilog* scale happens only during the very end when show() is called. This happens after the generation of the plot points.

Really??? Ouch! In a x log scale one certainly would want to disperse ploting points differently.

True, but that would be another ticket. And sometimes one would want to plot the same data in two different ways, so we wouldn't want to remove that entirely.

[nthiery]

comment:5

Hi!

Replying to @kcrisman:

True, but that would be another ticket.

Well, unless there is a quick solution for just the issue stated in this ticket, I am happy recycling it to whatever the right fix should be (taking into account the log scale early or delaying the generation of the evaluation points to show).

And sometimes one would want to plot the same data in two different ways, so we wouldn't want to remove that entirely.

I don't know the current implementation, so there might be technical obstructions I can't see; however, in principle, isn't the data really the function rather than the points? In that case, should'nt the points just be recalculated as needed?

[ppurka]

comment:6

Replying to @nthiery:

I don't know the current implementation, so there might be technical obstructions I can't see; however, in principle, isn't the data really the function rather than the points? In that case, should'nt the points just be recalculated as needed?

Suppose you want to plot the points (0, 1), (1, 10), (2, 100), (3, 1000). Then what you could do is send these points to matplotlib and ask it to plot it in a linear scale by using, say, pyplot.plot(x, y). Alternatively, if you want semilogy plot, you could do pyplot.semilogy(x, y), where x and y are the data points along the x and y axes. Note that we do not send the "linearized" data points [0, 1, 2, 3] (obtained by taking log of [1, 10, 100, 1000] to the base 10) as the y list to matplotlib.

Now, suppose you want to plot 10**n for large values of n. You would still do the same thing. Find the values of this function in the linear scale and then pass on the computed values to matplotlib to plot it on the logarithmic scale. In either case, the computation of the values of the function is being done on the linear scale. And it is this computation that is failing in your examples. As of now, this problem needs a fix even on the linear scale, let alone the log scale.

[ppurka]

comment:7

In fact, I just realized why you are getting the errors. The problem is with fast_float.

sage: set_verbose(1)
sage: p = plot_loglog(exp(x), (1, 10^5), plot_points=2)
verbose 1 (2397: plot.py, generate_plot_points)
Unable to compute f(100000.0) (time = 19.237264)
sage: exp(100000.0).n()
2.80666336042612e43429
sage: from sage.ext.fast_eval import fast_float
sage: f(x) = exp(x)
sage: v = f.variables()
sage: F = fast_float(f, *v)
sage: F(100000.0)
inf

Maybe you are better off generating the list of data points by using exact arithmetic in Sage and then passing off the list to list_plot.

[kcrisman]

comment:8

In fact, I just realized why you are getting the errors. The problem is with fast_float.

sage: from sage.ext.fast_eval import fast_float
sage: f(x) = exp(x)
sage: v = f.variables()
sage: F = fast_float(f, *v)
sage: F(100000.0)
inf

Huh, that is not good.

sage: F(709.7)
1.6549840276802644e+308
sage: F(709.8)
inf

That's as much bisecting as I want to do. And really, here is what is going on, I suspect.

In [3]: import math

In [6]: math.exp(709.8)
---------------------------------------------------------------------------
OverflowError                             Traceback (most recent call last)

/Users/.../<ipython console> in <module>()

OverflowError: math range error

In [7]: math.exp(709.7)
Out[7]: 1.6549840276802644e+308

So fast_float really is doing floats, but we need something better than that.