[Scilab-Dev] xrpoly: drawing of many polygons of the same type

[Samuel Gougeon]

Hi Stanislav,

Le 31/03/2013 11:12, ????????? a écrit :
> 30.03.2013 08:14, Samuel Gougeon ?????:
>> This vectoriation is a good idea! I agree that implementing it in the 
>> same function
>> as for only one polygon is much preferable, w.r.t. coding a specific 
>> xrpoly*s*()
>> function as it has been done for most of other functions plotting 
>> geometrical
>> shapes : xrect > xrects, etc..
>>
> I didn't know about such division and I don't understand why it has 
> been done. If I want to plot n rectangles what  function should I use? 
> xrects? Even if n = 1?
yes, if you want to fill it with a color : 
http://help.scilab.org/docs/5.4.0/en_US/xrects.html
There is neither logic nor sense for the user, but with xrect()
you won't be able to fill it with a color as parameter.
So you should assume and use that nb>=1 allows nb=1  :-)
>> Since a SEP is running, here are some ideas of other possible 
>> developments
>> for new  features:
>> - why not *vectorizing also n, r and theta*? (with default = scalar)
> It is a good idea and it is very simple to implement.
>> - *filling = filling_color* (optional): to fill the polygon(s) with 
>> respective
>>     colors (vector of indices in the color_map).
>>     a color<0 means that the line (border) must not be plotted.
>> - *symbol=[symbol_numbers, symbol_sizes]*: to put a symbol on the angles
>>   (the same on all angles, but may be different from a polygon to 
>> another one
>>   => vectorized = mx2 matrix).
>> - *isoview=%t* option, to force the targetted axes to be isometric to 
>> show
>>    a truly regular polygonal (see the present mis-shaped sample in 
>> help xrpoly)
> I am not sure that it is a good idea. This function use the axes scale 
> and I am not sure that user want to have isometric axes. 
If a user wants to plots a regular polygon, don't you think that one 
prefer to
see it as regular ? Backward compatibility would be insured by keeping the
default isoview=%f. But i would easily bet that in existing codes, 
xrpoly(...)
commands and 90% of the time preceded or followed by something like
ax = gca(); ax.isoview = "on";
and that for 9% of the remaining 10%, it would not injure to add isoview.

> Besides, backward compatibility can be damaged. But it can be done in 
> separate function. And in one year somebody will ask: "I am newbie and 
> I didn't know about such division and I don't understand why it has 
> been done." :-)
So, finally you understand why there are xrects() after xrect(), and 
xfrect()
(yes, enabling filling deserve a totally new function, don't you think? 
:-(( ),
xarcs() after xarc(), xfarc() after xarc(), and obviously xfarcs() (no, 
it is not a joke.
just check)...
>> - *showAll=%t* option: => enlarge axes bounds up to the external 
>> bounds of
>>    generated polygons
>> - returning the *vector of created handles*
> I don't understand what "returning the *vector of created handles*" is 
> for?
to easily enable any further tuning for other attributes of the lines 
(color,
thickness), the filling color of markers, etc.
For instance, stars of the example could be made yellow. This would give :

H = xrpoly([0.5 0.5], 12, 0.4, symbol=[14, 8], filling=-color("cyan"), 
isoview=%t)
H.mark_background = color("yelow");// and for all polygons in a once



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20130331/c82d0874/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eacdjadi.png
Type: image/png
Size: 6265 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/dev/attachments/20130331/c82d0874/attachment.png>