[Scilab-Dev] xget("fpf") xset("fpf") => gca().ticks_format(4)?
Samuel Gougeon
sgougeon at free.fr
Thu Feb 1 18:20:30 CET 2018
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/dev/attachments/20180201/8074a974/attachment.htm>
More information about the dev
mailing list