[Scilab-users] question on graphic children order

classic Classic list List threaded Threaded
13 messages Options
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

[Scilab-users] question on graphic children order


Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:


scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data
 
// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])
 
// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
   0.   0.
   1.   1.

After the second plot we get

b  =
   0.   0.5
   1.   1.5

c  =

   0.   0.
   1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.  

Regards,

Federico Miyara


Libre de virus. www.avast.com

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: question on graphic children order

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:


scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data
 
// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])
 
// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
   0.   0.
   1.   1.

After the second plot we get

b  =
   0.   0.5
   1.   1.5

c  =

   0.   0.
   1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.  

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.


Regards,

Federico Miyara


Libre de virus. www.avast.com

_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

Re: question on graphic children order


Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

Federico


On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:


scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data
 
// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])
 
// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
   0.   0.
   1.   1.

After the second plot we get

b  =
   0.   0.5
   1.   1.5

c  =

   0.   0.
   1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.  

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.


Regards,

Federico Miyara


Libre de virus. www.avast.com

_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: question on graphic children order

Le 08/04/2019 à 22:56, Federico Miyara a écrit :


Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

So what is your problem since you know that the order of entities is, though not natural, reproductible ? If you really need to recover a deeply hidden entity, use tags and the findobj() function.

S.


Federico


On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:


scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data
 
// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])
 
// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
   0.   0.
   1.   1.

After the second plot we get

b  =
   0.   0.5
   1.   1.5

c  =

   0.   0.
   1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.  

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.


Regards,

Federico Miyara


Libre de virus. www.avast.com

_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
der_Phil der_Phil
Reply | Threaded
Open this post in threaded view
|

Re: question on graphic children order

Federico...thanks for asking the question.
I was wondering about it myself for quite some time.
Once recognizing the fact, I just accepted that new entities are placed at the first position.
However, it might be interesting to get some insight of why it is like this....for now I guessed it has to do with how to handle memory.

Philipp 


Am Mo., 8. Apr. 2019 um 23:01 Uhr schrieb Stéphane Mottelet <[hidden email]>:

Le 08/04/2019 à 22:56, Federico Miyara a écrit :


Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

So what is your problem since you know that the order of entities is, though not natural, reproductible ? If you really need to recover a deeply hidden entity, use tags and the findobj() function.

S.


Federico


On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:


scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data
 
// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])
 
// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
   0.   0.
   1.   1.

After the second plot we get

b  =
   0.   0.5
   1.   1.5

c  =

   0.   0.
   1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.  

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.


Regards,

Federico Miyara


Libre de virus. www.avast.com

_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Antoine Monmayrant Antoine Monmayrant
Reply | Threaded
Open this post in threaded view
|

Re: question on graphic children order

Hello,

As Stéphane said, using a tag and findobj is a possibility that I use for complex layouts.
Here is another one: build your own vector of handles that you order the way you want:

as=[];
subplot(221)
plot(1,2)
as=[as,gca()]
subplot(222)
plot(1:2,2:3)
as=[as,gca()]
subplot(223)
plot(2*[1:2],2:3)
as=[as,gca()]
subplot(224)
plot(2*[1:2],-[2:3])
as=[as,gca()]
as.foreground=color('gray');
as.background=color('lightgray');
as.thickness=2;
as.font_size=4;

Cheers,

Antoine

Le 09/04/2019 à 08:30, P M a écrit :
Federico...thanks for asking the question.
I was wondering about it myself for quite some time.
Once recognizing the fact, I just accepted that new entities are placed at the first position.
However, it might be interesting to get some insight of why it is like this....for now I guessed it has to do with how to handle memory.

Philipp 


Am Mo., 8. Apr. 2019 um 23:01 Uhr schrieb Stéphane Mottelet <[hidden email]>:

Le 08/04/2019 à 22:56, Federico Miyara a écrit :


Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

So what is your problem since you know that the order of entities is, though not natural, reproductible ? If you really need to recover a deeply hidden entity, use tags and the findobj() function.

S.


Federico


On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:


scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data
 
// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])
 
// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
   0.   0.
   1.   1.

After the second plot we get

b  =
   0.   0.5
   1.   1.5

