[Scilab-users] xpoly()

[Calixte Denizet]

Hi Stefan,

We fixed the bug 8656 because we estimated that fixing it would make the 
user's job easier.
I read the doc about auto_scale and actually this property is only for 
"high-level" functions, as a compromise I propose to you to extend it to 
"low-level" functions.
So if auto_scale is "off" then the xfoo functions won't change axe_bounds.
By default auto_scale will stay at "on" (because we think that the most 
of the users expect that !)

What's your opinion ?

Regards

Calixte


On 03/12/2014 21:01, Stefan Du Rietz wrote:
> On 2014-11-20 23:58, Samuel Gougeon wrote:
>> Hello,
>>
>> Le 19/11/2014 18:39, Stefan Du Rietz a écrit :
>>> Hello,
>>>
>>> I have made quite an effort to write commands in numerous sci-files
>>> with the low level function xpoly() to avoid changes to the axes.
>>>
>>> But (surprise, surprise!),
>>
>> The fix of the bug 8956  has been announced in the Release Notes of
>> Scilab 5.5.0 :
>> #8956 - xpoly, xfpoly, xrect, xsegs and xarc did not update
>> data_bounds property.
>> http://bugzilla.scilab.org/8956
>> See also http://bugzilla.scilab.org/13365, fixed in 5.5.1
>
> But if you consider it a new bug, you will not read about fixes ...
>
>> The new behavior has been reported as a buggy one at
>> http://bugzilla.scilab.org/show_bug.cgi?id=13643
>> But as written in comment of that report, I fully agree with the #8656
>> reporter (and duplicates ones):
>> The former behavior was very bad, while from the new one, it is
>> trivial to get the former behavior.
>>
>> As Antoine has written it, if you want to keep the data bounds
>> unchanged, from Scilab  5.5.1 you just have to save the initial bounds
>> (no need to copy and save the full axes!) and finally restore them:
>> ax = gca();
>> DBold = ax.data_bounds;
>> // Then here plot tens, hundred or thousands xpoly(), xfpolys(),
>> xarcs(), xsegs(), etc...
>> // Finally, restore the entering bounds;
>> ax.data_bounds = DBold;
>> // and that's it!
>>
>> Whereas with the former behavior, updating data bounds with an
>> external script was impossible.
>> Reasons are somewhat detailled here:
>> http://bugzilla.scilab.org/show_bug.cgi?id=13643#c2
>>
>> This is why this fix and the new behavior should rather be considered
>> as a big improvement, since there is no specific  Scilab function
>> dedicated to bounds recalculation.
>> Unfortunately, replot() does not do that :
>> http://help.scilab.org/docs/5.5.1/en_US/replot.html
>>
>> By the way, when one plots something, it looks quite expected to be
>> able to see the plotted object. It was often not the case for
>> geometrical shapes with the former behavior of xpoly() and of other
>> comparable plotting functions, with no way to compute relevant data
>> bounds.
>>
>> Regards
>> Samuel
>>
> Hello Samuel,
> thank you for your comprehensive reply, which I have now investigated.
>
> Yet, I cannot agree with you.
>
> Do you really consider it logical that a built-in low level line 
> function (xpoly) should change a superior entity (axes) when there 
> already is a built-in plot function (plot2d) for that?
>
> And that you can prevent (with a.auto_scale = "off") the plot function 
> but not the line function to change the axes???
>
> Furthermore, if you want to draw "thousands" of lines with xpoly(), it 
> must take some time to recalculate the data_bounds every time!
>
> "when one plots something" and wants "to be able to see the plotted 
> object" one can use plot2d ...
>
> If I use a low level line function, it is because I know what I am 
> doing and don't want anything to interfere with it!
>
> So I will add my comments to the bug report 13643. This behaviour is 
> absurd.
>
> Regards
> Stefan
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users


-- 
Calixte Denizet
Software Development Engineer
-----------------------------------------------------------
Scilab Enterprises
143bis rue Yves Le Coz - 78000 Versailles, France
http://www.scilab-enterprises.com