plotting and float

[kcrisman]

Dear Support,

So I've always had some trouble with syntax for complex_plot and
plot3d. Namely, if you don't get the form of the function just right,
it complains about not being able to make things a float. Now, I'm
getting something even odder:

sage: f(x,y) = abs(e^(pi*i*x)+e^(pi*i*y))
sage: plot3d(f,(0,1),(0,1))
[works fine}
sage: plot3d(f,(x,0,1),(y,0,1))
TypeError: float() argument must be a string or a number

which comes from calling GEx_to_double in __float__ somewhere along
the line, probably in ParametricSurface. But how do we fix this?
Similarly,

sage: f(x,y) = e^(pi*i*x)+e^(pi*i*y)
sage: g(z) = f(z.real(),z.imag())
sage: g(.5+.5*i)
2*e^(.5*i*pi)
sage: complex_plot(g,(0,1),(0,1))
TypeError [same one]

Incidentally, it would be nice for complex_plot to take a function of
two variables with complex output as the input... as long as the docs
made very clear that the interpretation was var1=x, var2=y no matter
the "real" names of var1 and var2.

But anyway, these errors are really annoying. I would be happy to
help fix them if support had a sense of where they are coming from
exactly; it should just be a matter a few more if/then or try/except,
I figure.

Thanks,
- kcrisman

[William Cauchois]

It seems to me that the error comes from feeding a function which uses
i into fast_float (called by the plotting functions to compile the
function to be plotted into an optimized form). I tried a simpler
function using i and got the same error:

sage: plot3d(x + y + i, (x, 0, 1), (y, 0, 1))
Traceback (click to the left for traceback)
...

TypeError: float() argument must be a string or a number

sage: from sage.ext.fast_eval import fast_float
sage: fast_float(x + i, 'x')
Traceback (click to the left for traceback)
...

TypeError: float() argument must be a string or a number

It would make sense for the low-level representation used by
fast_float not to include a concept of imaginary numbers. Have you had
success plotting any other functions that use imaginary numbers? There
should be a mechanism to fall back to using the unmodified function in
the event that fast_float fails to convert the function.

[Robert Bradshaw]

The code leaves a lot to be desired. For example, now that we have
fast_callable, with CDF support, we should be using that. Actually,
we're using the helper function setup_for_eval_on_grid (to normalize
the boundaries) and then ignoring the returned function, so this
check is completely useless.

As for being a function of one or two variables, it's unclear what
the best approach is to take here. Clearly we want to allow plotting
complex functions of a complex variable, but the alternative is
useful too. For functions, the number (and names) of the arguments
they take is explicit, but for expressions like sin(z) or x+y+i it's
not as obvious. Does the x in plot3d(x+1, ...) stand for the real
part of the complex argument, or the entire thing? Or perhaps the
bounds should be complex numbers defining the rectangle, like

sage: plot3d(exp(z), (z, -1-i, 1+i))

though I'm not sure I like this notation either.

- Robert

[kcrisman]

> The code leaves a lot to be desired. For example, now that we have  
> fast_callable, with CDF support, we should be using that. Actually,  
> we're using the helper function setup_for_eval_on_grid (to normalize  
> the boundaries) and then ignoring the returned function, so this  
> check is completely useless.

Yes, that would be very good. Would that be hard to implement (for
someone who didn't write fast_callable or fast_float, that is, as they
are busy enough :) )?

>
> As for being a function of one or two variables, it's unclear what  
> the best approach is to take here. Clearly we want to allow plotting  
> complex functions of a complex variable, but the alternative is  
> useful too. For functions, the number (and names) of the arguments  
> they take is explicit, but for expressions like sin(z) or x+y+i it's  
> not as obvious. Does the x in plot3d(x+1, ...) stand for the real  
> part of the complex argument, or the entire thing? Or perhaps the  
> bounds should be complex numbers defining the rectangle, like

The current notation is fine for now. The problem is that my plot3d
was in fact a real-valued function, and my complex_plot function was a
nice complex-valued one, but they both went boom. The remark about
input was just an aside, sorry for obscuring the main point.

- kcrisman

[William Stein]

2009/9/1 Robert Bradshaw <robe...@math.washington.edu>

Trying to do plot(...) or plot3d(...) on a function that outputs complex numbers should result in a really useful error message, with instructions about how to plot real/imag/abs/arg parts, maybe?
 

sage: plot3d(exp(z), (z, -1-i, 1+i))

though I'm not sure I like this notation either.

- Robert

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

[William Cauchois]

By the way, you can make your original example work by using a lambda
instead of a symbolic expression:

sage: plot3d(lambda x, y: abs(e^(pi*i*x)+e^(pi*i*y)), (0,1), (0,1))

Should work. (Although I'm getting the error "plot variables should be
distinct", which I think is a bug; workaround is to change one of the
lower bounds to 0.1 instead of 0.)

[kcrisman]

On Sep 3, 3:38 pm, William Cauchois <wcauch...@gmail.com> wrote:
> By the way, you can make your original example work by using a lambda
> instead of a symbolic expression:
>
> sage: plot3d(lambda x, y: abs(e^(pi*i*x)+e^(pi*i*y)), (0,1), (0,1))

Oh, yes, I know. And I try to avoid using lambda notation whenever
possible, because I don't fully understand it even when I do use it,
and my students certainly don't. Hence this post.

Again, my point was that I inputted a real-valued function to plot3d,
and a complex-valued one to complex_plot, and both died. But I don't
know how to fix it, unless the code for fast_callable is easier to
work with than I think. Sorry it seems there is no easy fix for this.

- kcrisman