[Scilab-Dev] new logflags syntax of plot() in 6.1

Wed Jun 3 13:31:51 CEST 2020

Hi,

Le 03/06/2020 à 13:01, Samuel Gougeon a écrit :
> Dear Stéphane,
>
> This thread was on Bugzilla for more than 4 years, and the commit was 
> on review for a full year.
>
> This feature is completely back-compatible. It breaks nothing.
> 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.
> 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.
>
> 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,
That's where we definitively do not agree. To me, specification of Axes 
properties should not be given as _explicit_ arguments to plot(), which 
accepts polyline properties.
> 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().
> 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:
>
>   * allowing to switch the direction of each axis, by using the "-" symbol
>   * allowing to set the position, by using a "r", "t", or "c" symbol
>     (for Right, Top, Center)
>   * allowing to set the grid (for instance with the "_" symbol)
>   * 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)
>   * .. for instance using "|" as axis separator (that then could not
>     be used in legends)
>
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...


>  *
>
>
>
> 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.
>
> 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.
>
> About plot() Global properties:
> 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.
>
Yes.
>
> On the other hand, Global Properties are less useful now than 
> formerly, for 2 main reasons:
>
>   * 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).
>   * Assigning a given property for a vectors of handles (as a group of
>     polylines) has been a lot of improved in 6.0.2
>
> 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.
>
> About any semilogx, semilogy, loglog functions:
> 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.
> 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?
> 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..?
Haha, I like your sense of humor...
> To me, all this is just meaningless.
> 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.
> By the way, similar functions already exist in Scilab, as 
> mtlb_semilogx, mtlb_semilogy, mtlb_loglog, in the m2sci module.
>
> 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.
> At least, if so, personnally i would not go on about any cleaning and 
> clarifying task in Scilab.
>
> This is why, to me, the introduced AxesSpec feature is great, clear, 
> fully enabled, and already complete for log/lin tuning at calling time.
> While i am sorry to still not understanding your point.

So do I...

S.

>
> Best regards
> Samuel
>
>
> Le 13/03/2020 à 11:18, Stéphane Mottelet a écrit :
>> Hi,
>>
>> I don't approve this commit 
>> (https://codereview.scilab.org/#/c/20879/8) 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.
>>
>> 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".
>>
>> 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 
>> https://codereview.scilab.org/#/c/21436/, in order to prevent bad 
>> habits of average users who could start using the logflags syntax.
>>
>> S.
>>
>
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev

-- 
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
http://www.utc.fr/~mottelet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20200603/65e3359d/attachment.htm>