c  =

   0.   0.
   1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.  

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.


Regards,

Federico Miyara


Libre de virus. www.avast.com

_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

 Antoine Monmayrant LAAS - CNRS
 7 avenue du Colonel Roche
 BP 54200
 31031 TOULOUSE Cedex 4
 FRANCE

 Tel:+33 5 61 33 64 59
 
 email : [hidden email]
 permanent email : [hidden email]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

Re: question on graphic children order


Antoine,

Thank you for your suggestion. It's a good one, but I still don't know the reason why the index of the current entity is 1 (my question was not really about workarounds but reasons). Stéphane said it was a stack, but as far as I could find, there is no stack structure in Scilab 6. But in any case, if the inclusion of new graphic entities is organized as a stack, the question is why, since actually operations on a stack generally refer to the topmost entity and in this case all entities are accessible via indices.

Regards,

Federico



On 09/04/2019 04:22, Antoine Monmayrant wrote:
Hello,

As Stéphane said, using a tag and findobj is a possibility that I use for complex layouts.
Here is another one: build your own vector of handles that you order the way you want:

as=[];
subplot(221)
plot(1,2)
as=[as,gca()]
subplot(222)
plot(1:2,2:3)
as=[as,gca()]
subplot(223)
plot(2*[1:2],2:3)
as=[as,gca()]
subplot(224)
plot(2*[1:2],-[2:3])
as=[as,gca()]
as.foreground=color('gray');
as.background=color('lightgray');
as.thickness=2;
as.font_size=4;

Cheers,

Antoine

Le 09/04/2019 à 08:30, P M a écrit :
Federico...thanks for asking the question.
I was wondering about it myself for quite some time.
Once recognizing the fact, I just accepted that new entities are placed at the first position.
However, it might be interesting to get some insight of why it is like this....for now I guessed it has to do with how to handle memory.

Philipp 


Am Mo., 8. Apr. 2019 um 23:01 Uhr schrieb Stéphane Mottelet <[hidden email]>:

Le 08/04/2019 à 22:56, Federico Miyara a écrit :


Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

So what is your problem since you know that the order of entities is, though not natural, reproductible ? If you really need to recover a deeply hidden entity, use tags and the findobj() function.

S.


Federico


On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:


scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data
 
// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])
 
// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
   0.   0.
   1.   1.

After the second plot we get

b  =
   0.   0.5
   1.   1.5

c  =

   0.   0.
   1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.  

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.


Regards,

Federico Miyara


Libre de virus. www.avast.com

_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

 Antoine Monmayrant LAAS - CNRS
 7 avenue du Colonel Roche
 BP 54200
 31031 TOULOUSE Cedex 4
 FRANCE

 Tel:+33 5 61 33 64 59
 
 email : [hidden email]
 permanent email : [hidden email]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: question on graphic children order

Le 10/04/2019 à 01:24, Federico Miyara a écrit :


Antoine,

Thank you for your suggestion. It's a good one, but I still don't know the reason why the index of the current entity is 1 (my question was not really about workarounds but reasons). Stéphane said it was a stack, but as far as I could find, there is no stack structure in Scilab 6.

It was an image. The graphics objects tree is not built at the interpreter level but internally with, at the end, Java objects. In

modules/graphic_objects/src/java/org/scilab/modules/graphic_objects/graphicObject/GraphicObject.java

you can see that the set of children of a graphic object is a (Java) list

    /** Child objects list. Known by their UID */
    private List <Integer> children;

When a children is added to a graphic object, the the method "addChild" is invoked. In the source you can see

    public void addChild(Integer child) {
        children.add(0, child);
    }

Which is coherent with the actual behavior i.e. news children are pushed on the top.

What you would like is simply (without the 0)

    public void addChild(Integer child) {
        children.add(child);
    }

If I have time I can see if it breaks other things, but I am almost sure that it will...

S.




On 09/04/2019 04:22, Antoine Monmayrant wrote:
Hello,

As Stéphane said, using a tag and findobj is a possibility that I use for complex layouts.
Here is another one: build your own vector of handles that you order the way you want:

