<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<div class="moz-cite-prefix">Le 03/06/2020 à 13:01, Samuel Gougeon a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:2806888c-07ae-53bb-a612-145a1bc92068@free.fr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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, </div>
</blockquote>
That's where we definitively do not agree. To me, specification of
Axes properties should not be given as <u>explicit</u> arguments to
plot(), which accepts polyline properties.<br>
<blockquote type="cite"
cite="mid:2806888c-07ae-53bb-a612-145a1bc92068@free.fr">
<div class="moz-cite-prefix">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>
</div>
</blockquote>
<p>Sorry, but using a complicated multi-character string would be a
regression compared to setting correctly documented properties of
Axes (before or afterwards). The time where we could only use one
(complicated) string to speficity many stuff has gone...<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:2806888c-07ae-53bb-a612-145a1bc92068@free.fr">
<div class="moz-cite-prefix">
<ul>
<li> <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>
</p>
</div>
</blockquote>
Yes.<br>
<blockquote type="cite"
cite="mid:2806888c-07ae-53bb-a612-145a1bc92068@free.fr">
<div class="moz-cite-prefix">
<p> 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>
</div>
</blockquote>
Haha, I like your sense of humor...<br>
<blockquote type="cite"
cite="mid:2806888c-07ae-53bb-a612-145a1bc92068@free.fr">
<div class="moz-cite-prefix"> 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>
</div>
</blockquote>
<p>So do I...</p>
<p>S.<br>
</p>
<blockquote type="cite"
cite="mid:2806888c-07ae-53bb-a612-145a1bc92068@free.fr">
<div class="moz-cite-prefix"> <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://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/#/c/20879/8"
moz-do-not-send="true">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://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/#/c/21436/"
moz-do-not-send="true">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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.scilab.org">dev@lists.scilab.org</a>
<a class="moz-txt-link-freetext" href="https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev">https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
<a class="moz-txt-link-freetext" href="http://www.utc.fr/~mottelet">http://www.utc.fr/~mottelet</a>
</pre>
</body>
</html>