bugGNU Octave - Bugs: bug #39767, findobj sorts list of returned...

 
 

bug #39767: findobj sorts list of returned handles

Submitted by:  Ben Abbott <bpabbott>
Submitted on:  Mon 12 Aug 2013 11:57:59 AM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Matlab Compatibility
Status: FixedAssigned to: None
Originator Name: Ben AbbottOpen/Closed: Closed
Release: devOperating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue 13 Aug 2013 11:39:45 PM UTC, comment #14:

I checked in a changeset that doesn't use union() and therefore returns the same ordering of objects as Matlab (http://hg.savannah.gnu.org/hgweb/octave/rev/3fd617363762). I moved the test about the ordering of axis handles from graphics.cc to findobj.m.

Rik <rik5>
Project Administrator
Tue 13 Aug 2013 09:55:12 PM UTC, comment #13:

Rik,

What code are you suggesting be removed from graphics.cc?

Ben Abbott <bpabbott>
Project Member
Tue 13 Aug 2013 09:54:05 PM UTC, comment #12:

Without all of Matlab's uimenu/toolbar, etc

Ben Abbott <bpabbott>
Project Member
Tue 13 Aug 2013 09:39:14 PM UTC, comment #11:

>> hfig = figure (1);
>> hax1 = subplot (2,1,1); hp1 = plot (rand (10,1));
>> hax2 = subplot (2,1,2); hp2 = plot (rand (10,1));
>> findall (hfig)


ans =

1.0000
172.0011
170.0012
144.0011
132.0011
131.0011
80.0011
64.0011
57.0011
37.0011
18.0011
0.0011
173.0016
171.0016
169.0011
168.0011
167.0011
166.0011
165.0011
164.0011
163.0011
149.0011
148.0011
147.0011
146.0011
145.0011
143.0011
142.0011
141.0011
140.0011
139.0011
138.0011
137.0011
136.0011
135.0011
134.0011
133.0011
130.0011
129.0011
120.0011
111.0011
104.0011
103.0011
102.0011
101.0011
100.0011
99.0011
90.0011
89.0011
88.0011
87.0011
86.0011
85.0011
84.0011
83.0011
82.0011
81.0011
79.0011
78.0011
77.0011
76.0011
75.0011
74.0011
73.0011
72.0011
71.0011
70.0011
69.0011
68.0011
67.0011
66.0011
65.0011
63.0011
62.0011
61.0011
60.0011
59.0011
58.0011
56.0011
55.0011
54.0011
53.0011
52.0011
51.0011
50.0011
49.0011
48.0011
47.0011
46.0011
45.0011
44.0011
43.0011
42.0011
41.0011
40.0011
39.0011
38.0011
36.0011
35.0011
34.0011
33.0011
32.0011
31.0011
30.0011
29.0011
28.0011
27.0011
26.0011
25.0011
19.0011
17.0011
16.0011
15.0011
14.0011
13.0011
11.0011
10.0011
9.0011
8.0011
7.0011
6.0011
5.0011
4.0011
3.0011
2.0011
1.0011
162.0011
161.0011
160.0011
159.0011
158.0011
157.0011
156.0011
155.0011
154.0011
153.0011
152.0011
151.0011
150.0011
128.0011
127.0011
126.0011
125.0011
124.0011
121.0011
119.0011
118.0011
117.0011
116.0011
115.0011
114.0011
113.0011
112.0011
110.0011
109.0011
108.0011
107.0011
106.0011
105.0011
98.0011
97.0011
96.0011
95.0011
94.0011
93.0011
92.0011
91.0011
24.0011
23.0011
22.0011
21.0011
20.0011
12.0011
123.0011
122.0011

>> version


ans =

7.9.0.529 (R2009b)

Michael Godfrey <godfrey>
Project Member
Tue 13 Aug 2013 09:24:24 PM UTC, comment #10:

Seems like this should be fixed. The test for correct ordering can then be moved out of graphics.cc and over to findobj.m. What is the order of return for Matlab?

Is the grouping flat at each level as shown below?

