octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #52904] "mesh" with input array of "logical" c


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #52904] "mesh" with input array of "logical" causes error
Date: Tue, 16 Jan 2018 14:26:09 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #9, bug #52904 (project octave):

@Rik:
"Incidentally, running this in Octave results in a segfault because the handle
h is created, but it is in an invalid state."
"As an example of what is wrong,
h = surf ('foobar')
ishghandle (h)
error: 'h' undefined near line 1 column 13
get (gca, 'children')
ans = -18.192
h is not defined, but the current axes does contain a surface object."

OK, you've isolated the main issue: that handle still hanging around even
after an incomplete graphics object.  I suppose because that handle still
resides on the parent graphics object (axes) the update_XYZdata() callbacks
still remain active.  Hence the attempted redraw of the surface in the
graphics_toolkit.

@Markus:
">> h = surf (Z);
Error using matlab.graphics.chart.primitive.Surface/set
Invalid parameter/value pair arguments.
So at least the development branch seems to behave in this respect."

That seems the most logical thing to do, otherwise "logical" class data would
be acceptable as input but not setting zdata directly.  That's just best for
consistency sake; but this doesn't agree with what the original post said,
i.e., that Matlab converts the logical class data to something else... Hold
on, I just looked at the original post's example code, and there's no evidence
to suggest that is what Matlab does.  There is "+0" tossed into the code to
convert the logical-class data to double-class data prior to the mesh()
creation:


a=(abs(z)<0.8) & (abs(z)>0.3); # mmmm, donuts!
mesh(a+0); % workaround, convert to real


I'm not sure if the original submission meant that the above code was
something rehabilitated from previous Matlab-valid code or that the "+0" was
added to make it work in Octave.

More generally, yeah, I suspect that there needs to be some more fundamental
change in the validation test handling in graphics.cc.  I suspect if we were
to simply add checks at the .m level to solve the mesh/surface problem, this
same issue might eventually manifest somewhere else in some way, such as if a
user were to build some custom GUI code/program from graphics objects.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52904>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]