<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Dear Stéphane,</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">This thread was on Bugzilla for more
      than 4 years, and the commit was on review for a full year.</div>
    <div class="moz-cite-prefix"><br>
      This feature is completely back-compatible. It breaks nothing.<br>
      About any "spirit" : The only one that i know -- and it has always
      been very explicit -- is to improve Scilab by all possible and
      relevant ways.<br>
      IMHO in no way considering Scilab as a museum of features coming
      from anywhere else, or even internal, as in a showcase preventing
      any forthcoming changes -- could be considered as a way for
      improving Scilab.<br>
      <br>
      The new "logflags" argument is actually badly named in the
      documentation. It must rather be seen as the initial
      implementation of a more extended "AxesSpec" argument, as 
      "LineSpec" already exists and makes plot() much more handy than
      plot2d(). Simply, to me, the priority was to transfer the plot2d()
      log feature to plot(), as a first step. Indeed, it was the only
      feature missing to plot() that somewhat made me sticking to
      plot2d().<br>
      plot() can still be improved in many ways, without breaking
      anything. Just about this axesSpec (a report should be posted),
      here are some ideas to go on designing it: <br>
    </div>
    <div class="moz-cite-prefix">
      <ul>
        <li>allowing to switch the direction of each axis, by using the
          "-" symbol</li>
        <li>allowing to set the position, by using a "r", "t", or "c"
          symbol (for Right, Top, Center)</li>
        <li>allowing to set the grid (for instance with the "_" symbol)<br>
        </li>
        <li>allowing to set the legend (for instance as last field,
          after the first @ symbol, since this one is already used in
          the legacy "leg" option)<br>
        </li>
        <li>.. for instance using "|" as axis separator (that then could
          not be used in legends)<br>
        </li>
      </ul>
      IMHO, may be it's the right time to announce the deprecation of
      plot2d() in its documentation, to make it an internal in Scilab
      6.2 or 6.3.<br>
      <p>You seem to fear other plot2d() extra  options. As you, i would
        not
        regret strf and nax ones, whose names and encoding are very
        criptic, and just impossible to remember. There were likely
        designed before graphical properties were implemented to address
        them in a detailed way.<br>
        <br>
        About plot() Global properties: <br>
        They are dedicated to polylines, not to axes. So adding any axes
        properties to them would break the idea, indeed. Yet, AFAIU
        still some polyline setting can't be tuned through LineSpec nor
        a Global property, like the curve's thickness. It's a pity. We
        could think about improving this.<br>
        On the other hand, Global Properties are less useful now than
        formerly, for 2 main reasons:</p>
      <ul>
        <li>set() is now vectorized: It now allows to set several
          properties in a single call. This is a quite recent feature
          (added in ~6.0.1). <br>
        </li>
        <li>Assigning a given property for a vectors of handles (as a
          group of polylines) has been a lot of improved in 6.0.2</li>
      </ul>
      This recent double vectorization makes complex assignements of
      (scalar or non scalar) values to vectors of polylines handles much
      easier, and in a more extensive way than only through  Global
      properties.<br>
    </div>
    <div class="moz-cite-prefix"><br>
      About any semilogx, semilogy, loglog functions:</div>
    <div class="moz-cite-prefix">When in 2D 3 functions can be simply
      replaced with 3 understandable values of a single option in an
      existing function, that just tells that they are completely
      useless.<br>
      Who would tell that in 3D we would have to create 7 separate
      functions to deal with all x/y/z log/normal possible combinations?
      So why doing it in 2D?<br>
      And why only for the log status? Then, in the same way, why not
      creating some invXplot(), invYplot(), invXYplot(), to directly
      plot inverted axes, and so, of course, invSemilogX(), etc..?<br>
      To me, all this is just meaningless.<br>
      Now, if former matlabers wish to still use their prefered former
      functions, of course adding them in an external compatibility
      toolbox is possible, as you did in plotlib.<br>
      By the way, similar functions already exist in Scilab, as
      mtlb_semilogx, mtlb_semilogy, mtlb_loglog, in the m2sci module.</div>
    <div class="moz-cite-prefix"><br>
      We can't on one hand make strong efforts to remove all existing
      duplicates or uselessly split features, and on the other one make
      strong efforts to build new ones as somewhat strange and absurd
      ones that already exist.<br>
      At least, if so, personnally i would not go on about any cleaning
      and clarifying task in Scilab.<br>
      <br>
      This is why, to me, the introduced AxesSpec feature is great,
      clear, fully enabled, and already complete for log/lin tuning at
      calling time.<br>
      While i am sorry to still not understanding your point.<br>
      <br>
      Best regards<br>
      Samuel<br>
      <br>
    </div>
    <br>
    <div class="moz-cite-prefix">Le 13/03/2020 à 11:18, Stéphane
      Mottelet a écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:87170509-31bc-99ac-904e-46b7e71b0f4d@utc.fr">Hi, <br>
      <br>
      I don't approve this commit (<a class="moz-txt-link-freetext"
        href="https://codereview.scilab.org/#/c/20879/8">https://codereview.scilab.org/#/c/20879/8</a>)
      which was merged just before the release (I didn't even have the
      time to give it a -1). It represents a complete breakdown with the
      spirit of "plot", whose help page says "plot has been rebuild to
      better handle Matlab syntax. To improve graphical compatibility,
      Matlab users should use plot (rather than plot2d)". Until now, the
      behavior of plot was customized by means of "propertyName/value"
      pairs given after the (x,y) pairs. <br>
      <br>
      With this new logflags syntax, we have an optionnal first argument
      of "value" type without its "propertyName", moreover this is a
      "value" of an Axes property. At worse, but it would not have been
      more coherent, the expected feature could have been implemented as
      a pair "log_flags",string among other "propertyName/value". <br>
      <br>
      plot() had the merit of being more user friendly that plot2d().
      With this commit, it started its convergence towards plot2d(),
      which is not a reference of user friendliness. One implicit rule
      is: when we introduce functions with Matlab's functions names and
      trying to emulate some of its features, then the Scilab function
      has to respect the subset of the Matlab API it implements and not
      mix with custom Scilab syntax. There are plenty of such functions
      in Scilab and this is a pity. We have implemented plot(), mesh(),
      surf(), light() and instead of breaking plot() to allow
      logarithmic plots it would have been simpler to emulate the
      corresponding functions in Matlab, namely, semilogx(), semilogy(),
      loglog(). So I hope that this commit will be quickly reverted in
      favor of <a class="moz-txt-link-freetext"
        href="https://codereview.scilab.org/#/c/21436/">https://codereview.scilab.org/#/c/21436/</a>,
      in order to prevent bad habits of average users who could start
      using the logflags syntax. <br>
      <br>
      S. <br>
      <br>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>