#12798: list_plot3d plots extraneous points at z=0 and doesn't take color or
rgbcolor as keywords
--------------------------------------------------------------+-------------
Reporter: ppurka | Owner:
jdemeyer
Type: defect | Status:
needs_work
Priority: major | Milestone:
sage-5.2
Component: graphics | Resolution:
Keywords: list_plot3d, sd40.5 | Work issues:
Report Upstream: N/A | Reviewers:
Karl-Dieter Crisman, Punarbasu Purkayastha, Jeroen Demeyer
Authors: Punarbasu Purkayastha, Karl-Dieter Crisman | Merged in:
Dependencies: | Stopgaps:
--------------------------------------------------------------+-------------
Comment (by ppurka):
Replying to [comment:45 jdemeyer]:
> ...although, strangely enough, the doctest timeout is gone on Solaris
with that patch. I'm still not happy with this patch because of the
`nan`s, but I don't mind if somebody wants to give it positive review.
>
> Somebody still needs to test the patch and check whether the output 3D
plots still look like they should.
I had a fresh look at this ticket. The last patch that I posted which
trims the `xvals` and `yvals` on the basis of whether there are `nan`s or
not, is actually incorrect. This can be tested on a simple 3D plot:
{{{
list_plot3d([(0,0,1), (1,0,0), (0,1,0)], num_points=5)
}}}
The output is a square instead of a triangle and the square persists even
for `num_points=100`. This is because we trim the x and y values. Without
the third patch, the earlier patches in this ticket actually gives a
correct plot (even for such a low value of `num_points=5`).
As for the presence of `nan`s. This is all correct and there is no
contradiction or error here. If you look at what is going on, there is a
matrix being created called `vals` which contains all possible z values
corresponding to `x in xvals` and `y in yvals` which should appear in our
3D plot. In the simple example above, `xvals = [0, 0.25, 0.5, 0.75, 1]`
and `yvals` is the same. So '''all''' possible points `(x,y)` with `x` and
`y` taking values from `xvals` and `yvals`, respectively, is the cartesian
product `xvals x yvals` and it will will include points like `(0.75,
0.75)` or `(0.75, 1)`, etc, which should have no corresponding finite
value in `vals`. All these values in the matrix are set to `nan`. Prior to
this ticket, they were being set to 0.
So, every time the ranges of `x` and `y` do not form a square, there will
be `nan`s in the matrix `vals`, and this can not be avoided if you want an
accurate plot. So, it is pointless to try and remove `nan`s.
So now, the question is, why does `ParametricSurface` take so much time
only during the doctests and only on Solaris arch. I don't know the
answer, and the code in that class (and in `IndexFace`, etc) is too
complex for me and not very well documented.
At this point, what I suggest is to merge the changes regarding the
colors, and leave the `list_plot3d` alone. If it sounds reasonable, then I
will open a new ticket regarding the colors and leave this ticket for the
future, when the Solaris arch goes out of fashion!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12798#comment:50>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
