[Scilab-users] xget("fpf") xset("fpf") => gca().ticks_format(4)?

[Samuel Gougeon]

Please follow up the discussion on the devs@ list only.

Dear devs and users,

xset() and xget() are obsolete since Scilab 5.0. Yet, they still remain 
in Scilab 6.0 due to the xget("fpf") and xset("fpf") syntaxes that still 
have no replacement.

These syntaxes respectively gets and sets the floating point C-like 
format of numbers to be labeled on level curves, as rendered by 
xstring() within contouring functions like contour2d() : 
https://help.scilab.org/docs/6.0.0/en_US/contour2d.html

The gca().ticks_format property was added in Scilab 5.5.0 and is now 
available.
It is currently a vector of 3 strings being C-like formats 
specifications for the labels of the x, y, and z axes.

So, i am wondering about the possibility to *replace the xget("fpf") and 
xset("fpf") with a fourth component gca().ticks_format(4) *(to be 
implemented).

Levels are (always?) about z, so in one hand it could be useless to 
implement .ticks_format(4) instead of using .ticks_format(3) that is 
already available. In another hand, the special value " " (blank) is 
presently used in contouring functions to cancel labeling, without 
canceling labels on the Z axis when contours are drawn in a 3D plot 
instead of a flat one.

Since, in Scilab itself, xget("fpf") and xset("fpf") are used only in 
leveling macros, *another solution *would be to

  * simply remove xget("fpf") and xset("fpf")
  * improve xnumb() in order to make it self-adaptable in term of
    display format according to values.
      o i already use and may provide such a version (as well to display
        complex numbers with their imaginary parts). A SEP may be prepared.
      o possibly add a formating option. But this is not mandatory if a
        self-adapting version is available in Scilab.
  * make contour(), contour2d() and contourf() using xnumb() instead of
    xstring(). This is trivial.
    Possibly add a labelling option to them (but it's not mandatory)

As a side question, adding a C-like format option to xstring() would be 
useful as well. The xstring() code already gets such a format from 
xget("fpf"). It would then be provided as a direct input, instead of 
from this former environmental variable.

I hope that Scilab will, ASAP, actually and properly get rid of these 
xget() and xset() functions.

May this contribution help to this purpose?

Best regards
Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20180201/8074a974/attachment.htm>