as=[];
subplot(221)
plot(1,2)
as=[as,gca()]
subplot(222)
plot(1:2,2:3)
as=[as,gca()]
subplot(223)
plot(2*[1:2],2:3)
as=[as,gca()]
subplot(224)
plot(2*[1:2],-[2:3])
as=[as,gca()]
as.foreground=color('gray');
as.background=color('lightgray');
as.thickness=2;
as.font_size=4;

Cheers,

Antoine

Le 09/04/2019 à 08:30, P M a écrit :
Federico...thanks for asking the question.
I was wondering about it myself for quite some time.
Once recognizing the fact, I just accepted that new entities are placed at the first position.
However, it might be interesting to get some insight of why it is like this....for now I guessed it has to do with how to handle memory.

Philipp 


Am Mo., 8. Apr. 2019 um 23:01 Uhr schrieb Stéphane Mottelet <[hidden email]>:

Le 08/04/2019 à 22:56, Federico Miyara a écrit :


Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

So what is your problem since you know that the order of entities is, though not natural, reproductible ? If you really need to recover a deeply hidden entity, use tags and the findobj() function.

S.


Federico


On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:


scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data
 
// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])
 
// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
   0.   0.
   1.   1.

After the second plot we get

b  =
   0.   0.5
   1.   1.5

c  =

   0.   0.
   1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.  

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.


Regards,

Federico Miyara


Libre de virus. www.avast.com

_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

 Antoine Monmayrant LAAS - CNRS
 7 avenue du Colonel Roche
 BP 54200
 31031 TOULOUSE Cedex 4
 FRANCE

 <a class="moz-txt-link-freetext" href="Tel:+33">Tel:+33 5 61 33 64 59
 
 email : [hidden email]
 permanent email : [hidden email]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: question on graphic children order

It works (after the modification in GraphicObject.java)

t=linspace(0,2*%pi,4);
plot(t,sin(t))
plot(t,cos(t),'r')
legend('sin','cos')

--> gca().children(1).children.data
 ans  =

   0.          0.      
   2.0943951   0.8660254
   4.1887902  -0.8660254
   6.2831853  -2.449D-16


--> gca().children(2).children.data
 ans  =

   0.          1.
   2.0943951  -0.5
   4.1887902  -0.5
   6.2831853   1.

i.e. the first compound is the sine. But it breaks legend() (see attached screenshot).

S.

Le 10/04/2019 à 08:47, Stéphane Mottelet a écrit :

Le 10/04/2019 à 01:24, Federico Miyara a écrit :


Antoine,

Thank you for your suggestion. It's a good one, but I still don't know the reason why the index of the current entity is 1 (my question was not really about workarounds but reasons). Stéphane said it was a stack, but as far as I could find, there is no stack structure in Scilab 6.

It was an image. The graphics objects tree is not built at the interpreter level but internally with, at the end, Java objects. In

modules/graphic_objects/src/java/org/scilab/modules/graphic_objects/graphicObject/GraphicObject.java

you can see that the set of children of a graphic object is a (Java) list

    /** Child objects list. Known by their UID */
    private List <Integer> children;

When a children is added to a graphic object, the the method "addChild" is invoked. In the source you can see

    public void addChild(Integer child) {
        children.add(0, child);
    }

Which is coherent with the actual behavior i.e. news children are pushed on the top.

What you would like is simply (without the 0)

    public void addChild(Integer child) {
        children.add(child);
    }

If I have time I can see if it breaks other things, but I am almost sure that it will...

S.




On 09/04/2019 04:22, Antoine Monmayrant wrote:
Hello,

As Stéphane said, using a tag and findobj is a possibility that I use for complex layouts.
Here is another one: build your own vector of handles that you order the way you want:

as=[];
subplot(221)
plot(1,2)
as=[as,gca()]
subplot(222)
plot(1:2,2:3)
as=[as,gca()]
subplot(223)
plot(2*[1:2],2:3)
as=[as,gca()]
subplot(224)
plot(2*[1:2],-[2:3])
as=[as,gca()]
as.foreground=color('gray');
as.background=color('lightgray');
as.thickness=2;
as.font_size=4;

Cheers,

Antoine

