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
<stephane.motte...@utc.fr <mailto:stephane.motte...@utc.fr>>:
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 list
users@lists.scilab.org <mailto:users@lists.scilab.org>
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 list
users@lists.scilab.org <mailto:users@lists.scilab.org>
http://lists.scilab.org/mailman/listinfo/users
<https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users>
_______________________________________________
users mailing list
users@lists.scilab.org <mailto:users@lists.scilab.org>
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@lists.scilab.org <mailto:users@lists.scilab.org>
http://lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@lists.scilab.org
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 :antoine.monmayr...@laas.fr
permanent email :antoine.monmayr...@polytechnique.org
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
---
El software de antivirus Avast ha analizado este correo electrónico en busca de
virus.
https://www.avast.com/antivirus
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
