The gca().ticks_format property was added in Scilab 5.5.0 and is now
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.
i already use and may provide such a version (as well to
display complex numbers with their imaginary parts). A SEP may
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.