Le 09/04/2019 à 08:30, P M a écrit :
Federico...thanks for asking the question.
I was wondering about it myself for quite some time.
Once recognizing the fact, I just accepted that new entities are placed at the first position.
However, it might be interesting to get some insight of why it is like this....for now I guessed it has to do with how to handle memory.

Philipp 


Am Mo., 8. Apr. 2019 um 23:01 Uhr schrieb Stéphane Mottelet <[hidden email]>:

Le 08/04/2019 à 22:56, Federico Miyara a écrit :


Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

So what is your problem since you know that the order of entities is, though not natural, reproductible ? If you really need to recover a deeply hidden entity, use tags and the findobj() function.

S.


Federico


On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:

scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data
 
// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])
 
// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
   0.   0.
   1.   1.

After the second plot we get

b  =
   0.   0.5
   1.   1.5

c  =

   0.   0.
   1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.  

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.


Regards,

Federico Miyara


Libre de virus. www.avast.com

_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

 Antoine Monmayrant LAAS - CNRS
 7 avenue du Colonel Roche
 BP 54200
 31031 TOULOUSE Cedex 4
 FRANCE

 <a class="moz-txt-link-freetext" href="Tel:+33" moz-do-not-send="true">Tel:+33 5 61 33 64 59
 
 email : [hidden email]
 permanent email : [hidden email]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

Figure0.png (10K) Download Attachment
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

Re: question on graphic children order

In reply to this post by mottelet

Stéphane,

Thank you for your insight.

I think I've found a possible explanation fromthe user's point of view: If several entities are successively added and some of their properties need to be modified on the fly, it is easier to use a single instruction that affects the newly added entity instead of having to keep track of the index or the handle of each specific entity. I suppose it is more frequent to modify the most recently added object than a deeply buried one.

Regards,

Federico Miyara
   

On 10/04/2019 03:47, Stéphane Mottelet wrote:

Le 10/04/2019 à 01:24, Federico Miyara a écrit :


Antoine,

Thank you for your suggestion. It's a good one, but I still don't know the reason why the index of the current entity is 1 (my question was not really about workarounds but reasons). Stéphane said it was a stack, but as far as I could find, there is no stack structure in Scilab 6.

It was an image. The graphics objects tree is not built at the interpreter level but internally with, at the end, Java objects. In

modules/graphic_objects/src/java/org/scilab/modules/graphic_objects/graphicObject/GraphicObject.java

you can see that the set of children of a graphic object is a (Java) list

    /** Child objects list. Known by their UID */
    private List <Integer> children;

When a children is added to a graphic object, the the method "addChild" is invoked. In the source you can see

    public void addChild(Integer child) {
        children.add(0, child);
    }

Which is coherent with the actual behavior i.e. news children are pushed on the top.

What you would like is simply (without the 0)

    public void addChild(Integer child) {
        children.add(child);
    }

If I have time I can see if it breaks other things, but I am almost sure that it will...

S.




On 09/04/2019 04:22, Antoine Monmayrant wrote:
Hello,

As Stéphane said, using a tag and findobj is a possibility that I use for complex layouts.
Here is another one: build your own vector of handles that you order the way you want:

as=[];
subplot(221)
plot(1,2)
as=[as,gca()]
subplot(222)
plot(1:2,2:3)
as=[as,gca()]
subplot(223)
plot(2*[1:2],2:3)
as=[as,gca()]
subplot(224)
plot(2*[1:2],-[2:3])
as=[as,gca()]
as.foreground=color('gray');
as.background=color('lightgray');
as.thickness=2;
as.font_size=4;

Cheers,

Antoine

Le 09/04/2019 à 08:30, P M a écrit :
Federico...thanks for asking the question.
I was wondering about it myself for quite some time.
Once recognizing the fact, I just accepted that new entities are placed at the first position.
However, it might be interesting to get some insight of why it is like this....for now I guessed it has to do with how to handle memory.

Philipp 


Am Mo., 8. Apr. 2019 um 23:01 Uhr schrieb Stéphane Mottelet <[hidden email]>:

Le 08/04/2019 à 22:56, Federico Miyara a écrit :


Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

So what is your problem since you know that the order of entities is, though not natural, reproductible ? If you really need to recover a deeply hidden entity, use tags and the findobj() function.

