[Scilab-users] xsetetch and xgetetch incompatible definitions of "frect"

[Samuel Gougeon]

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.|
  * |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?

Samuel

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