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 < [email protected]>: > 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 > > > > <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > Libre > de virus. www.avast.com > <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > <#m_-570024488477070350_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > _______________________________________________ > users mailing > [email protected]https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users > > <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users> > > > > _______________________________________________ > users mailing > [email protected]http://lists.scilab.org/mailman/listinfo/users > <https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users> > > > > _______________________________________________ > users mailing > [email protected]https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > [email protected] > http://lists.scilab.org/mailman/listinfo/users >
_______________________________________________ users mailing list [email protected] http://lists.scilab.org/mailman/listinfo/users
