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

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       scilab-dev
Subject:    [Scilab-Dev] xget("fpf") xset("fpf") => gca().ticks_format(4)?
From:       Samuel Gougeon <sgougeon () free ! fr>
Date:       2018-02-01 17:20:30
Message-ID: 9affd59f-cd70-8bc9-0c4c-fea3dfa277ea () free ! fr
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

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

[Attachment #5 (text/html)]

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Please follow up the discussion on the devs@ list only.<br>
    <br>
    Dear devs and users,<br>
    <br>
    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.<br>
    <br>
    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() :
    <a class="moz-txt-link-freetext" \
href="https://help.scilab.org/docs/6.0.0/en_US/contour2d.html">https://help.scilab.org/docs/6.0.0/en_US/contour2d.html</a><br>
  <br>
    The gca().ticks_format property was added in Scilab 5.5.0 and is now
    available.<br>
    It is currently a vector of 3 strings being C-like formats
    specifications for the labels of the x, y, and z axes.<br>
    <br>
    So, i am wondering about the possibility to <b>replace the
      xget("fpf") and xset("fpf") with a fourth component
      gca().ticks_format(4) </b>(to be implemented).<br>
    <br>
    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.<br>
    <br>
    Since, in Scilab itself, xget("fpf") and xset("fpf") are used only
    in leveling macros, <b>another solution </b>would be to <br>
    <ul>
      <li>simply remove xget("fpf") and xset("fpf")</li>
      <li>improve xnumb() in order to make it self-adaptable in term of
        display format according to values.</li>
      <ul>
        <li>i already use and may provide such a version (as well to
          display complex numbers with their imaginary parts). A SEP may
          be prepared.<br>
        </li>
        <li>possibly add a formating option. But this is not mandatory
          if a self-adapting version is available in Scilab.<br>
        </li>
      </ul>
      <li>make contour(), contour2d() and contourf() using xnumb()
        instead of xstring(). This is trivial.<br>
        Possibly add a labelling option to them (but it's not mandatory)<br>
      </li>
    </ul>
    <p>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.</p>
    <p>I hope that Scilab will, ASAP, actually and properly get rid of
      these xget() and xset() functions.<br>
      <br>
      May this contribution help to this purpose?<br>
      <br>
      Best regards<br>
      Samuel<br>
      <br>
    </p>
  </body>
</html>

_______________________________________________
dev mailing list
dev@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev

[prev in list] [next in list] [prev in thread] [next in thread] 