From sgougeon at free.fr Wed Jun 3 13:01:24 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 3 Jun 2020 13:01:24 +0200 Subject: [Scilab-Dev] new logflags syntax of plot() in 6.1 In-Reply-To: <87170509-31bc-99ac-904e-46b7e71b0f4d@utc.fr> References: <87170509-31bc-99ac-904e-46b7e71b0f4d@utc.fr> Message-ID: <2806888c-07ae-53bb-a612-145a1bc92068@free.fr> 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, 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) 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. 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..? 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. 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Wed Jun 3 13:31:51 2020 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 3 Jun 2020 13:31:51 +0200 Subject: [Scilab-Dev] new logflags syntax of plot() in 6.1 In-Reply-To: <2806888c-07ae-53bb-a612-145a1bc92068@free.fr> References: <87170509-31bc-99ac-904e-46b7e71b0f4d@utc.fr> <2806888c-07ae-53bb-a612-145a1bc92068@free.fr> Message-ID: <77417065-4c20-faad-0781-7c44b15c043f@utc.fr> 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: From stephane.mottelet at utc.fr Thu Jun 18 16:52:47 2020 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 18 Jun 2020 16:52:47 +0200 Subject: [Scilab-Dev] Scilab 6.1 for OSX is out ! In-Reply-To: <5346a48b-59f6-5676-b52b-00efc63e7a37@utc.fr> References: <5346a48b-59f6-5676-b52b-00efc63e7a37@utc.fr> Message-ID: <7f23459b-fd57-61ab-70d3-190b3c59b056@utc.fr> Hello, The branch-6.1 OSX build has been updated yesterday evening. To have an idea of bug fixes and other improvements since the last build see the following list on CR: https://codereview.scilab.org/#/q/status:merged+since:2020-04-20 S. Le 21/04/2020 ? 19:21, St?phane Mottelet a ?crit?: > Hi all, > > Finally I managed to package a branch-6.1 version. "branch-6.1" means > that you will have the actual features of 6.1 version plus the bug > fixes and improvements provided by the team and contributors since its > release. The archive is available to dowload at the following url: > > https://www.utc.fr/~mottelet/scilab_for_macOS.html > > Tests have been made under HighSierra, Mojave, Catalina and everything > seems OK. Please use the ML to report eventual problems. > > Enjoy ! > -- 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