Please test #8433 (notebook, tachyon)
Jeroen Demeyer
people but not for others. I believe it would be useful to have some
people test it such that we might determine why it works on some systems
but not on others.
It's just a matter of copy-pasting the code in the bug report from
http://trac.sagemath.org/sage_trac/ticket/8433 to a notebook and seeing
whether the plot "hangs" or not.
Thanks,
Jeroen.
David Kirkby
I don't have Sage on this laptop, and are not at home. But I tested it
on t2.math
http://t2nb.math.washington.edu:8000/home/pub/41/
(Solaris 10 SPARC)
and as you can see it does work. Note that is with Sage 4.5.1, so is a
few releases old
For comparison here is the same plot in Mathematica, using:
Plot3D[Sqrt[Sin[x] Sin[y]],{x,-2 Pi, 2 Pi},{y, - 2 Pi, 2 Pi}]
http://boxen.math.washington.edu/home/kirkby/Plot3D-in-Mathematica-of-sqrt-sin-x-sin-y.png
which is a lot more aesthetically pleasing, with the false color, but
has a quite different shape too.
I must admit I can't understand the difference between them. I have
some difficulty visualising in my mind what this should look lke.
Clearly the product sin(x) sin(y) will be negative for some values of
x and y, so when the square root is taken, one will get a complex
number, which I assume neither package plots. So I can understand why
this can't be plotted for all combinations of x and y.
However, the plot from Mathematica always falls to zero smoothly
before being cut-off. This actually seems to me more believeable than
the Sage plot, but I may be mistaken.
When I'm at home next, I'll try the same in MATLAB and see how that compares.
Dave
Jason Grout
Yes. I think the problem is that in Sage, we do not try to break up
plotting triangles to find out the actual boundaries of a domain.
Instead, we just try to plot the triangle that goes across the domain
boundary, find that one corner of the triangle is off the domain, and so
we don't plot the triangle.
In this case, I think the result doesn't look *too* bad, though it is
incorrect. In other cases, it leads to a very jagged figure where the
domain stops.
Try:
y=var('y')
B=plot3d(sqrt(sin(x)*sin(y)),(x,-2*pi,2*pi),(y,-2*pi,2*pi),viewer='tachyon',plot_points=400)
B.show()
to make those triangles at the edge of the domain smaller.
By the way, in an effort to make this plot look better, I did notice a bug:
B=plot3d(sqrt(sin(x)*sin(y)),(x,-2*pi,2*pi),(y,-2*pi,2*pi),viewer='tachyon',adaptive=True)
gives:
ValueError: cannot convert float NaN to integer
Thanks,
Jason
David Kirkby
> On 11/4/10 5:01 AM, David Kirkby wrote:
>> For comparison here is the same plot in Mathematica, using:
>>
>> Plot3D[Sqrt[Sin[x] Sin[y]],{x,-2 Pi, 2 Pi},{y, - 2 Pi, 2 Pi}]
>>
>>
>> http://boxen.math.washington.edu/home/kirkby/Plot3D-in-Mathematica-of-sqrt-sin-x-sin-y.png
>>
>> which is a lot more aesthetically pleasing, with the false color, but
>> has a quite different shape too.
>>
>> I must admit I can't understand the difference between them. I have
>> some difficulty visualising in my mind what this should look lke.
>> Clearly the product sin(x) sin(y) will be negative for some values of
>> x and y, so when the square root is taken, one will get a complex
>> number, which I assume neither package plots. So I can understand why
>> this can't be plotted for all combinations of x and y.
>>
>> However, the plot from Mathematica always falls to zero smoothly
>> before being cut-off. This actually seems to me more believeable than
>> the Sage plot, but I may be mistaken.
>
> Yes. I think the problem is that in Sage, we do not try to break up
> plotting triangles to find out the actual boundaries of a domain. Instead,
> we just try to plot the triangle that goes across the domain boundary, find
> that one corner of the triangle is off the domain, and so we don't plot the
> triangle.
>
> In this case, I think the result doesn't look *too* bad, though it is
> incorrect. In other cases, it leads to a very jagged figure where the
> domain stops.
Personally I think it's pretty bad, as it indicates discontinuities
which simply do not exist. It's not such a big deal with this
equation, as one can take a guess that theres a problem. But on
something were I were unable to do that, it could lead to all sorts of
mis-leading confusions.
> Try:
>
> y=var('y')
> B=plot3d(sqrt(sin(x)*sin(y)),(x,-2*pi,2*pi),(y,-2*pi,2*pi),viewer='tachyon',plot_points=400)
> B.show()
>
> to make those triangles at the edge of the domain smaller.
It looks smoother, but does not change the fundamental problem
> By the way, in an effort to make this plot look better, I did notice a bug:
>
> B=plot3d(sqrt(sin(x)*sin(y)),(x,-2*pi,2*pi),(y,-2*pi,2*pi),viewer='tachyon',adaptive=True)
>
> gives:
>
> ValueError: cannot convert float NaN to integer
That should go on a trac ticket. I'm just about to cook dinner now,
but if nobody beats me to it, I'll create one later.
Dave
Jason Grout
> It looks smoother, but does not change the fundamental problem
I agree. I guess one way to deal with the problem is to subdivide the
space like the implicit_plot3d function does. Another way is to use the
adaptive plotting (which presumably slices up triangles as needed), but
as you saw, that currently has a NaN issue that prevents it from working.
Thanks,
Jason
David Kirkby
It might be worth adding 1.1 or somthing like that so the result is
always positive and never complex. That might avoid NAN's, but again
does not solve the problem. But it might indicate where it is.
Dave
R. Grout
would be of help.
see numpy.nan_to_num(). If 'nan' then 0; 'inf' (infinity) -> some
really huge number
http://www.scipy.org/Numpy_Example_List_With_Doc#head-c98ac710ae88aadee85e953af821e560ab316ef3
I also notice that the traceback includes these two lines of code at
the end
span = (len(texture)-1) / (max_z -
min_z) # max to avoid dividing by 0
--> 777 parts = P.partition(lambda x,y,z: int((z-
min_z)*span))
If we want to still preserve nan, there are min and max functions in
numpy designed to handle nan (ie ignore nan values) Maybe those could
be of use too (for min_z and max_z).