hfig
hax2
hax1
hp2
hp1

or does it intersperse the children like so?

hfig
hax2
hp2
hax1
hp1

Rik <rik5>
Project Administrator
Tue 13 Aug 2013 08:07:06 PM UTC, comment #9:

Rik,

My apologies, I think I've been confusing myself.

I have a simple example which indicates the difference between Octave and Matlab (same conclusion as you) First Matlab,

And now Octave

Your observation that the problem is with findobj() looks correct to me. Should that be fixed?

Ben Abbott <bpabbott>
Project Member
Tue 13 Aug 2013 07:32:35 PM UTC, comment #8:

Ben,

I extracted the failing test and put it in its own m-file, tst_findall.m, which is attached. Now you can run

The first time it will pass. And it will fail on all subsequent times. The problem is in the findall call. It does not return the objects in the same order as they are in the figure. There is a keybard() call I used to debug the test. If you uncomment it and then run the failing test I get.

First, we should just be able to run findobj() here. Second, there is something in findobj. I suspect it is the call to union().

union is for set objects which have no ordering, only membership. It would be better to use ordinary concatenation. get() will always return column vectors so this isn't a problem. I changed findobj() to

And the test passes now.

Rik <rik5>
Project Administrator
Tue 13 Aug 2013 07:13:32 PM UTC, comment #7:

position(1,:) is for hax(1) which corresponds to the last axes created -> subplot (2, 1, 2))

Ben Abbott <bpabbott>
Project Member
Tue 13 Aug 2013 06:19:59 PM UTC, comment #6:

I think the assert statement is wrong.

The first axes in the list is positioned towards the bottom of the canvas. Therefore, it's Y value should be smaller, not larger, than the second axes. If I flip the comparison around

then the test passes on the first time and now fails repeatably every time after that. There is still a problem in that axes are ordered incorrectly on all subsequent tests.

Rik <rik5>
Project Administrator
Tue 13 Aug 2013 05:37:13 PM UTC, comment #5:

Ok. I may have misunderstood what is happening. Running the script below from a file,

Matlab gives

and Octave gives

After restarting Octave, the similar test in graphics.cc fails for me.

However, if I run the test a second time, it passes.

Ben Abbott <bpabbott>
Project Member
Tue 13 Aug 2013 05:17:32 PM UTC, comment #4:

I'm in violent agreement with you. kids(1) should be the last axes created and it is the last axes created according to

The %!test you wrote shows that the position value for axes 1 is being assigned to axes 2 and vice versa, but it doesn't seem to show an incorrect ordering of axes.

Rik <rik5>
Project Administrator
Tue 13 Aug 2013 04:39:07 PM UTC, comment #3:

kids(1) should always be the last axes created.

When the graphics.cc test fails, the results indicate that the axes are not ordered correctly.

Ben Abbott <bpabbott>
Project Member
Tue 13 Aug 2013 04:22:05 PM UTC, comment #2:

What is the behavior, i.e. Matlab, that we are looking for?

When I execute

The bottom subplot, the last one plotted, turns green. This is what I would expect as it was the last plot done so its axes appears first, i.e., on top in the list of children.

Rik <rik5>
Project Administrator
Mon 12 Aug 2013 10:11:14 PM UTC, comment #1:

I added a test to detect this

http://hg.savannah.gnu.org/hgweb/octave/rev/d9ca0f44f1e7

Ben Abbott <bpabbott>
Project Member
Mon 12 Aug 2013 11:57:59 AM UTC, original submission:

I'm seeing a failure the first time tests are run on graphics.cc

The test fails due to the axes objects being in the wrong order. Subsequently, all tests pass.

Ben Abbott <bpabbott>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by bpabbott (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 13 Aug 2013 11:39:45 PM UTCrik5Item GroupInaccurate Result=>Matlab Compatibility
      StatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Tue 13 Aug 2013 09:24:24 PM UTCrik5Summaryinitial axes are not ordered properly=>findobj sorts list of returned handles

    Back to the top


    Powered by Savane 3.1-cleanup1