S.


Federico


On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:


scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data
 
// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])
 
// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
   0.   0.
   1.   1.

After the second plot we get

b  =
   0.   0.5
   1.   1.5

c  =

   0.   0.
   1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.  

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.


Regards,

Federico Miyara


Libre de virus. www.avast.com

_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

 Antoine Monmayrant LAAS - CNRS
 7 avenue du Colonel Roche
 BP 54200
 31031 TOULOUSE Cedex 4
 FRANCE

 <a moz-do-not-send="true" class="moz-txt-link-freetext" href="Tel:+33">Tel:+33 5 61 33 64 59
 
 email : [hidden email]
 permanent email : [hidden email]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: question on graphic children order

Le 10/04/2019 à 18:05, Federico Miyara a écrit :

Stéphane,

Thank you for your insight.

I think I've found a possible explanation fromthe user's point of view: If several entities are successively added and some of their properties need to be modified on the fly, it is easier to use a single instruction that affects the newly added entity instead of having to keep track of the index or the handle of each specific entity. I suppose it is more frequent to modify the most recently added object than a deeply buried one.

I don't think it is the reason (if there is any true reason). It is equally easy to get the handle with
A...children($)
A...children(1)
gce()

Thanks for your persistent will to know why, for things that are actually not the most handy, even if after years we are compelled to do with them.
To have fresh observers and comenters is often interesting. To have new contributors as well.

After the first interesting Stéphane's attempt, i am also afraid that changing the order now would break a lot of code.
However, IMO it would be worthwhile to try, and see how many tests this change breaks.
Many graphical tests are interactive, that requires more manpower (because these tests have no "automatic" validation/invalidation. A human must see how graphics are rendered and say "the test passes, or fails")
But this is easy to do, and subscribers to this list could contribute.

Samuel


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

Re: question on graphic children order


Samuel,

I would like to contribute somehow, but for the moment I don't know anything about Java and very little about C or C++. I could test code if it is in a version ready to install (I don't know how to compile) and if there is some protocol or guidelines to how to perform tests.

I find more likely for me to contribute Scilab functions written using the available functions and operators, or try to improve help pages.

Regards,

Federico


On 10/04/2019 13:28, Samuel Gougeon wrote:
Le 10/04/2019 à 18:05, Federico Miyara a écrit :

Stéphane,

Thank you for your insight.

I think I've found a possible explanation fromthe user's point of view: If several entities are successively added and some of their properties need to be modified on the fly, it is easier to use a single instruction that affects the newly added entity instead of having to keep track of the index or the handle of each specific entity. I suppose it is more frequent to modify the most recently added object than a deeply buried one.

I don't think it is the reason (if there is any true reason). It is equally easy to get the handle with
A...children($)
A...children(1)
gce()

Thanks for your persistent will to know why, for things that are actually not the most handy, even if after years we are compelled to do with them.
To have fresh observers and comenters is often interesting. To have new contributors as well.

After the first interesting Stéphane's attempt, i am also afraid that changing the order now would break a lot of code.
However, IMO it would be worthwhile to try, and see how many tests this change breaks.
Many graphical tests are interactive, that requires more manpower (because these tests have no "automatic" validation/invalidation. A human must see how graphics are rendered and say "the test passes, or fails")
But this is easy to do, and subscribers to this list could contribute.

Samuel



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


Libre de virus. www.avast.com

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
amonmayr amonmayr
Reply | Threaded
Open this post in threaded view
|

Re: ?==?utf-8?q? question on graphic children order

In reply to this post by Samuel GOUGEON
Hello,

> After the first interesting Stéphane's attempt, i am also afraid that
> changing the order now would break a lot of code.

My intuition is that functions like gce() might rely on the assumption that the most recent object is to be found at the first position in the children list.
I am not sure this is going to be trivial to track all the possible weird bugs such a change could induce.
But I agree that this "stack" sorting (new things first) is quite surprising for new users¹ and that an array sorting (new things last) would be less surprising and thus easier to grasp.

Antoine
 ¹ Every new student in our group trying to  work with scilab graphic handles gets bitten at some point by the fact that a.children(1) no longer points to the first plot after a second one is added.

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users