[Scilab-users] question on graphic children order

Federico Miyara fmiyara at fceia.unr.edu.ar
Wed Apr 10 01:24:39 CEST 2019


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.mottelet at utc.fr <mailto:stephane.mottelet at 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 at lists.scilab.org <mailto:users at 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 at lists.scilab.org <mailto:users at 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 at lists.scilab.org <mailto:users at lists.scilab.org>
>>>     https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
>>     _______________________________________________
>>     users mailing list
>>     users at lists.scilab.org <mailto:users at lists.scilab.org>
>>     http://lists.scilab.org/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> users mailing list
>> users at 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.monmayrant at laas.fr
>   permanent email :antoine.monmayrant at polytechnique.org
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
> _______________________________________________
> users mailing list
> users at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20190409/3c404dc3/attachment.htm>


More information about the users mailing list