xget("fpf") xset("fpf") => gca().ticks_format(4)?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

xget("fpf") xset("fpf") => gca().ticks_format(4)?

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.
    • i already use and may provide such a version (as well to display complex numbers with their imaginary parts). A SEP may be prepared.
    • 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

dev mailing list
[hidden email]