[Scilab-users] ?==?utf-8?q? xsetetch and xgetetch incompatible definitions of "frect"

[Samuel Gougeon]

Le 26/11/2016 18:06, Antoine Monmayrant a écrit :
> Le Samedi, Novembre 26, 2016 17:09 CET, Samuel Gougeon <sgougeon at free.fr> a écrit:
>   
>> Le 26/11/2016 16:14, Samuel Gougeon a écrit :
>>> Le 26/11/2016 08:52, Antoine Monmayrant a écrit :
>>> .../...
>>>> Two issues:
>>>>
>>>> 1) the help pages are missing description of most of the parameters,
>>>>
>>> Parameters description is not missing. It is just written for
>>> developers that are not users ;):
>>> Format and datatype of the parameter, that's all. No need to know what
>>> it represents. Any such need?
>>> I am jocking, but by the way most of pages are written in this way.
>>> Most of pages need a full overhaul by advanced users.
>>> As a contributor, you are welcome, most likely because you know how
>>> much time you loose because of a poor documentation, vs how much time
>>> you would save + using a good doc - contributing to write it.
>>>
>>>> 2) the two functions are apparently not using the same definition of frect:
>>>>>      plot2d();
>>>>>      [wrect,frect,logflag,arect] = xgetech():
>>>>>      xsetech(wrect, frect)// does not work for the scale part, ie frect
>>>>>         at line    65 of function xsetech ( /pathtoscilab/share/scilab/modules/graphics/macros/xsetech.sci line 79 )
>>>>>         Error : Min and Max values for one axis do not verify Min <= Max.
>>>>>      xsetech(wrect, [frect(1),frect(3),frect(2),frect(4)]) // works fine, scale un changed
>>> I don't see that, for instance using the examples. Could you please
>>> provide a clear example setting parameters with xsetech() and reading
>>> them back from xgetech(), that would not match? Thanks!
>>
>> Arg, ok, sorry for misreading your example.
>>
>> help xgetech() tells: |
>> "The rectangle [xmin, ymin, xmax, ymax] given by frect.."
>> while it actually returns [xmin xmax ymin ymax] that matches
>> gca().data_bounds
>>
>> help xsetech tells: "frect = [xmin, ymin, xmax, ymax]"
>> and that's the way it works.
>>
>> The bug was introduced in xgetech() in 2012 when xgetech() became a
>> macro instead of formerly a builtin function.
>> This shows that
>> |
>>
>>    * |xgetech() is very few used. Otherwise, the bug would have been
>>      spotted before.|
> OK, so there's a bug. Should I open a bug report or not? I don't know how it is supposed to interact with your SEP.
> I suppose I should open a bug report and point to your SEP or something like that?
>
>>    * |frect from the old xgetech() did not match gca().data_bounds. This
>>      was cryptic.|
>>    * |xsetech() does not accept gca().data_bounds as frect, but a puzzled
>>      version of it. It is a cryptic usage.|
>>
>> |So, here is a *Scilab Enhancement Proposal (SEP)*:
>> |
>>
>>    * |xgetech:|
>>        o |fix the code of xgetech.sci in order to match the old xgetech()
>>          version|
>>        o |set xgetech as obsolete, but keep its code (for back-compatibility)
>>          |
>>        o |undocument it|
>>    * xsetech:
>>        o extend subplot() to replace xsetech().
>>          Additional subplot() syntaxes to be designed. The new input
>>          formats should be the ones of the unpuzzled gca(). attributes
>>        o undocument xsetech() to make it a private internal function.
>>
>> What do you think about that?
> Not sure I understood everything here.
> I agree that a user can survive for some time without xsetech/xgetech.
> I used scilab daily since 2.6 (was it in 2001 or something like that?) and I just discovered it now.
> I agree that the naming is terrible!
> However, I kind of dislike (read I really hate) subplot.
> The defaults are just not doing the job for most of my plotting needs and I always end up piling up lines of  codes to tweak each axis created by subplot.
> I like the way you can set things like size, position and margins ahead of time with xsetech.
> With your proposal, we lose this possibility, right?
.
The purpose is to merge xsetech() features in subplot(), not to cancel them.
> ...
> Wait a bit, I re-read your SEP: you propose to add optional arguments to subplot in order to set margins and so on with subplot?
.
More than optional arguments, i propose to add new syntaxes. The purpose 
of subplot() and xsetech() is the same.
The subplot() short description presently tells:
*subplot - divide a graphics window into a matrix of sub-windows*

But this is not what subplot() actually does, but rather
*
subplot - sets a new axes as a cell of a virtual grid sharing the 
current window*

> If it's the case, I'm with you on this one.
> Still, how should we proceed?
> Should I fill a bug report on xsetech/xgetech incompatibilities and then you comment with your SEP?

If a report is just about the bug, IMO its processing will lead to the 
SEP discussion.
For my part, i wouldn't work fixing or improving anything that looks 
useless
or badly designed to me, as xsetech() and xgetech() do.
We may post a report about xsetech() and xgetech() together to propose 
and discuss
the SEP in the report's thread.

Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20161126/5762ac15/attachment.htm>