From chijikem at yahoo.com Mon Dec 2 01:04:20 2019 From: chijikem at yahoo.com (CO Ajike) Date: Mon, 02 Dec 2019 01:04:20 +0100 Subject: [Scilab-users] Question References: Message-ID: An HTML attachment was scrubbed... URL: From chinluh.tan at bytecode-asia.com Mon Dec 2 06:43:50 2019 From: chinluh.tan at bytecode-asia.com (Chin Luh Tan) Date: Mon, 02 Dec 2019 13:43:50 +0800 Subject: [Scilab-users] Run Scilab 6.0.2 on OSX Catalina In-Reply-To: <16eb2ef1712.b577de6e463425.5736602650988100689@bytecode-asia.com> References: <16eb2cb9944.11303947c566541.4807756935658977747@bytecode-asia.com> <72f50fae-3ae1-c312-3884-52c6f5b3b12c@utc.fr> <16eb2ef1712.b577de6e463425.5736602650988100689@bytecode-asia.com> Message-ID: <16ec522ecce.dd8daa29158650.2819253852798780009@bytecode-asia.com> Hi Stephane,? Just to add-on, this script also works on previous version of MacOS, tested for High Sierra, it make Scilab works with latest version of Java. On top of that, I notice that it also fix the issue of the hdf5 dependency for the IPCV module, do you have the summary on what the fixes implemented? Thanks for the nice patch! rgds, CL ---- On Fri, 29 Nov 2019 00:54:03 +0800 Chin Luh Tan wrote ---- Hi,? Java SE 13.0.1 Thanks Rgds, CL ---- On Fri, 29 Nov 2019 00:52:15 +0800 mailto:stephane.mottelet at utc.fr wrote ---- _______________________________________________ users mailing list users at lists.scilab.org http://lists.scilab.org/mailman/listinfo/users Le 28/11/2019 ? 17:15, Chin Luh Tan a ?crit?: Hi Stephane,? I tested the latest jdk what is the version ? from the web, with your patch, it works! Thanks. rgds, CL ---- On Thu, 28 Nov 2019 23:27:09 +0800 St?phane Mottelet mailto:stephane.mottelet at utc.fr wrote ---- Sorry, there was a typo error (wrong tilda) in the URL, the valid one is S. Le 28/11/2019 ? 10:51, St?phane Mottelet a ?crit?: > Hello, > > I have prepared a small Applescript application? enabling the current > JDK to run Scilab on OSX Catalina at the url > > https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.utc.fr/?mottelet/java/enableJDK.dmg > > > This application automates the fix we already discussed in this ML. If > I summarize the necessary steps to run Scilab under Catalina, you have > to: > > 1-download and install a JDK (not a JRE), e.g. > https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html > (more recent versions should also work, tests are welcome...) > > 2-download and run the enableJDK script (you will have to allow its > execution in system preferencences) > > The fix provided by enableJDK is neither specific to Scilab nor > specific to OSX Catalina. It will allow any application using Java > thru JNI to run with your current JDK, without having to use the Apple > legacy/obsolete Java 6 > (https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/support.apple.com/kb/dl1572). > > 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 https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.utc.fr/~mottelet _______________________________________________ users mailing list mailto:users at lists.scilab.org https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users _______________________________________________ users mailing list mailto:users at lists.scilab.org https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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 _______________________________________________ users mailing list mailto:users at lists.scilab.org http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From fujimoto2005 at gmail.com Mon Dec 2 09:29:49 2019 From: fujimoto2005 at gmail.com (fujimoto2005) Date: Mon, 2 Dec 2019 01:29:49 -0700 (MST) Subject: [Scilab-users] Stopping at the line generating warning Message-ID: <1575275389920-0.post@n3.nabble.com> During a loop, I have the following warning. "operation +: Warning adding a matrix with the empty matrix will give an empty matrix result." The loop continues and eventually fails. Since I use operation + in many places, it is difficult to find out which line is the cause of the warning. Is it possible to stop at the line that generated the warning and display that line number? Beat regards, Masahiro Fujimoto -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From sgougeon at free.fr Mon Dec 2 12:50:49 2019 From: sgougeon at free.fr (sgougeon at free.fr) Date: Mon, 2 Dec 2019 12:50:49 +0100 (CET) Subject: [Scilab-users] =?utf-8?q?Re=C2=A0=3A__Stopping_at_the_line_genera?= =?utf-8?q?ting_warning?= In-Reply-To: <1575275389920-0.post@n3.nabble.com> Message-ID: <1287647594.1813523614.1575287449685.JavaMail.root@zimbra75-e12.priv.proxad.net> Hello, Yes, with --> warning stop Regards From fujimoto2005 at gmail.com Mon Dec 2 16:10:23 2019 From: fujimoto2005 at gmail.com (fujimoto2005) Date: Mon, 2 Dec 2019 08:10:23 -0700 (MST) Subject: [Scilab-users] =?utf-8?q?Re=C2=A0=3A__Stopping_at_the_line_genera?= =?utf-8?q?ting_warning?= In-Reply-To: <1287647594.1813523614.1575287449685.JavaMail.root@zimbra75-e12.priv.proxad.net> References: <1575275389920-0.post@n3.nabble.com> <1287647594.1813523614.1575287449685.JavaMail.root@zimbra75-e12.priv.proxad.net> Message-ID: <1575299423805-0.post@n3.nabble.com> Dear Samuel I could identify the line causing the problem. Thak you? -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From stephane.mottelet at utc.fr Tue Dec 3 11:36:59 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 3 Dec 2019 11:36:59 +0100 Subject: [Scilab-users] ?= GUI hel In-Reply-To: References: <67529b3e-821f-35ba-6456-d2ef770dba4b@gmail.com> <12333f6b-d618-28f4-587f-e3d628379de3@utc.fr> Message-ID: <6fa0df3c-e3a7-2734-4794-d492b67f6524@utc.fr> Le 30/11/2019 ? 11:30, Samuel Gougeon a ?crit?: > Le 29/11/2019 ? 21:53, St?phane Mottelet a ?crit?: >> Le 29/11/2019 ? 21:21, Claus Futtrup a ?crit?: >> >>> Hi St?phane >>> >>> Lazy = not pretty. >> >> Matlab users do not have this possibility, and as a result, programs >> do not suffer from eventual border effects. > > So why do they use "clear" at the beginning of every script? This is > like a Matlab signature. > In Scilab, i never use clear (all), and it works. Neither do I. But I see the same behavior in Scilab programs of users around me and very often in Scilab programs posted by users in the ML, and precisely due to the potential border effect of lazy global variables. The sydrom is: "I don't understand why my program worked before I quit and relaunched Scilab ?" Concerning this habit of Matlab users, I have a different theory : until recently, it was tedious to use functions in order to give a decent structure to Matlab programs because each function had to reside in one single .m file. Then may users took the habit to write very long scripts hence with variables living in the main workspace. Then a "clear" at the begining of this kind of script was at least prophylatic, not to say a must ! > >> But I know many Matlab users using a bunch of "global" statements. >> This is WORSE than lazy globals... > > Agreed, and IMO less handy. > > Samuel > > > > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users > -- 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 From p.muehlmann at gmail.com Tue Dec 3 13:14:29 2019 From: p.muehlmann at gmail.com (P M) Date: Tue, 3 Dec 2019 13:14:29 +0100 Subject: [Scilab-users] ?= GUI hel In-Reply-To: <6fa0df3c-e3a7-2734-4794-d492b67f6524@utc.fr> References: <67529b3e-821f-35ba-6456-d2ef770dba4b@gmail.com> <12333f6b-d618-28f4-587f-e3d628379de3@utc.fr> <6fa0df3c-e3a7-2734-4794-d492b67f6524@utc.fr> Message-ID: > > So why do they use "clear" at the beginning of every script? This is > like a Matlab signature. > I am no matlabber, but like to start my scripts with: clc() clear("all") delete("all") // in older days also: stacksize("max") At least so long, as I am working on a script. Pressing F5 for restating the script just ensures, that I always start from new without the danger of keeping old variables/figure etc Maybe this is some kind of lazyness...I would say: convenience :-) cheers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.monmayrant at laas.fr Tue Dec 3 13:43:47 2019 From: antoine.monmayrant at laas.fr (Antoine Monmayrant) Date: Tue, 3 Dec 2019 13:43:47 +0100 Subject: [Scilab-users] ?= GUI hel In-Reply-To: References: <67529b3e-821f-35ba-6456-d2ef770dba4b@gmail.com> <12333f6b-d618-28f4-587f-e3d628379de3@utc.fr> <6fa0df3c-e3a7-2734-4794-d492b67f6524@utc.fr> Message-ID: <45852dc3-2602-8f62-ffea-c515d393c61d@laas.fr> Le 03/12/2019 ? 13:14, P M a ?crit?: > > > So why do they use "clear" at the beginning of every script? > This is like a Matlab signature. > > > I am no matlabber, but like to start my scripts with: > > clc() > clear("all") > delete("all") > // in older days also: stacksize("max") > > At least so long, as I am working on a script. > Pressing F5 for restating the script just ensures, that I always start > from new without the danger of keeping old variables/figure etc You forgot the xdel(winsid()) to get rid of all the opened windows... ;-) > > Maybe this is some kind of lazyness...I would say: convenience :-) > > cheers. > > > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Tue Dec 3 15:19:20 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Tue, 3 Dec 2019 11:19:20 -0300 Subject: [Scilab-users] question on mlists Message-ID: <64d5d75b-cd71-ecc9-a603-a842be059f5c@fceia.unr.edu.ar> Dear all, The mlist object is called matrix-oriented typed list. Does anybody have a good explanation why "_matrix_- oriented"? Thanks! Regards, Federico Miyara -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Tue Dec 3 15:20:08 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 3 Dec 2019 15:20:08 +0100 Subject: [Scilab-users] ?= GUI hel In-Reply-To: <63fc-5de10100-d-68dc398@147029288> References: <63fc-5de10100-d-68dc398@147029288> Message-ID: Sorry Antoine but I have completely lost the thread. Please give us an example of what (still) does not work for you. S. Le 29/11/2019 ? 12:28, Antoine Monmayrant a ?crit?: >> get() and set() can now use a tagsPath, that might be less ambiguate >> than using findobj(), that returns the first component with a matching >> tag (unless only unique tags are defined). The documentation of set() is >> being overhauled . You >> may have a look to it there >> . The same work on >> the get()'s page is pending >> . > I tried to use your syntax in a callback and it does not work. > The values returned are not the same than when using findobj and the old syntax (I always get the initial value for the uicontrol, not the updated ones). > I'll try to get a minimal working example... > > Antoine > > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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 From antoine.monmayrant at laas.fr Tue Dec 3 16:13:58 2019 From: antoine.monmayrant at laas.fr (Antoine Monmayrant) Date: Tue, 3 Dec 2019 16:13:58 +0100 Subject: [Scilab-users] ?= GUI hel In-Reply-To: References: <63fc-5de10100-d-68dc398@147029288> Message-ID: <63967dca-13f9-1d69-0311-f2aaf93f7096@laas.fr> Le 03/12/2019 ? 15:20, St?phane Mottelet a ?crit?: > Sorry Antoine but I have completely lost the thread. Please give us an > example of what (still) does not work for you. Ah, sorry for the noise. I don't know why your syntax was not working, but it clearly was not working. I saw a bunch of java related issues on command line so I restarted scilab and boom, both syntax where working perfectly. I have no idea what happened and how to reproduce it. See below the example GUI I built using the new get/set syntax. I think an example showing the full power of tagPath to distinguish two uicontrols with same tag but different parents (with different tags) could be useful too. Antoine ////////////////////////////////////////// f=figure(); f.tag="myfig"; /* ---------------- First number from slider ----------------? */ //values nmin=-5; nmax=10; nini=7; nsmallstep=1; nsbigstep=2; //slider position and size x=10; y=20; w=100; h=25; //slider uicontrol creation in figure f hslider=uicontrol(f, ... ??? "style", "slider", ... ??? "tag", "slider1", ... ??? "backgroundcolor", [1 1 1], ... ??? "position", [x y w h], ... ??? "value", nini, ... ??? "min", nmin, ... ??? "max", nmax, ... ??? "sliderstep", [nsmallstep, nsbigstep], ... ??? "callback", "update_values"); /* ------------- Second number from an editable text -------------? */ // initial value editini="3.14"; //edit position and size x2=x; y2=y+h+5; w2=w; h2=h; //edit uicontrol creation in figure f hedit=uicontrol(f, ... ??? "style", "edit", ... ??? "tag", "edit2", ... ??? "backgroundcolor", [1 1 1], ... ??? "position", [x2 y2 w2 h2], ... ??? "string", editini, ... ??? "callback", "update_values"); /* ------------- Sum displayed in a text uicontrol ------------- */ // initial value textini="Nothing" //edit position and size x3=x+w+5; y3=y; w3=w; h3=2*h+5; //slider uicontrol creation htext=uicontrol(f, ... ??? "style", "text", ... ??? "tag", "text3", ... ??? "backgroundcolor", [1 1 1], ... ??? "position", [x3 y3 w3 h3], ... ??? "string", textini); /* -------- callback function for slider and edit uicontrols --------? */ //Whenever user interacts with the slider or the edit uicontrols //? show the sum of both numbers in the text field function update_values() ??? //temporarily deactivate the callback (don't want callback calls to stack up while processing the current one ??? set(gcbo,"callback_type",-1); ??? /* ????? Using the unique tag chosen at the creation time of the uicontrols ????? to set/get the uicontrol properties ??? */ ??? //get both numbers from the slider and the edit uicontrols ??? number1=get("slider1", "value"); ??? string2=get("edit2", "string"); ??? //alternative syntax using the full tagpath ie "tagOfParent/tag" to avoid confusion //??? number1=get("myfig/slider1", "value"); //??? string2=get("myfig/edit2", "string"); ??? //do your maths & conversion ??? string3=string(number1+evstr(string2)); ??? //change the string displayed in the text uicontrol ??? set("text3", "string", string3); ??? //reactivate callback ??? set(gcbo,"callback_type",0); endfunction ////////////////////////////////////////// > > S. > > Le 29/11/2019 ? 12:28, Antoine Monmayrant a ?crit?: >>> get() and set() can now use a tagsPath, that might be less ambiguate >>> than using findobj(), that returns the first component with a matching >>> tag (unless only unique tags are defined). The documentation of >>> set() is >>> being overhauled >>> . >>> You >>> may have a look to it there >>> . >>> The same work on >>> the get()'s page is pending >>> . >>> >> I tried to use your syntax in a callback and it does not work. >> The values returned are not the same than when using findobj and the >> old syntax (I always get the initial value for the uicontrol, not the >> updated ones). >> I'll try to get a minimal working example... >> >> Antoine >> >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users >> > From stephane.mottelet at utc.fr Tue Dec 3 16:53:48 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 3 Dec 2019 16:53:48 +0100 Subject: [Scilab-users] Run Scilab 6.0.2 on OSX Catalina In-Reply-To: <16ec522ecce.dd8daa29158650.2819253852798780009@bytecode-asia.com> References: <16eb2cb9944.11303947c566541.4807756935658977747@bytecode-asia.com> <72f50fae-3ae1-c312-3884-52c6f5b3b12c@utc.fr> <16eb2ef1712.b577de6e463425.5736602650988100689@bytecode-asia.com> <16ec522ecce.dd8daa29158650.2819253852798780009@bytecode-asia.com> Message-ID: <036fa4ce-8f72-3a01-e9b8-6e2db0627706@utc.fr> Hello, In fact the enableJDK script is needed if the JDK is of Oracle brand. If you install a JDK from OpenJDK, e.g. https://adoptopenjdk.net/ the JNI and BundleApp entries are already present in the Info.plist, and the script is useless. Le 02/12/2019 ? 06:43, Chin Luh Tan a ?crit?: > Hi Stephane, > > Just to add-on, this script also works on previous version of MacOS, > tested for High Sierra, it make Scilab works with latest version of > Java. On top of that, I notice that it also fix the issue of the hdf5 > dependency for the IPCV module, do you have the summary on what the > fixes implemented? > hdf5 stuff is completely independent from Java, so I don't understand why. > Thanks for the nice patch! > > rgds, > CL > > > ---- On Fri, 29 Nov 2019 00:54:03 +0800 *Chin Luh Tan > * wrote ---- > > > Hi, > > Java SE 13.0.1 > > > Thanks > > Rgds, > CL > > ---- On Fri, 29 Nov 2019 00:52:15 +0800*stephane.mottelet at utc.fr > * wrote ---- > > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > > > Le 28/11/2019 ? 17:15, Chin Luh Tan a ?crit?: > > Hi Stephane, > > I tested the latest jdk > > what is the version ? > > from the web, with your patch, it works! > > Thanks. > > rgds, > CL > > > ---- On Thu, 28 Nov 2019 23:27:09 +0800 *St?phane Mottelet > > * wrote ---- > > Sorry, there was a typo error (wrong tilda) in the > URL, the valid one is > > https:/www.utc.fr/~mottelet/java/enableJDK.dmg > > S. > > Le 28/11/2019 ? 10:51, St?phane Mottelet a ?crit?: > > Hello, > > > > I have prepared a small Applescript application? > enabling the current > > JDK to run Scilab on OSX Catalina at the url > > > > > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.utc.fr/ > ?mottelet/java/enableJDK.dmg > > > > > > > This application automates the fix we already > discussed in this ML. If > > I summarize the necessary steps to run Scilab under > Catalina, you have > > to: > > > > 1-download and install a JDK (not a JRE), e.g. > > > https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html > > > > (more recent versions should also work, tests are > welcome...) > > > > 2-download and run the enableJDK script (you will > have to allow its > > execution in system preferencences) > > > > The fix provided by enableJDK is neither specific to > Scilab nor > > specific to OSX Catalina. It will allow any > application using Java > > thru JNI to run with your current JDK, without > having to use the Apple > > legacy/obsolete Java 6 > > > (https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/support.apple.com/kb/dl1572 > ). > > > > 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 > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > > > > > > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users > > -- > 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 > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > > > > > > > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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 fmiyara at fceia.unr.edu.ar Wed Dec 4 02:07:17 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Tue, 3 Dec 2019 22:07:17 -0300 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> Message-ID: Dear all, Regarding the question I've sent a few days earlier (see below), I think the Variable Browser in some cases may be creating confusion between variable types and number formats For instance, a = 1.22 creates a variable of type "constant", while its format is "double". Regards, Federico Miyara On 29/11/2019 02:57, Federico Miyara wrote: > > Dear all, > > I'm trying to elucidate some details regarding types. The most basic > type, corresponding to real or complex decimal numbers (or vectors, > matrices and hypermatrices with this kind of components) is called > "constant" by the function typeof (and so listed in the documentation). > > However, the variable browser lists them as "double". > > This is somewhat confusing. It seems that "double" refers to the way > each individual component is encoded while constant may refer to the > fact that any array containing doubles is o type constant. > > In the case of integers, for instance we have int64 as reported by > typeof, but in the Variable Browser it is listed a bit more in full as > "Integer 64". While this is also slightly inconsistent, it is not to > complain very much about. > > In the case of rationals, typeof returns "rational" while the Variable > Browser callsit "r (Tlist)" > > Cell array type is called "ce" by typeof but "Cell" in the Variabe Browser > > User-defined types in tlists and mlists are designed by the > user-defined type name by typeof, while the variable browser adds > "(Tlist)" or "(Mlist)" > > Functions, libraries and impliit lists such as $ are not listed in the > variable bowser but are correctly reported by typeof > > I wonder whether there is a reason for all this or it is actually an > issue that could be fixed in a future versions. > > Thank you > > Regards, > > Federico Miyara > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Wed Dec 4 13:30:54 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 4 Dec 2019 13:30:54 +0100 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> Message-ID: <385922a8-4e29-8981-4aaa-bb1f13c34f23@utc.fr> Hello, The name "constant" has been kept to ensure backwards compatibililty. But frankly, sometimes legacy really sucks ! To me, "constant" should be replaced everywhere by "double" to suppress this confusion. The argument that it would break some toolboxes does not hold : we already will have to recompile almost all binary gateways for the next release of Scilab. I don't understand why toolboxes authors would not be able to release a new version by just doing an easy find/replace in their codes. S. Le 04/12/2019 ? 02:07, Federico Miyara a ?crit?: > > Dear all, > > Regarding the question I've sent a few days earlier (see below), I > think the Variable Browser in some cases may be creating confusion > between variable types and number formats > > For instance, > > a = 1.22 > > creates a variable of type "constant", while its format is "double". > > Regards, > > Federico Miyara > > > On 29/11/2019 02:57, Federico Miyara wrote: >> >> Dear all, >> >> I'm trying to elucidate some details regarding types. The most basic >> type, corresponding to real or complex decimal numbers (or vectors, >> matrices and hypermatrices with this kind of components) is called >> "constant" by the function typeof (and so listed in the documentation). >> >> However, the variable browser lists them as "double". >> >> This is somewhat confusing. It seems that "double" refers to the way >> each individual component is encoded while constant may refer to the >> fact that any array containing doubles is o type constant. >> >> In the case of integers, for instance we have int64 as reported by >> typeof, but in the Variable Browser it is listed a bit more in full >> as "Integer 64". While this is also slightly inconsistent, it is not >> to complain very much about. >> >> In the case of rationals, typeof returns "rational" while the >> Variable Browser callsit "r (Tlist)" >> >> Cell array type is called "ce" by typeof but "Cell" in the Variabe >> Browser >> >> User-defined types in tlists and mlists are designed by the >> user-defined type name by typeof, while the variable browser adds >> "(Tlist)" or "(Mlist)" >> >> Functions, libraries and impliit lists such as $ are not listed in >> the variable bowser but are correctly reported by typeof >> >> I wonder whether there is a reason for all this or it is actually an >> issue that could be fixed in a future versions. >> >> Thank you >> >> Regards, >> >> Federico Miyara >> > > > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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 chinluh.tan at bytecode-asia.com Wed Dec 4 14:07:36 2019 From: chinluh.tan at bytecode-asia.com (Chin Luh Tan) Date: Wed, 04 Dec 2019 21:07:36 +0800 Subject: [Scilab-users] Run Scilab 6.0.2 on OSX Catalina In-Reply-To: <036fa4ce-8f72-3a01-e9b8-6e2db0627706@utc.fr> References: <16eb2cb9944.11303947c566541.4807756935658977747@bytecode-asia.com> <72f50fae-3ae1-c312-3884-52c6f5b3b12c@utc.fr> <16eb2ef1712.b577de6e463425.5736602650988100689@bytecode-asia.com> <16ec522ecce.dd8daa29158650.2819253852798780009@bytecode-asia.com> <036fa4ce-8f72-3a01-e9b8-6e2db0627706@utc.fr> Message-ID: <16ed105ec64.d70b0f35225098.5128317045485743528@bytecode-asia.com> Hi Stephane,? For Java Fixed: --> thanks for the info, the openjdk works out of the box w/o the script For hdf5 --> is actually my mistake, I've compiled the opencv w/o the qt this time so it is free from qt5 issue.? thanks. rgds, CL ---- On Tue, 03 Dec 2019 23:53:48 +0800 St?phane Mottelet wrote ---- Hello, In fact the enableJDK script is needed if the JDK is of Oracle brand. If you install a JDK from OpenJDK, e.g. https://adoptopenjdk.net/ the JNI and BundleApp entries are already present in the Info.plist, and the script is useless. Le 02/12/2019 ? 06:43, Chin Luh Tan a ?crit?: Hi Stephane,? Just to add-on, this script also works on previous version of MacOS, tested for High Sierra, it make Scilab works with latest version of Java. On top of that, I notice that it also fix the issue of the hdf5 dependency for the IPCV module, do you have the summary on what the fixes implemented? hdf5 stuff is completely independent from Java, so I don't understand why. Thanks for the nice patch! rgds, CL ---- On Fri, 29 Nov 2019 00:54:03 +0800 Chin Luh Tan mailto:chinluh.tan at bytecode-asia.com wrote ---- Hi,? Java SE 13.0.1 Thanks Rgds, CL ---- On Fri, 29 Nov 2019 00:52:15 +0800 mailto:stephane.mottelet at utc.fr wrote ---- _______________________________________________ users mailing list mailto:users at lists.scilab.org http://lists.scilab.org/mailman/listinfo/users Le 28/11/2019 ? 17:15, Chin Luh Tan a ?crit?: Hi Stephane,? I tested the latest jdk what is the version ? from the web, with your patch, it works! Thanks. rgds, CL ---- On Thu, 28 Nov 2019 23:27:09 +0800 St?phane Mottelet mailto:stephane.mottelet at utc.fr wrote ---- Sorry, there was a typo error (wrong tilda) in the URL, the valid one is S. Le 28/11/2019 ? 10:51, St?phane Mottelet a ?crit?: > Hello, > > I have prepared a small Applescript application? enabling the current > JDK to run Scilab on OSX Catalina at the url > > https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.utc.fr/?mottelet/java/enableJDK.dmg > > > This application automates the fix we already discussed in this ML. If > I summarize the necessary steps to run Scilab under Catalina, you have > to: > > 1-download and install a JDK (not a JRE), e.g. > https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html > (more recent versions should also work, tests are welcome...) > > 2-download and run the enableJDK script (you will have to allow its > execution in system preferencences) > > The fix provided by enableJDK is neither specific to Scilab nor > specific to OSX Catalina. It will allow any application using Java > thru JNI to run with your current JDK, without having to use the Apple > legacy/obsolete Java 6 > (https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/support.apple.com/kb/dl1572). > > 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 https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.utc.fr/~mottelet _______________________________________________ users mailing list mailto:users at lists.scilab.org https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users _______________________________________________ users mailing list mailto:users at lists.scilab.org https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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 https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.utc.fr/~mottelet _______________________________________________ users mailing list mailto:users at lists.scilab.org https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users _______________________________________________ users mailing list mailto:users at lists.scilab.org https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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 _______________________________________________ users mailing list users at lists.scilab.org http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Thu Dec 5 14:25:33 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Thu, 5 Dec 2019 10:25:33 -0300 Subject: [Scilab-users] question on makecell Message-ID: <84d6acff-5438-9330-d566-c9b54850f487@fceia.unr.edu.ar> Dear all, When using makecell such as in --> u = makecell([2 2], cos, 'hello', 1+%s^2, [1 2; 3 4]) ?u? = ? [? 1 fptr????? ]? [1x1 string? ] ? [1x1 polynomial]? [2x2 constant] we get a cell array where the unidimensional ordering of the cells goes first along columns and then ows. However, when extracting components unidimensionally, it behaves the other way around: --> u(1:4) ?ans? = ? [? 1 fptr????? ] ? [1x1 polynomial] ? [1x1 string??? ] ? [2x2 constant? ] The same happens wen applying matrix: --> matrix(u,4,1) ?ans? = ? [? 1 fptr????? ] ? [1x1 polynomial] ? [1x1 string??? ] ? [2x2 constant? ] --> matrix(u,1,4) ?ans? = ? [1 fptr]? [1x1 polynomial]? [1x1 string]? [2x2 constant] Isn't this inconsistent? Shouldn't makecell create the cell array going along rows and then columns? Regards, Federico Miyara -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Thu Dec 5 18:00:11 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 5 Dec 2019 18:00:11 +0100 Subject: [Scilab-users] question on makecell In-Reply-To: <84d6acff-5438-9330-d566-c9b54850f487@fceia.unr.edu.ar> References: <84d6acff-5438-9330-d566-c9b54850f487@fceia.unr.edu.ar> Message-ID: <67d5e2ea-f99c-08ed-57fe-a2b7872c6292@utc.fr> Le 05/12/2019 ? 14:25, Federico Miyara a ?crit?: > > Dear all, > > When using makecell such as in > > --> u = makecell([2 2], cos, 'hello', 1+%s^2, [1 2; 3 4]) > ?u? = > > ? [? 1 fptr????? ]? [1x1 string? ] > ? [1x1 polynomial]? [2x2 constant] > > we get a cell array where the unidimensional ordering of the cells > goes first along columns and then ows. However, when extracting > components unidimensionally, it behaves the other way around: > > --> u(1:4) > ?ans? = > > ? [? 1 fptr????? ] > ? [1x1 polynomial] > ? [1x1 string??? ] > ? [2x2 constant? ] > > The same happens wen applying matrix: > > --> matrix(u,4,1) > ?ans? = > > ? [? 1 fptr????? ] > ? [1x1 polynomial] > ? [1x1 string??? ] > ? [2x2 constant? ] > > --> matrix(u,1,4) > ?ans? = > > ? [1 fptr]? [1x1 polynomial]? [1x1 string]? [2x2 constant] > > Isn't this inconsistent? > Shouldn't makecell create the cell array going along rows and then > columns? No, the doc says: s= makecell(dims,a1,a2,...an) creates a cell array of dimensions given by dims with the given input arguments. The ai are stored along the last dimension first. > > Regards, > > Federico Miyara > > > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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 sgougeon at free.fr Thu Dec 5 22:13:54 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 5 Dec 2019 22:13:54 +0100 Subject: [Scilab-users] question on makecell In-Reply-To: <84d6acff-5438-9330-d566-c9b54850f487@fceia.unr.edu.ar> References: <84d6acff-5438-9330-d566-c9b54850f487@fceia.unr.edu.ar> Message-ID: Le 05/12/2019 ? 14:25, Federico Miyara a ?crit?: > > Dear all, > > When using makecell such as in > > --> u = makecell([2 2], cos, 'hello', 1+%s^2, [1 2; 3 4]) > ?u? = > > ? [? 1 fptr????? ]? [1x1 string? ] > ? [1x1 polynomial]? [2x2 constant] > > we get a cell array where the unidimensional ordering of the cells > goes first along columns and then ows. However, when extracting > components unidimensionally, it behaves the other way around: > > --> u(1:4) > ?ans? = > > ? [? 1 fptr????? ] > ? [1x1 polynomial] > ? [1x1 string??? ] > ? [2x2 constant? ] > > The same happens wen applying matrix: > > --> matrix(u,4,1) > ?ans? = > > ? [? 1 fptr????? ] > ? [1x1 polynomial] > ? [1x1 string??? ] > ? [2x2 constant? ] > > --> matrix(u,1,4) > ?ans? = > > ? [1 fptr]? [1x1 polynomial]? [1x1 string]? [2x2 constant] > > Isn't this inconsistent? > Shouldn't makecell create the cell array going along rows and then > columns? You are right, Federico. We could have expected to list cells elements in linearized indices order, as for all other native Scilab arrays. This irregularity/exception is completely useless and misleading: --> c = { "abcd" %T ; %pi %z} ?c? = ? [1x1 string? ]? [1x1 boolean?? ] ? [1x1 constant]? [1x1 polynomial] --> makecell([2 2], c{:}(:)) ?ans? = ? [1x1 string ]? [1x1 constant? ] ? [1x1 boolean]? [1x1 polynomial] The fact that it is documented does not attenuate it. Please do not hesitate to report a wish about removing this exception. It would not be complicated to remove it, and tracking and updating it in existing codes would be easy, through the /makecell/ keyword. Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Thu Dec 5 22:23:54 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Thu, 5 Dec 2019 18:23:54 -0300 Subject: [Scilab-users] cell and cell array Message-ID: <7d36cf5b-59ed-d1ce-7c07-61812dfff66c@fceia.unr.edu.ar> Dear all, 1) Are "cell" and "cell array" the same concept? 2) Or is a cell just a component of a cell array? 3) Would it be correct to say that a cell is a container of any other data type? Some authors, such as https://www.cse.iitb.ac.in/~sohoni/TD604/sundry/Scilab_Tutorial.pdf don't even use the compound "cell array", they just call it "cell". But the same author calls "struct" what would be a 1x1 struct Federico Miyara -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Dec 5 22:31:32 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 5 Dec 2019 22:31:32 +0100 Subject: [Scilab-users] cell and cell array In-Reply-To: <7d36cf5b-59ed-d1ce-7c07-61812dfff66c@fceia.unr.edu.ar> References: <7d36cf5b-59ed-d1ce-7c07-61812dfff66c@fceia.unr.edu.ar> Message-ID: Le 05/12/2019 ? 22:23, Federico Miyara a ?crit?: > > Dear all, > > 1) Are "cell" and "cell array" the same concept? Yes. A cell is a 1x1 cell array, a "scalar" cell. > > 2) Or is a cell just a component of a cell array? Yes, as well. > > 3) Would it be correct to say that a cell is a container of any other > data type? Still yes, like list()s, but tabular. Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Dec 5 23:23:18 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 5 Dec 2019 23:23:18 +0100 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> Message-ID: <4ace8522-8ce8-3ab7-85dd-4e5c719b73f9@free.fr> Le 29/11/2019 ? 06:57, Federico Miyara a ?crit?: > > Dear all, > > I'm trying to elucidate some details regarding types. The most basic > type, corresponding to real or complex decimal numbers (or vectors, > matrices and hypermatrices with this kind of components) is called > "constant" by the function typeof (and so listed in the documentation). > > However, the variable browser lists them as "double". Both are sucking legacy (i hope there is no copyright on this expression). But if we should sort awful things, a variable of "constant" is clearly the worst, in my not humble opinion. "double" is awful as well because personally, as a user in 2019, i strictly don't care about that, 40 years ago, there was a dominating "single precision" encoding, and then came the "double precision" encoding, and everybody was really happy, you know. Still today, we should remember this great event. OK, OK, OK. We are still very happy, indeed. In Scilab, there is no single precision encoding. May be we should propose implementing it, to look like our so loved eternal and discrete and exclusive inspirator. For any normal newby, before being twisted-minded by historical and external habits, a "double" is a number, or even better, for interfaces where short and explicit keywords are welcome, a num.ber And for the same fresh user, what does a string mean? A rope, a chain. Now, when comprehensive normal -- so very creative -- persons ask why we don't name a byte a string of bits, you know which answer they receive? None. Very strange world, isn't it? Very. Yet, "Text" is a word even shorter than "String". It tells exactly what this stuff is actually. In Scilab, a text is NOT a characters string: the basic block is the text, not the character. And part() helps. But anyway, which user really cares about how texts are encoded? Is it really the matter? > > This is somewhat confusing. Oo yes. Sometimes we pay to get confused. With Scilab, it's free. Get, try, and love it. Or report. > It seems that "double" refers to the way each individual component is > encoded while constant may refer to the fact that any array containing > doubles is o type constant. > > In the case of integers, for instance we have int64 as reported by > typeof, but in the Variable Browser it is listed a bit more in full as > "Integer 64". While this is also slightly inconsistent, it is not to > complain very much about. > > In the case of rationals, typeof returns "rational" while the Variable > Browser callsit "r (Tlist)" > > Cell array type is called "ce" by typeof but "Cell" in the Variabe Browser > > User-defined types in tlists and mlists are designed by the > user-defined type name by typeof, while the variable browser adds > "(Tlist)" or "(Mlist)" > > Functions, libraries and impliit lists such as $ are not listed in the > variable bowser but are correctly reported by typeof We can add them in the list, through the /Filter/ menu. Anyway, beside the "constant" typeof, i personally do not care too much about technical typeof names. Obviously, it is always highly preferable to choose carefully reserved keywords when creating them. Some typeof improvements have been done for Scilab 6. And indeed we could wonder why this "constant" typeof has not been changed. Too frequently used in existing codes? Probably. But the situation in GUIs is quite different. Back-compatibility issues are somewhat less acute than in the code. In the variables browser and editor, * an array of decimal real numbers could be tagged "num.ber" * an array of complex numbers : "complex", despite it is the same "constant" typeof. It's not the topic. * a sparse array of complex numbers : "sparse complex" * an array of characters string : "text" * an array of int64 integers : "int64". It is definitely clear, and shorter than "Integer 64" or "64 bits integers", that tell nothing more or better than "int64" * an array of rationals: "rational", indeed. * etc I do not see reasons to make GUIs labels exactly matching the technical typeofs. But, please convince us. Cheers Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Dec 5 23:26:25 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 5 Dec 2019 23:26:25 +0100 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: <385922a8-4e29-8981-4aaa-bb1f13c34f23@utc.fr> References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> <385922a8-4e29-8981-4aaa-bb1f13c34f23@utc.fr> Message-ID: Le 04/12/2019 ? 13:30, St?phane Mottelet a ?crit?: > > Hello, > > The name "constant" has been kept to ensure backwards compatibililty. > But frankly, sometimes legacy really sucks ! > > To me, "constant" should be replaced everywhere by "double" to > suppress this confusion. The argument that it would break some > toolboxes does not hold : we already will have to recompile almost all > binary gateways for the next release of Scilab. I don't understand why > toolboxes authors would not be able to release a new version by just > doing an easy find/replace in their codes. > St?phane, All ATOMS toolboxes are all together a very tiny part of all existing codes. Samuel From stephane.mottelet at utc.fr Fri Dec 6 08:41:18 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 6 Dec 2019 08:41:18 +0100 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> <385922a8-4e29-8981-4aaa-bb1f13c34f23@utc.fr> Message-ID: <9d59d049-9027-59c3-9907-3abeac4004d3@utc.fr> Le 05/12/2019 ? 23:26, Samuel Gougeon a ?crit?: > Le 04/12/2019 ? 13:30, St?phane Mottelet a ?crit?: >> >> Hello, >> >> The name "constant" has been kept to ensure backwards compatibililty. >> But frankly, sometimes legacy really sucks ! >> >> To me, "constant" should be replaced everywhere by "double" to >> suppress this confusion. The argument that it would break some >> toolboxes does not hold : we already will have to recompile almost >> all binary gateways for the next release of Scilab. I don't >> understand why toolboxes authors would not be able to release a new >> version by just doing an easy find/replace in their codes. >> > > St?phane, > > All ATOMS toolboxes are all together a very tiny part of all existing > codes. Yes. But what is the ratio of "alive" codes ? When I see the infinitesimal traffic on the ML, I have the feeling that this ratio is close to zero (but not zero, right ?). The small number of *active* users (hence having "active" codes) do not have problems to adapt to (necessary) changes. In the past we had such (yeah, painfull) issues (empty matrix stuff, among others). We are no going to prevent improvements because there are some codes, somewhere, with no maintainer, that could eventually fail after the improvement. Codes with no maintainers are (most of the time) dead codes. Please think about the future of Scilab, not always its past. > > Samuel > > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users > -- 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 From antoine.monmayrant at laas.fr Fri Dec 6 11:17:16 2019 From: antoine.monmayrant at laas.fr (Antoine Monmayrant) Date: Fri, 6 Dec 2019 11:17:16 +0100 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: <9d59d049-9027-59c3-9907-3abeac4004d3@utc.fr> References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> <385922a8-4e29-8981-4aaa-bb1f13c34f23@utc.fr> <9d59d049-9027-59c3-9907-3abeac4004d3@utc.fr> Message-ID: <37b63e4f-c8b3-c788-5f1c-4b900efdc30f@laas.fr> Le 06/12/2019 ? 08:41, St?phane Mottelet a ?crit?: > Please think about the future of Scilab, not always its past. I do agree with you. I mentioned in the past that the default colormap was so ugly it should be considered a bug ( http://bugzilla.scilab.org/show_bug.cgi?id=11054 ). I proposed changing the default colormap to something sensible and also proposed adding decent replacement to the abomination that is jetcolormap. The answer was: "but we can't: backward compatibility". I think scilab is one of the only plotting soft that is still using horrible defaults (matlab, python.matplotib, ... all have evolved and changed to reasonable defaults). Antoine From sgougeon at free.fr Fri Dec 6 13:09:34 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 6 Dec 2019 13:09:34 +0100 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: <37b63e4f-c8b3-c788-5f1c-4b900efdc30f@laas.fr> References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> <385922a8-4e29-8981-4aaa-bb1f13c34f23@utc.fr> <9d59d049-9027-59c3-9907-3abeac4004d3@utc.fr> <37b63e4f-c8b3-c788-5f1c-4b900efdc30f@laas.fr> Message-ID: <1fb2eb02-3e3e-2647-3f5b-23c23dce3e3a@free.fr> This is already hijacking the initial thread. I won't go on here after this message. Le 06/12/2019 ? 11:17, Antoine Monmayrant a ?crit?: > > Le 06/12/2019 ? 08:41, St?phane Mottelet a ?crit?: >> Please think about the future of Scilab, not always its past. For my part, i think about future, taking into account the present. And the past is also interesting to learn from past successes, and failures. > > > I do agree with you. > I mentioned in the past that the default colormap was so ugly it > should be considered a bug ( > http://bugzilla.scilab.org/show_bug.cgi?id=11054 ). > The problem was and is not that the default colormap is ugly, but that it holds for the whole figure, instead of per axes. > I proposed changing the default colormap to something sensible and > also proposed adding decent replacement to the abomination that is > jetcolormap. > jetcolormap() is jetcolormap(), and is used as a jetcolormap swatch in many other softwares, noticeably thermal imaging ones. It is one very standard colormap among other ones. I don't see the point about any abomination. > The answer was: "but we can't: backward compatibility". > > I think scilab is one of the only plotting soft that is still using > horrible defaults (matlab, python.matplotib, ... all have evolved and > changed to reasonable defaults). This is why i am wondering why my open post about changing the default grid style in axes has received strictly no answer, noticably from futurologists. Is it OK with the current defaults? Not for me. Was it OK with the default ticks and grid style of bode() up to 6.0.1 ? Not for me. This is why changing them was proposed and accepted in 6.0.2 . Etc, etc etc. There were actually extremely conservative positions or actions/inactions about some cases -- i am wondering for instance about the disp() inversion --, hardly believable, because almost or definitely without rationale. And we can hope that, for this case, it will be corrected soon. But these extreme cases -- that are even hard to consider as naive -- do no allow any extreme positions in the opposite, whose main processing could aim to avoid providing rationale as well, in the pretendly opposite direction but for the same reason: it's shorter, and at first sight, it looks easier. Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Fri Dec 6 14:14:46 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Fri, 6 Dec 2019 10:14:46 -0300 Subject: [Scilab-users] question on makecell In-Reply-To: References: <84d6acff-5438-9330-d566-c9b54850f487@fceia.unr.edu.ar> Message-ID: <7f1d0966-19a1-92cb-fbd8-926a6db1629d@fceia.unr.edu.ar> Samuel, Thanks, I've filed the wish as http://bugzilla.scilab.org/show_bug.cgi?id=16268. Just a detail regarding the bugzilla interface: Any issue like this is called a "bug" and we have to accept this to complete the form. I think some of them are not really bugs but inconsistencies or other kind of minor details and it would be nice that we could file them as "issues", term that better describes what they really are. Other OS free software projects have an "issue tracker". Regards, Federico Miyara On 05/12/2019 18:13, Samuel Gougeon wrote: > Le 05/12/2019 ? 14:25, Federico Miyara a ?crit?: >> >> Dear all, >> >> When using makecell such as in >> >> --> u = makecell([2 2], cos, 'hello', 1+%s^2, [1 2; 3 4]) >> ?u? = >> >> ? [? 1 fptr????? ]? [1x1 string? ] >> ? [1x1 polynomial]? [2x2 constant] >> >> we get a cell array where the unidimensional ordering of the cells >> goes first along columns and then ows. However, when extracting >> components unidimensionally, it behaves the other way around: >> >> --> u(1:4) >> ?ans? = >> >> ? [? 1 fptr????? ] >> ? [1x1 polynomial] >> ? [1x1 string??? ] >> ? [2x2 constant? ] >> >> The same happens wen applying matrix: >> >> --> matrix(u,4,1) >> ?ans? = >> >> ? [? 1 fptr????? ] >> ? [1x1 polynomial] >> ? [1x1 string??? ] >> ? [2x2 constant? ] >> >> --> matrix(u,1,4) >> ?ans? = >> >> ? [1 fptr]? [1x1 polynomial]? [1x1 string]? [2x2 constant] >> >> Isn't this inconsistent? >> Shouldn't makecell create the cell array going along rows and then >> columns? > > > You are right, Federico. > We could have expected to list cells elements in linearized indices > order, as for all other native Scilab arrays. > > This irregularity/exception is completely useless and misleading: > > --> c = { "abcd" %T ; %pi %z} > ?c? = > ? [1x1 string? ]? [1x1 boolean?? ] > ? [1x1 constant]? [1x1 polynomial] > > --> makecell([2 2], c{:}(:)) > ?ans? = > ? [1x1 string ]? [1x1 constant? ] > ? [1x1 boolean]? [1x1 polynomial] > > The fact that it is documented does not attenuate it. > > Please do not hesitate to report a wish about removing this exception. > It would not be complicated to remove it, and tracking and updating it > in existing codes would be easy, through the /makecell/ keyword. > > Regards > Samuel > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Dec 6 14:26:23 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 6 Dec 2019 14:26:23 +0100 Subject: [Scilab-users] question on makecell In-Reply-To: <7f1d0966-19a1-92cb-fbd8-926a6db1629d@fceia.unr.edu.ar> References: <84d6acff-5438-9330-d566-c9b54850f487@fceia.unr.edu.ar> <7f1d0966-19a1-92cb-fbd8-926a6db1629d@fceia.unr.edu.ar> Message-ID: Le 06/12/2019 ? 14:14, Federico Miyara a ?crit?: > > Samuel, > > Thanks, I've filed the wish as > http://bugzilla.scilab.org/show_bug.cgi?id=16268. > > Just a detail regarding the bugzilla interface: Any issue like this is > called a "bug" and we have to accept this to complete the form. No, from the beginning, you can set Importance = Wish, before validating and creating the bugzilla entry. You can set it also afterwards. In the old ages, there were 2 distinct websites to reports bugs on one hand, and to report wishes on the other hand. But it was definitely not handy. This is why? this "Wish" value has been created and both sites have been merged. Other values of the "Importance" flag can be set according to some quite simple rules (that are documented in the context). Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Fri Dec 6 23:23:35 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Fri, 6 Dec 2019 19:23:35 -0300 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: <4ace8522-8ce8-3ab7-85dd-4e5c719b73f9@free.fr> References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> <4ace8522-8ce8-3ab7-85dd-4e5c719b73f9@free.fr> Message-ID: <9be08b32-cd75-dcd7-2105-038d84fc798a@fceia.unr.edu.ar> Samuel, Thanks for your lengthy insight. I'll just take up the challenge at the end: > I do not see reasons to make GUIs labels exactly matching the > technical typeofs. > But, please convince us. I think the interface should be as transparent and informative as possible. It should confirm facts, not obscure them. It should never create a cognitive dissonance in the user. If I have learned that a type is called "constant", which is confirmed by the outcome of applying typeof, I'll find it strange, to say the least, to see that the type appears as "double" in the variable Browser. At a minimum, I'll lose time trying to find out what's going on; I'll probably ask on this list, causing others, probably yourself, to lose their time answering, and so on. Finally, there can be certainly no objection to use consistently a unique term for a single concept across the program. The only problem is that someone would have to change the string (or text :)) in the apropriate code, but it wouldn't be much of a burden and, as you said, there would be no backward compatibility problems. By the way, if constant were changed to double (or to number or num.ber --I don't get the dot...--), then as this might cause some backward compatibility, consider taking the oportunity also to replace "ce" by "cell", and "st" by "struct", which are the offical type names, Regards, Federico Miyara On 05/12/2019 19:23, Samuel Gougeon wrote: > Le 29/11/2019 ? 06:57, Federico Miyara a ?crit?: >> >> Dear all, >> >> I'm trying to elucidate some details regarding types. The most basic >> type, corresponding to real or complex decimal numbers (or vectors, >> matrices and hypermatrices with this kind of components) is called >> "constant" by the function typeof (and so listed in the documentation). >> >> However, the variable browser lists them as "double". > > > Both are sucking legacy (i hope there is no copyright on this > expression). But if we should sort awful things, a variable of > "constant" is clearly the worst, in my not humble opinion. > > "double" is awful as well because personally, as a user in 2019, i > strictly don't care about that, 40 years ago, there was a dominating > "single precision" encoding, and then came the "double precision" > encoding, and everybody was really happy, you know. Still today, we > should remember this great event. OK, OK, OK. We are still very happy, > indeed. > In Scilab, there is no single precision encoding. May be we should > propose implementing it, to look like our so loved eternal and > discrete and exclusive inspirator. > > For any normal newby, before being twisted-minded by historical and > external habits, a "double" is a number, or even better, for > interfaces where short and explicit keywords are welcome, a num.ber > > And for the same fresh user, what does a string mean? A rope, a chain. > Now, when comprehensive normal -- so very creative -- persons ask why > we don't name a byte a string of bits, you know which answer they > receive? None. Very strange world, isn't it? Very. > Yet, "Text" is a word even shorter than "String". It tells exactly > what this stuff is actually. > In Scilab, a text is NOT a characters string: the basic block is the > text, not the character. And part() helps. > But anyway, which user really cares about how texts are encoded? Is it > really the matter? > >> >> This is somewhat confusing. > > > Oo yes. Sometimes we pay to get confused. With Scilab, it's free. Get, > try, and love it. Or report. > >> It seems that "double" refers to the way each individual component is >> encoded while constant may refer to the fact that any array >> containing doubles is o type constant. >> >> In the case of integers, for instance we have int64 as reported by >> typeof, but in the Variable Browser it is listed a bit more in full >> as "Integer 64". While this is also slightly inconsistent, it is not >> to complain very much about. >> >> In the case of rationals, typeof returns "rational" while the >> Variable Browser callsit "r (Tlist)" >> >> Cell array type is called "ce" by typeof but "Cell" in the Variabe >> Browser >> >> User-defined types in tlists and mlists are designed by the >> user-defined type name by typeof, while the variable browser adds >> "(Tlist)" or "(Mlist)" >> >> Functions, libraries and impliit lists such as $ are not listed in >> the variable bowser but are correctly reported by typeof > > > We can add them in the list, through the /Filter/ menu. > > Anyway, beside the "constant" typeof, i personally do not care too > much about technical typeof names. > Obviously, it is always highly preferable to choose carefully reserved > keywords when creating them. > Some typeof improvements have been done for Scilab 6. And indeed we > could wonder why this "constant" typeof has not been changed. > Too frequently used in existing codes? Probably. > > But the situation in GUIs is quite different. Back-compatibility > issues are somewhat less acute than in the code. > In the variables browser and editor, > > * an array of decimal real numbers could be tagged "num.ber" > * an array of complex numbers : "complex", despite it is the same > "constant" typeof. It's not the topic. > * a sparse array of complex numbers : "sparse complex" > * an array of characters string : "text" > * an array of int64 integers : "int64". It is definitely clear, and > shorter than "Integer 64" or "64 bits integers", that tell nothing > more or better than "int64" > * an array of rationals: "rational", indeed. > * etc > > I do not see reasons to make GUIs labels exactly matching the > technical typeofs. > But, please convince us. > > Cheers > Samuel > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Dec 6 23:37:18 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 6 Dec 2019 23:37:18 +0100 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: <9be08b32-cd75-dcd7-2105-038d84fc798a@fceia.unr.edu.ar> References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> <4ace8522-8ce8-3ab7-85dd-4e5c719b73f9@free.fr> <9be08b32-cd75-dcd7-2105-038d84fc798a@fceia.unr.edu.ar> Message-ID: Le 06/12/2019 ? 23:23, Federico Miyara a ?crit?: > > .../... > By the way, if constant were changed to double (or to number or > num.ber --I don't get the dot... As in 3.14, contrarily to 123 > --), then as this might cause some backward compatibility, consider > taking the oportunity also to replace "ce" by "cell", and "st" by > "struct", Definitely, or even with their possible translation in locales, as for other main native types. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Sat Dec 7 00:24:34 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Fri, 6 Dec 2019 20:24:34 -0300 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: <385922a8-4e29-8981-4aaa-bb1f13c34f23@utc.fr> References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> <385922a8-4e29-8981-4aaa-bb1f13c34f23@utc.fr> Message-ID: St?phane, Thank you. In your opinion, when format is clearly defined and widely agreed upon, such as double, type name should be the same as format name? Or in this case you propose such name which by chance coincides with the name of the format? As you may guess I have some conflict about this--not sure of the difference between type, type of the scalar version and storage format. Regards, Federico Miyara On 04/12/2019 09:30, St?phane Mottelet wrote: > > Hello, > > The name "constant" has been kept to ensure backwards compatibililty. > But frankly, sometimes legacy really sucks ! > > To me, "constant" should be replaced everywhere by "double" to > suppress this confusion. The argument that it would break some > toolboxes does not hold : we already will have to recompile almost all > binary gateways for the next release of Scilab. I don't understand why > toolboxes authors would not be able to release a new version by just > doing an easy find/replace in their codes. > > S. > > Le 04/12/2019 ? 02:07, Federico Miyara a ?crit?: >> >> Dear all, >> >> Regarding the question I've sent a few days earlier (see below), I >> think the Variable Browser in some cases may be creating confusion >> between variable types and number formats >> >> For instance, >> >> a = 1.22 >> >> creates a variable of type "constant", while its format is "double". >> >> Regards, >> >> Federico Miyara >> >> >> On 29/11/2019 02:57, Federico Miyara wrote: >>> >>> Dear all, >>> >>> I'm trying to elucidate some details regarding types. The most basic >>> type, corresponding to real or complex decimal numbers (or vectors, >>> matrices and hypermatrices with this kind of components) is called >>> "constant" by the function typeof (and so listed in the documentation). >>> >>> However, the variable browser lists them as "double". >>> >>> This is somewhat confusing. It seems that "double" refers to the way >>> each individual component is encoded while constant may refer to the >>> fact that any array containing doubles is o type constant. >>> >>> In the case of integers, for instance we have int64 as reported by >>> typeof, but in the Variable Browser it is listed a bit more in full >>> as "Integer 64". While this is also slightly inconsistent, it is not >>> to complain very much about. >>> >>> In the case of rationals, typeof returns "rational" while the >>> Variable Browser callsit "r (Tlist)" >>> >>> Cell array type is called "ce" by typeof but "Cell" in the Variabe >>> Browser >>> >>> User-defined types in tlists and mlists are designed by the >>> user-defined type name by typeof, while the variable browser adds >>> "(Tlist)" or "(Mlist)" >>> >>> Functions, libraries and impliit lists such as $ are not listed in >>> the variable bowser but are correctly reported by typeof >>> >>> I wonder whether there is a reason for all this or it is actually an >>> issue that could be fixed in a future versions. >>> >>> Thank you >>> >>> Regards, >>> >>> Federico Miyara >>> >> >> >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users > -- > 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 > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From amonmayr at laas.fr Sat Dec 7 02:10:21 2019 From: amonmayr at laas.fr (Antoine Monmayrant) Date: Sat, 07 Dec 2019 02:10:21 +0100 Subject: [Scilab-users] Matplot help page insconsticencies Message-ID: <67c0-5deafc00-23-7ae84580@211292436> Hi all, The use of Matplot to display a HxWx3 hypermatrix as a RGB image is not really well described in the help page. It reads: "Arguments a a real matrix of size (n1, n2)." Which does not include the case where a is an hypermatrix of size (n1,n2,3). Only at the very end, just before the examples one can read: "data can be a matrix (or an hypermatrix) containing RGB, RGBA, ... data (see Matplot_properties)." Is there any reason why this is ability to display images is kind of hidden at the end of the help page? Antoine From sgougeon at free.fr Sat Dec 7 02:21:12 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 7 Dec 2019 02:21:12 +0100 Subject: [Scilab-users] Matplot help page insconsticencies In-Reply-To: <67c0-5deafc00-23-7ae84580@211292436> References: <67c0-5deafc00-23-7ae84580@211292436> Message-ID: <697a25f2-bb26-07f7-a8d9-8cdddbb05728@free.fr> Le 07/12/2019 ? 02:10, Antoine Monmayrant a ?crit?: > Hi all, > > The use of Matplot to display a HxWx3 hypermatrix as a RGB image is not really well described in the help page. > It reads: > > "Arguments > a a real matrix of size (n1, n2)." > > Which does not include the case where a is an hypermatrix of size (n1,n2,3). > Only at the very end, just before the examples one can read: > > "data can be a matrix (or an hypermatrix) containing RGB, RGBA, ... data (see Matplot_properties)." > > Is there any reason why this is ability to display images is kind of hidden at the end of the help page? Missing time. http://bugzilla.scilab.org/12955 From amonmayr at laas.fr Sat Dec 7 03:54:07 2019 From: amonmayr at laas.fr (Antoine Monmayrant) Date: Sat, 07 Dec 2019 03:54:07 +0100 Subject: [Scilab-users] =?utf-8?b?Pz09P3V0Zi04P3E/ICBNYXRwbG90IGhlbHAgcGFn?= =?utf-8?q?e_insconsticencies?= In-Reply-To: <697a25f2-bb26-07f7-a8d9-8cdddbb05728@free.fr> Message-ID: <67c0-5deb1480-25-7ae84580@211292437> Le Samedi, D?cembre 07, 2019 02:21 CET, Samuel Gougeon a ?crit: > Le 07/12/2019 ? 02:10, Antoine Monmayrant a ?crit?: > > Hi all, > > > > The use of Matplot to display a HxWx3 hypermatrix as a RGB image is not really well described in the help page. > > It reads: > > > > "Arguments > > a a real matrix of size (n1, n2)." > > > > Which does not include the case where a is an hypermatrix of size (n1,n2,3). > > Only at the very end, just before the examples one can read: > > > > "data can be a matrix (or an hypermatrix) containing RGB, RGBA, ... data (see Matplot_properties)." > > > > Is there any reason why this is ability to display images is kind of hidden at the end of the help page? > > > Missing time. > http://bugzilla.scilab.org/12955 Ah, OK, so we should work on some description and examples using RGB, RGBA images, etc? Antoine > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > From stephane.mottelet at utc.fr Mon Dec 9 09:44:02 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Mon, 9 Dec 2019 09:44:02 +0100 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> <4ace8522-8ce8-3ab7-85dd-4e5c719b73f9@free.fr> <9be08b32-cd75-dcd7-2105-038d84fc798a@fceia.unr.edu.ar> Message-ID: Hello all, Le 06/12/2019 ? 23:37, Samuel Gougeon a ?crit?: > Le 06/12/2019 ? 23:23, Federico Miyara a ?crit?: >> >> .../... >> By the way, if constant were changed to double (or to number or >> num.ber --I don't get the dot... > > As in 3.14, contrarily to 123 > If "double" is not to be used for reasons that I still don't understand, why don't we use "Real" instead of "Number" for x such that typeof(x)==constant and isreal(x)==%t ? This would be consistent with "complex" when typeof(x)==constant and isreal(x)==f. Moreover, this would be even set-theory compliant, i.e. use the name of the smallest set corresponding to storage type. > >> --), then as this might cause some backward compatibility, consider >> taking the oportunity also to replace "ce" by "cell", and "st" by >> "struct", > > Definitely, or even with their possible translation in locales, as for > other main native types. > > > > > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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 Tue Dec 10 10:47:51 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 10 Dec 2019 10:47:51 +0100 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> <4ace8522-8ce8-3ab7-85dd-4e5c719b73f9@free.fr> <9be08b32-cd75-dcd7-2105-038d84fc798a@fceia.unr.edu.ar> Message-ID: After thinking about it and after looking to other softwares, my proposition would be to concentrate on the set theoritic name + use parenthesis for details of storage typeof(x)=="constant" && isreal(x)==%t && issparse(x)=%f : Real typeof(x)=="constant" && isreal(x)==%f && issparse(x)=%f : Complex typeof(x)=="constant" && isreal(x)==%t && issparse(x)=%t : Real (sparse) typeof(x)=="constant" && isreal(x)==%f && issparse(x)=%t : Complex (sparse) typeof(x)=="boolean" && issparse(x)=%f : Boolean typeof(x)=="boolean" && issparse(x)=%t : Boolean (sparse) For integers, since their use is rather specific to more advanced users, i suggest to display the storage type to differentiate them type(x)==8 && inttype(x)==1 : Integer (int8) type(x)==8 && inttype(x)==11 : Integer (uint8) and so on... However, I don't understand why we should consider Scilab users as less aware (or less concerned by) of the reality of storage types. When you consider the big audience of Matlab and see that developpers didn't waste time like we do here. They just use "double", litteral integer types (int8,...). Moreover they didn't even have to make translations.... S. Le 09/12/2019 ? 09:44, St?phane Mottelet a ?crit?: > > Hello all, > > Le 06/12/2019 ? 23:37, Samuel Gougeon a ?crit?: >> Le 06/12/2019 ? 23:23, Federico Miyara a ?crit?: >>> >>> .../... >>> By the way, if constant were changed to double (or to number or >>> num.ber --I don't get the dot... >> >> As in 3.14, contrarily to 123 >> > > If "double" is not to be used for reasons that I still don't > understand, why don't we use "Real" instead of "Number" for x such > that typeof(x)==constant and isreal(x)==%t ? This would be consistent > with "complex" when typeof(x)==constant and isreal(x)==f. Moreover, > this would be even set-theory compliant, i.e. use the name of the > smallest set corresponding to storage type. > > >> >>> --), then as this might cause some backward compatibility, consider >>> taking the oportunity also to replace "ce" by "cell", and "st" by >>> "struct", >> >> Definitely, or even with their possible translation in locales, as >> for other main native types. >> >> >> >> >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users > -- > 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 > > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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 bruno.pincon at univ-lorraine.fr Tue Dec 10 16:49:03 2019 From: bruno.pincon at univ-lorraine.fr (=?UTF-8?Q?Pin=c3=a7on_Bruno?=) Date: Tue, 10 Dec 2019 16:49:03 +0100 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> <4ace8522-8ce8-3ab7-85dd-4e5c719b73f9@free.fr> <9be08b32-cd75-dcd7-2105-038d84fc798a@fceia.unr.edu.ar> Message-ID: <65fb7a0a-f66b-9832-101b-154b1e49b255@univ-lorraine.fr> Le 10/12/2019 ? 10:47, St?phane Mottelet a ?crit?: > > After thinking about it and after looking to other softwares, my > proposition would be to concentrate on the set theoritic name + use > parenthesis for details of storage > > typeof(x)=="constant" && isreal(x)==%t && issparse(x)=%f : Real > > typeof(x)=="constant" && isreal(x)==%f && issparse(x)=%f : Complex > > typeof(x)=="constant" && isreal(x)==%t && issparse(x)=%t : Real (sparse) > > typeof(x)=="constant" && isreal(x)==%f && issparse(x)=%t : Complex > (sparse) > > typeof(x)=="boolean" && issparse(x)=%f : Boolean > > typeof(x)=="boolean" && issparse(x)=%t : Boolean (sparse) > > For integers, since their use is rather specific to more advanced > users, i suggest to display the storage type to differentiate them > > type(x)==8 && inttype(x)==1 : Integer (int8) > > type(x)==8 && inttype(x)==11 : Integer (uint8) > > and so on... > ?? Looks good Stephane ! ?Bruno -- Non ? l'augmentation des frais d'inscription (Fac, IUT, ?coles...) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: serveimage.png Type: image/png Size: 6113 bytes Desc: not available URL: From chinluh.tan at bytecode-asia.com Wed Dec 11 14:31:06 2019 From: chinluh.tan at bytecode-asia.com (Chin Luh Tan) Date: Wed, 11 Dec 2019 21:31:06 +0800 Subject: [Scilab-users] Scilab API sciprint to print on the same line Message-ID: <16ef527f574.12799511f225859.7570712554584492025@bytecode-asia.com> Hi, I am trying to print some progress of a for loop in C api which will print the output in scilab console using the sciprint. Is there anyway to print the output to a same line as normal C printf could be achieved using '\r' ?? e.g.: currently my out out showing: Train Epoch: 10 [ 1000/15416] Loss: 0.5961 Train Epoch: 10 [ 2000/15416] Loss: 0.6794 Train Epoch: 10 [ 3000/15416] Loss: 0.3965 Train Epoch: 10 [ 4000/15416] Loss: 0.8110 Train Epoch: 10 [ 5000/15416] Loss: 0.7892 I would like to have the output to show on the same line.? I tried \r with fflush(stdout) it seems not working. Thanks. rgds, Chin Luh -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Wed Dec 11 15:25:39 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Wed, 11 Dec 2019 11:25:39 -0300 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> <4ace8522-8ce8-3ab7-85dd-4e5c719b73f9@free.fr> <9be08b32-cd75-dcd7-2105-038d84fc798a@fceia.unr.edu.ar> Message-ID: St?phane, I'm not sure whether you are proposing to modify types, type names or just how they are presented in the variable browser. I think, from the user's perspective, that the type names appearing in the variable browser (in the Type column) should be strictly the same as reported by the function typeof. Otherwise it can and will cause confusion and the sensation of lack of consistency. I also think types should reflect three things: 1) The way a variable is stored in memory, including the headers and the data with the basic format corresponding to each case. 2) The set of possible values or elements compatible with the type. 3) The functions and operators that can be applied to a given type of data (without overloading) and the way they work. According to this, a complex number would have definitely a different type from a real number since the way it is stored is different. By the way, calling non-complex numbers type "real" wouldn't be completely accurate, since they are really a subset of rationals with a power-of-ttwo denominator; however it would be acceptable because they are meant to approximate real numbers. Finally, I don't consider it recommendable that the same word be used both for a /format /and a /type name/, such as if "constant" were replaced by "double". In the case of integers, are all integers the same type?? Is int16 the same type as int32? I tend to think the answer is no, since they have very different storage representations, cover different sets of numbers and even operations behave differently. If so, the type should be called integer8, integer16 and so on (so the type would be integer8 and the basic format would be int16 --no ambiguity). If, on the contrary, they are the same, then the only type name should be "integer" and the basic format should be informed in a different column. Regards, Federico Miyara On 10/12/2019 06:47, St?phane Mottelet wrote: > > After thinking about it and after looking to other softwares, my > proposition would be to concentrate on the set theoritic name + use > parenthesis for details of storage > > typeof(x)=="constant" && isreal(x)==%t && issparse(x)=%f : Real > > typeof(x)=="constant" && isreal(x)==%f && issparse(x)=%f : Complex > > typeof(x)=="constant" && isreal(x)==%t && issparse(x)=%t : Real (sparse) > > typeof(x)=="constant" && isreal(x)==%f && issparse(x)=%t : Complex > (sparse) > > typeof(x)=="boolean" && issparse(x)=%f : Boolean > > typeof(x)=="boolean" && issparse(x)=%t : Boolean (sparse) > > For integers, since their use is rather specific to more advanced > users, i suggest to display the storage type to differentiate them > > type(x)==8 && inttype(x)==1 : Integer (int8) > > type(x)==8 && inttype(x)==11 : Integer (uint8) > > and so on... > > However, I don't understand why we should consider Scilab users as > less aware (or less concerned by) of the reality of storage types. > When you consider the big audience of Matlab and see that developpers > didn't waste time like we do here. They just use "double", litteral > integer types (int8,...). Moreover they didn't even have to make > translations.... > > S. > > Le 09/12/2019 ? 09:44, St?phane Mottelet a ?crit?: >> >> Hello all, >> >> Le 06/12/2019 ? 23:37, Samuel Gougeon a ?crit?: >>> Le 06/12/2019 ? 23:23, Federico Miyara a ?crit?: >>>> >>>> .../... >>>> By the way, if constant were changed to double (or to number or >>>> num.ber --I don't get the dot... >>> >>> As in 3.14, contrarily to 123 >>> >> >> If "double" is not to be used for reasons that I still don't >> understand, why don't we use "Real" instead of "Number" for x such >> that typeof(x)==constant and isreal(x)==%t ? This would be consistent >> with "complex" when typeof(x)==constant and isreal(x)==f. Moreover, >> this would be even set-theory compliant, i.e. use the name of the >> smallest set corresponding to storage type. >> >> >>> >>>> --), then as this might cause some backward compatibility, consider >>>> taking the oportunity also to replace "ce" by "cell", and "st" by >>>> "struct", >>> >>> Definitely, or even with their possible translation in locales, as >>> for other main native types. >>> >>> >>> >>> >>> _______________________________________________ >>> users mailing list >>> users at lists.scilab.org >>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users >> -- >> 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 >> >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users > -- > 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 > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Wed Dec 11 15:38:13 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 11 Dec 2019 15:38:13 +0100 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> <4ace8522-8ce8-3ab7-85dd-4e5c719b73f9@free.fr> <9be08b32-cd75-dcd7-2105-038d84fc798a@fceia.unr.edu.ar> Message-ID: Hello Frederico Le 11/12/2019 ? 15:25, Federico Miyara a ?crit?: > > St?phane, > > I'm not sure whether you are proposing to modify types, type names or > just how they are presented in the variable browser. As far as my previous message is concerned, I was just making a proposal for names in the variable browser > > I think, from the user's perspective, that the type names appearing in > the variable browser (in the Type column) should be strictly the same > as reported by the function typeof. Otherwise it can and will cause > confusion and the sensation of lack of consistency. So do I. But other users do not agree with that, that's why I am trying to find a sensible compromise... > > I also think types should reflect three things: > > 1) The way a variable is stored in memory, including the headers and > the data with the basic format corresponding to each case. > > 2) The set of possible values or elements compatible with the type. > > 3) The functions and operators that can be applied to a given type of > data (without overloading) and the way they work. > > According to this, a complex number would have definitely a different > type from a real number since the way it is stored is different. By > the way, calling non-complex numbers type "real" wouldn't be > completely accurate, since they are really a subset of rationals with > a power-of-ttwo denominator; however it would be acceptable because > they are meant to approximate real numbers. > > Finally, I don't consider it recommendable that the same word be used > both for a /format /and a /type name/, such as if "constant" were > replaced by "double". What do you mean by "format" ? > > In the case of integers, are all integers the same type?? Is int16 the > same type as int32? > > I tend to think the answer is no, since they have very different > storage representations, cover different sets of numbers and even > operations behave differently. If so, the type should be called > integer8, integer16 and so on (so the type would be integer8 and the > basic format would be int16 --no ambiguity). If, on the contrary, they > are the same, then the only type name should be "integer" and the > basic format should be informed in a different column. > That was my attempt, by using parenthesis. S. > Regards, > > Federico Miyara > > > > > > On 10/12/2019 06:47, St?phane Mottelet wrote: >> >> After thinking about it and after looking to other softwares, my >> proposition would be to concentrate on the set theoritic name + use >> parenthesis for details of storage >> >> typeof(x)=="constant" && isreal(x)==%t && issparse(x)=%f : Real >> >> typeof(x)=="constant" && isreal(x)==%f && issparse(x)=%f : Complex >> >> typeof(x)=="constant" && isreal(x)==%t && issparse(x)=%t : Real (sparse) >> >> typeof(x)=="constant" && isreal(x)==%f && issparse(x)=%t : Complex >> (sparse) >> >> typeof(x)=="boolean" && issparse(x)=%f : Boolean >> >> typeof(x)=="boolean" && issparse(x)=%t : Boolean (sparse) >> >> For integers, since their use is rather specific to more advanced >> users, i suggest to display the storage type to differentiate them >> >> type(x)==8 && inttype(x)==1 : Integer (int8) >> >> type(x)==8 && inttype(x)==11 : Integer (uint8) >> >> and so on... >> >> However, I don't understand why we should consider Scilab users as >> less aware (or less concerned by) of the reality of storage types. >> When you consider the big audience of Matlab and see that developpers >> didn't waste time like we do here. They just use "double", litteral >> integer types (int8,...). Moreover they didn't even have to make >> translations.... >> >> S. >> >> Le 09/12/2019 ? 09:44, St?phane Mottelet a ?crit?: >>> >>> Hello all, >>> >>> Le 06/12/2019 ? 23:37, Samuel Gougeon a ?crit?: >>>> Le 06/12/2019 ? 23:23, Federico Miyara a ?crit?: >>>>> >>>>> .../... >>>>> By the way, if constant were changed to double (or to number or >>>>> num.ber --I don't get the dot... >>>> >>>> As in 3.14, contrarily to 123 >>>> >>> >>> If "double" is not to be used for reasons that I still don't >>> understand, why don't we use "Real" instead of "Number" for x such >>> that typeof(x)==constant and isreal(x)==%t ? This would be >>> consistent with "complex" when typeof(x)==constant and isreal(x)==f. >>> Moreover, this would be even set-theory compliant, i.e. use the name >>> of the smallest set corresponding to storage type. >>> >>> >>>> >>>>> --), then as this might cause some backward compatibility, >>>>> consider taking the oportunity also to replace "ce" by "cell", and >>>>> "st" by "struct", >>>> >>>> Definitely, or even with their possible translation in locales, as >>>> for other main native types. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> users mailing list >>>> users at lists.scilab.org >>>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users >>> -- >>> 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 >>> >>> _______________________________________________ >>> users mailing list >>> users at lists.scilab.org >>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users >> -- >> 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 >> >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/users > > > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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 fmiyara at fceia.unr.edu.ar Wed Dec 11 19:20:50 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Wed, 11 Dec 2019 15:20:50 -0300 Subject: [Scilab-users] Confusion about types (typeof vs. Variabe Browser) In-Reply-To: References: <1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar> <4ace8522-8ce8-3ab7-85dd-4e5c719b73f9@free.fr> <9be08b32-cd75-dcd7-2105-038d84fc798a@fceia.unr.edu.ar> Message-ID: <7449fde6-4517-c779-ac92-001587d92cb8@fceia.unr.edu.ar> St?phane, >> I think, from the user's perspective, that the type names appearing >> in the variable browser (in the Type column) should be strictly the >> same as reported by the function typeof. Otherwise it can and will >> cause confusion and the sensation of lack of consistency. > So do I. But other users do not agree with that, that's why I am > trying to find a sensible compromise... Users who don't think that each thing should bear a single name should provide a good rationale. The rationale for my proposal is that most users are not computer science experts and can be easily confused by the reach of the word "type". If the variable browser gives a contradictory message, such as calling "double" what typeof calls "constant", they will probably be at a loss. >> Finally, I don't consider it recommendable that the same word be used >> both for a /format /and a /type name/, such as if "constant" were >> replaced by "double". > What do you mean by "format" ? I mean the way basic data are stored, such as the IEEE Std 754 specification, so double (double precision) is a format with 1 sign bit, 11 binary exponent bits and 52 fraction bits. Type involves other information appart from the data themselves, contained in a heaader. According to https://wiki.scilab.org/Memory%20representation%20of%20variables "constant" requires a numeric type integer, two integers representing rows and columns, an integer representing whether it is real or complex, and finally the data in double precision format. >> I tend to think the answer is no, since they have very different >> storage representations, cover different sets of numbers and even >> operations behave differently. If so, the type should be called >> integer8, integer16 and so on (so the type would be integer8 and the >> basic format would be int16 --no ambiguity). If, on the contrary, >> they are the same, then the only type name should be "integer" and >> the basic format should be informed in a different column. >> > That was my attempt, by using parenthesis. > This could be prevented if it were acknowledged that int16 and 1nt32, for instance, are actually different types as they have different memory representations, they represent different number sets, and operators on them have different reults: --> int16(32000)*2 ?ans? = ?-1536 --> int32(32000)*2 ?ans? = ? 64000 typeof acknowledges it, but type doesn't, yielding 8 for both types. Regards, Federico Miyara -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Dec 11 21:09:25 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 11 Dec 2019 21:09:25 +0100 Subject: [Scilab-users] Scilab API sciprint to print on the same line In-Reply-To: <16ef527f574.12799511f225859.7570712554584492025@bytecode-asia.com> References: <16ef527f574.12799511f225859.7570712554584492025@bytecode-asia.com> Message-ID: Le 11/12/2019 ? 14:31, Chin Luh Tan a ?crit?: > Hi, > > I am trying to print some progress of a for loop in C api which will > print the output in scilab console using the sciprint. > > Is there anyway to print the output to a same line as normal C printf > could be achieved using '\r' ? > > e.g.: > > currently my out out showing: > > Train Epoch: 10 [ 1000/15416] Loss: 0.5961 > Train Epoch: 10 [ 2000/15416] Loss: 0.6794 > Train Epoch: 10 [ 3000/15416] Loss: 0.3965 > Train Epoch: 10 [ 4000/15416] Loss: 0.8110 > Train Epoch: 10 [ 5000/15416] Loss: 0.7892 > > I would like to have the output to show on the same line. > > I tried \r with fflush(stdout) it seems not working. > > Thanks. > > rgds, > Chin Luh In the C API i don't know, but in Scilab language, this mprintf("..\r") feature is broken . It is possible to mimik it with (example): for i = 1:100 mprintf("Static counter: %d\n \n\n",i) sleep(300) clc(1) end Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From chinluh.tan at bytecode-asia.com Thu Dec 12 17:10:32 2019 From: chinluh.tan at bytecode-asia.com (Chin Luh Tan) Date: Fri, 13 Dec 2019 00:10:32 +0800 Subject: [Scilab-users] Scilab API sciprint to print on the same line In-Reply-To: References: <16ef527f574.12799511f225859.7570712554584492025@bytecode-asia.com> Message-ID: <16efae04743.c61a96ce454183.7920217350096248729@bytecode-asia.com> Hi Samuel,? Thanks for your reply.? Previously I was using clc(linenumtoclear) for showing this effect in scilab, but i never thought of the mprintf, i was using disp that time for i = 1:100 disp("Static counter : " + string(i)); sleep(1); clc(1) end it seems that the mprintf also kind of broken? as it needs 3 \n to get this result? I also tried to look into the clc C source and see whether I could use the c code of clc in scilab api but no luck, but your example of mprintf which need 3 \n inspired me to look into the mprintf c code and see how it works.? I will get back to you on this, thanks again. rgds, CL ---- On Thu, 12 Dec 2019 04:09:25 +0800 Samuel Gougeon wrote ---- Le 11/12/2019 ? 14:31, Chin Luh Tan a ?crit?: In the C API i don't know, but in Scilab language, http://bugzilla.scilab.org/show_bug.cgi?id=14642. It is possible to mimik it with (example): for i = 1:100 mprintf("Static counter: %d\n \n\n",i) sleep(300) clc(1) end Samuel _______________________________________________ users mailing list mailto:users at lists.scilab.org http://lists.scilab.org/mailman/listinfo/users Hi, I am trying to print some progress of a for loop in C api which will print the output in scilab console using the sciprint. Is there anyway to print the output to a same line as normal C printf could be achieved using '\r' ?? e.g.: currently my out out showing: Train Epoch: 10 [ 1000/15416] Loss: 0.5961 Train Epoch: 10 [ 2000/15416] Loss: 0.6794 Train Epoch: 10 [ 3000/15416] Loss: 0.3965 Train Epoch: 10 [ 4000/15416] Loss: 0.8110 Train Epoch: 10 [ 5000/15416] Loss: 0.7892 I would like to have the output to show on the same line.? I tried \r with fflush(stdout) it seems not working. Thanks. rgds, Chin Luh -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Dec 12 23:19:54 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 12 Dec 2019 23:19:54 +0100 Subject: [Scilab-users] Scilab API sciprint to print on the same line In-Reply-To: <16efae04743.c61a96ce454183.7920217350096248729@bytecode-asia.com> References: <16ef527f574.12799511f225859.7570712554584492025@bytecode-asia.com> <16efae04743.c61a96ce454183.7920217350096248729@bytecode-asia.com> Message-ID: Hello Chin Luh Le 12/12/2019 ? 17:10, Chin Luh Tan a ?crit?: > Hi Samuel, > > Thanks for your reply. > > Previously I was using clc(linenumtoclear) for showing this effect in > scilab, but i never thought of the mprintf, i was using disp that time > > for i = 1:100 > disp("Static counter : " + string(i)); > sleep(1); clc(1) > end I could not think using disp(). According to its expected behavior, it always appends an \n, while we want to stay on the line, what's the purpose of \r instead of \n, and mprintf() does not append anything to what it is requested to display. > it seems that the mprintf also kind of broken? as it needs 3 \n to get > this result? I do not think that disp() is broken. It looks OK, while clc(1) is bugged . This is why extra \n are required for this workaround using clc. > I also tried to look into the clc C source and see whether I could use > the c code of clc in scilab api but no luck, but your example of > mprintf which need 3 \n inspired me to look into the mprintf c code > and see how it works. Now that you know the clc code, please do not hesitate to propose a patch for its clc(1) bug ;-)) Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.muehlmann at gmail.com Fri Dec 13 09:08:26 2019 From: p.muehlmann at gmail.com (P M) Date: Fri, 13 Dec 2019 09:08:26 +0100 Subject: [Scilab-users] Scilab API sciprint to print on the same line In-Reply-To: References: <16ef527f574.12799511f225859.7570712554584492025@bytecode-asia.com> <16efae04743.c61a96ce454183.7920217350096248729@bytecode-asia.com> Message-ID: ...even more strange than the reported bug: clc(1) seems to behave different when directly written into the console vs used from SciNotes. from SciNotes: clc();for i=1:10 mprintf("%d\n",i)endclc(1) result in console: 1 2 3 4 5 6 7 // note that number 8,9,10 are cleared..so it's 3 lines, not only two --> code directly put into console...do this step by step --> clc(); --> for i=1:10 mprintf("%d\n",i) end 1 2 3 4 5 6 7 8 9 10 --> clc(1) 1 2 3 4 5 6 7 8 9 --> // works as expected tested on win7, Scilab 6.0.2 best regards, Philipp Am Do., 12. Dez. 2019 um 23:20 Uhr schrieb Samuel Gougeon : > Hello Chin Luh > > Le 12/12/2019 ? 17:10, Chin Luh Tan a ?crit : > > Hi Samuel, > > Thanks for your reply. > > Previously I was using clc(linenumtoclear) for showing this effect in > scilab, but i never thought of the mprintf, i was using disp that time > > for i = 1:100 > disp("Static counter : " + string(i)); > sleep(1); clc(1) > end > > > I could not think using disp(). According to its expected behavior, it > always appends an \n, while we want to stay on the line, what's the purpose > of \r instead of \n, and mprintf() does not append anything to what it is > requested to display. > > > it seems that the mprintf also kind of broken? as it needs 3 \n to get > this result? > > > I do not think that disp() is broken. It looks OK, while clc(1) is bugged > . This is why extra \n > are required for this workaround using clc. > > I also tried to look into the clc C source and see whether I could use the > c code of clc in scilab api but no luck, but your example of mprintf which > need 3 \n inspired me to look into the mprintf c code and see how it works. > > > Now that you know the clc code, please do not hesitate to propose a patch > for its clc(1) bug ;-)) > Regards > > Samuel > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amonmayr at laas.fr Fri Dec 13 09:22:22 2019 From: amonmayr at laas.fr (Antoine Monmayrant) Date: Fri, 13 Dec 2019 09:22:22 +0100 Subject: [Scilab-users] =?utf-8?b?Pz09P3V0Zi04P3E/ICBTY2lsYWIgQVBJIHNjaXBy?= =?utf-8?q?int_to_print_on_the_same_line?= In-Reply-To: Message-ID: <49a9-5df34a00-3d-7fadf080@57224964> Well, I can see the same behaviour under linux. But while playing with your example, I discovered a nice bug: sleep 100 just kills scilab (Segmentation fault (core dumped)). It works from both scinotes or the console. Can anyone give it a try under windows so that I can make an accurate bug report? Cheers, Antoine Le Vendredi, D?cembre 13, 2019 09:08 CET, P M a ?crit: > ...even more strange than the reported bug: > clc(1) seems to behave different when directly written into the console vs > used from SciNotes. > > from SciNotes: > > clc();for i=1:10 mprintf("%d\n",i)endclc(1) > > result in console: > 1 > 2 > 3 > 4 > 5 > 6 > 7 // note that number 8,9,10 are cleared..so it's 3 lines, not only two > > --> > > code directly put into console...do this step by step > --> clc(); > --> for i=1:10 mprintf("%d\n",i) end > 1 > 2 > 3 > 4 > 5 > 6 > 7 > 8 > 9 > 10 > > --> clc(1) > 1 > 2 > 3 > 4 > 5 > 6 > 7 > 8 > 9 > > --> // works as expected > > tested on win7, Scilab 6.0.2 > > best regards, > Philipp > > > > > Am Do., 12. Dez. 2019 um 23:20 Uhr schrieb Samuel Gougeon >: > > > Hello Chin Luh > > > > Le 12/12/2019 ? 17:10, Chin Luh Tan a ?crit : > > > > Hi Samuel, > > > > Thanks for your reply. > > > > Previously I was using clc(linenumtoclear) for showing this effect in > > scilab, but i never thought of the mprintf, i was using disp that time > > > > for i = 1:100 > > disp("Static counter : " + string(i)); > > sleep(1); clc(1) > > end > > > > > > I could not think using disp(). According to its expected behavior, it > > always appends an \n, while we want to stay on the line, what's the purpose > > of \r instead of \n, and mprintf() does not append anything to what it is > > requested to display. > > > > > > it seems that the mprintf also kind of broken? as it needs 3 \n to get > > this result? > > > > > > I do not think that disp() is broken. It looks OK, while clc(1) is bugged > > . This is why extra \n > > are required for this workaround using clc. > > > > I also tried to look into the clc C source and see whether I could use the > > c code of clc in scilab api but no luck, but your example of mprintf which > > need 3 \n inspired me to look into the mprintf c code and see how it works. > > > > > > Now that you know the clc code, please do not hesitate to propose a patch > > for its clc(1) bug ;-)) > > Regards > > > > Samuel > > > > > > _______________________________________________ > > users mailing list > > users at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/users > > From amonmayr at laas.fr Fri Dec 13 09:40:09 2019 From: amonmayr at laas.fr (Antoine Monmayrant) Date: Fri, 13 Dec 2019 09:40:09 +0100 Subject: [Scilab-users] =?utf-8?q?sleep_100_crashes_scilab_=3A_http=3A//bu?= =?utf-8?q?gzilla=2Escilab=2Eorg/show=5Fbug=2Ecgi=3Fid=3D14791?= Message-ID: <49a9-5df34e80-57-7fadf080@57224994> Hello all, Replying my previous email about sleep 100 crashing scilab: it's already reported as bug #14791 Antoine From stephane.mottelet at utc.fr Fri Dec 13 18:00:24 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 13 Dec 2019 18:00:24 +0100 Subject: [Scilab-users] Scilab API sciprint to print on the same line In-Reply-To: References: <16ef527f574.12799511f225859.7570712554584492025@bytecode-asia.com> <16efae04743.c61a96ce454183.7920217350096248729@bytecode-asia.com> Message-ID: <307d8a32-77d8-96be-63f9-a56505101e43@utc.fr> Besides the clc bug, why don't we try to repair mprinf ? Le 12/12/2019 ? 23:19, Samuel Gougeon a ?crit?: > Hello Chin Luh > > Le 12/12/2019 ? 17:10, Chin Luh Tan a ?crit?: >> Hi Samuel, >> >> Thanks for your reply. >> >> Previously I was using clc(linenumtoclear) for showing this effect in >> scilab, but i never thought of the mprintf, i was using disp that time >> >> for i = 1:100 >> disp("Static counter : " + string(i)); >> sleep(1); clc(1) >> end > > I could not think using disp(). According to its expected behavior, it > always appends an \n, while we want to stay on the line, what's the > purpose of \r instead of \n, and mprintf() does not append anything to > what it is requested to display. > > >> it seems that the mprintf also kind of broken? as it needs 3 \n to >> get this result? > > > I do not think that disp() is broken. It looks OK, while clc(1) is > bugged > . > This is why extra \n are required for this workaround using clc. > >> I also tried to look into the clc C source and see whether I could >> use the c code of clc in scilab api but no luck, but your example of >> mprintf which need 3 \n inspired me to look into the mprintf c code >> and see how it works. > > > Now that you know the clc code, please do not hesitate to propose a > patch for its clc(1) bug ;-)) > > Regards > > Samuel > > > > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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 sgougeon at free.fr Fri Dec 13 19:24:55 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 13 Dec 2019 19:24:55 +0100 Subject: [Scilab-users] Scilab API sciprint to print on the same line In-Reply-To: References: <16ef527f574.12799511f225859.7570712554584492025@bytecode-asia.com> <16efae04743.c61a96ce454183.7920217350096248729@bytecode-asia.com> Message-ID: Le 13/12/2019 ? 09:08, P M a ?crit?: > .../... > code directly put into console...do this step by step > --> clc(); > --> for i=1:10 mprintf("%d\n",i) end > 1 > 2 > 3 > 4 > 5 > 6 > 7 > 8 > 9 > 10 > > --> clc(1) > 1 > 2 > 3 > 4 > 5 > 6 > 7 > 8 > 9 > > -->? // works as expected No, 2 lines preceding the prompt are cleared instead of one: the 10, and the next blank line. From sgougeon at free.fr Fri Dec 13 19:29:45 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 13 Dec 2019 19:29:45 +0100 Subject: [Scilab-users] Scilab API sciprint to print on the same line In-Reply-To: <307d8a32-77d8-96be-63f9-a56505101e43@utc.fr> References: <16ef527f574.12799511f225859.7570712554584492025@bytecode-asia.com> <16efae04743.c61a96ce454183.7920217350096248729@bytecode-asia.com> <307d8a32-77d8-96be-63f9-a56505101e43@utc.fr> Message-ID: <78d0b709-28dd-c737-2b2a-3cb9858fcc2d@free.fr> Le 13/12/2019 ? 18:00, St?phane Mottelet a ?crit?: > > Besides the clc bug, why don't we try to repair mprinf ? > Please follow the report , the dedicated commit, and comment it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Tue Dec 17 20:08:16 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Tue, 17 Dec 2019 16:08:16 -0300 Subject: [Scilab-users] 3 byte integers Message-ID: Dear All, While it is possible to create directly a wav file of reasonable size from Scilab, if the size is very large, say, 1 Gb,we willmost likely have memory problems. That's why I'm trying to program a script allowing to append new audio data to an existing wav file. It is simple to save 8 bit, 16 bit and 32 bit samples to a file. However, 24 bit is also a popular format and Scilab doesn't seem to support 3 byte integer format, either for variables and read/write file operations. Is there some way to save 3 byte integers other than creating a specialized routine from scratch? Regards, Federico Miyara -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Tue Dec 17 21:15:01 2019 From: stephane.mottelet at utc.fr (=?utf-8?Q?St=C3=A9phane_Mottelet?=) Date: Tue, 17 Dec 2019 21:15:01 +0100 Subject: [Scilab-users] 3 byte integers In-Reply-To: References: Message-ID: Hello I think it is supported in savewave and loadwave. There was a pb with savewave but fixed by https://codereview.scilab.org/#/c/19947/ in 6.0.2 S. > Le 17 d?c. 2019 ? 20:09, Federico Miyara a ?crit : > > ? > Dear All, > > While it is possible to create directly a wav file of reasonable size from Scilab, if the size is very large, say, 1 Gb, we will most likely have memory problems. That's why I'm trying to program a script allowing to append new audio data to an existing wav file. > > It is simple to save 8 bit, 16 bit and 32 bit samples to a file. However, 24 bit is also a popular format and Scilab doesn't seem to support 3 byte integer format, either for variables and read/write file operations. > > Is there some way to save 3 byte integers other than creating a specialized routine from scratch? > > Regards, > > Federico Miyara > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Tue Dec 17 22:37:48 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Tue, 17 Dec 2019 18:37:48 -0300 Subject: [Scilab-users] 3 byte integers In-Reply-To: References: Message-ID: <881003e6-26bc-ecd6-44de-88f1f53db11a@fceia.unr.edu.ar> St?phane, wavewrite also supports 3 bytes, but as I commented, I cannot save, not evem generate huge files, so i must create them by successive appending, so i needto be able to save 3 byte numbers directly. Thanks anyway. Regards, Federico Miyara On 17/12/2019 17:15, St?phane Mottelet wrote: > Hello > > I think it is supported in savewave and loadwave. There was a pb with > savewave but fixed by > > https://codereview.scilab.org/#/c/19947/ > > in 6.0.2 > > S. > >> Le 17 d?c. 2019 ? 20:09, Federico Miyara a >> ?crit?: >> >> ? >> Dear All, >> >> While it is possible to create directly a wav file of reasonable size >> from Scilab, if the size is very large, say, 1 Gb,we willmost likely >> have memory problems. That's why I'm trying to program a script >> allowing to append new audio data to an existing wav file. >> >> It is simple to save 8 bit, 16 bit and 32 bit samples to a file. >> However, 24 bit is also a popular format and Scilab doesn't seem to >> support 3 byte integer format, either for variables and read/write >> file operations. >> >> Is there some way to save 3 byte integers other than creating a >> specialized routine from scratch? >> >> Regards, >> >> Federico Miyara >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From chinluh.tan at bytecode-asia.com Wed Dec 18 02:36:27 2019 From: chinluh.tan at bytecode-asia.com (Chin Luh Tan) Date: Wed, 18 Dec 2019 09:36:27 +0800 Subject: [Scilab-users] Scilab API sciprint to print on the same line In-Reply-To: References: <16ef527f574.12799511f225859.7570712554584492025@bytecode-asia.com> <16efae04743.c61a96ce454183.7920217350096248729@bytecode-asia.com> Message-ID: <16f16a62e32.117d4044c282373.8337546216948381468@bytecode-asia.com> Hi,? Looks like the last command followed by the clc(1) would be ignore : example 1:? --> for i=1:10 mprintf("%d\n",i) end; 1 2 3 4 5 6 7 8 9 10 -->?clc(1) 1 2 3 4 5 6 7 8 9 10? <-- cleared ? ? ? <--cleared example 2: ? --> for i=1:10 mprintf("%d\n",i) end;clc(1) 1 2 3 4 5 6 7 when the for loop printing 10, the clc(1) followed will immediately clear 9 and 8 making the 10 as never been exist.? thanks. CL -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Wed Dec 18 05:37:26 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Wed, 18 Dec 2019 01:37:26 -0300 Subject: [Scilab-users] 3 byte integers In-Reply-To: <881003e6-26bc-ecd6-44de-88f1f53db11a@fceia.unr.edu.ar> References: <881003e6-26bc-ecd6-44de-88f1f53db11a@fceia.unr.edu.ar> Message-ID: <5511a09b-6aa2-669f-bf5d-d2bee2795d0f@fceia.unr.edu.ar> St?phane, Sorry for having explained myself so poorly. The problem with the macros already available is that in order to save a wavfile in a single operation, I need to have the whole signal loaded in a variable. I'm not sure whether it is possible to handle a variable with about 2 gigasamples (the maximum 16 bit mono file that Windows allows --a total file size of 4 GB--). This would demand 16 GB just for a single variable. I'm pretty sure that problems would arise even with an audio variable much smaller than that. This is the reason why I need to be able to append new audio data to an existing wave file, so that much less information is handled at a time. Of course this requires to edit the header to update the file size after the append, but this is quite easy. The tough part is to save three byte numbers, since the existing mput command supports 1, 2, 4 and 8 byte formats, but not the 3 byte used for 24 bit audio. If there were a native macro or primitive capable of formatting numbers as 3 byte, it would be helpful. Thanks, Federico Miyara On 17/12/2019 18:37, Federico Miyara wrote: > > St?phane, > > wavewrite also supports 3 bytes, but as I commented, I cannot save, > not evem generate huge files, so i must create them by successive > appending, so i needto be able to save 3 byte numbers directly. > > Thanks anyway. > > Regards, > > Federico Miyara > > On 17/12/2019 17:15, St?phane Mottelet wrote: >> Hello >> >> I think it is supported in savewave and loadwave. There was a pb with >> savewave but fixed by >> >> https://codereview.scilab.org/#/c/19947/ >> >> in 6.0.2 >> >> S. >> >>> Le 17 d?c. 2019 ? 20:09, Federico Miyara >>> a ?crit?: >>> >>> ? >>> Dear All, >>> >>> While it is possible to create directly a wav file of reasonable >>> size from Scilab, if the size is very large, say, 1 Gb,we willmost >>> likely have memory problems. That's why I'm trying to program a >>> script allowing to append new audio data to an existing wav file. >>> >>> It is simple to save 8 bit, 16 bit and 32 bit samples to a file. >>> However, 24 bit is also a popular format and Scilab doesn't seem to >>> support 3 byte integer format, either for variables and read/write >>> file operations. >>> >>> Is there some way to save 3 byte integers other than creating a >>> specialized routine from scratch? >>> >>> Regards, >>> >>> Federico Miyara >>> _______________________________________________ >>> users mailing list >>> users at lists.scilab.org >>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users >> >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/users > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christophe.Dang at sidel.com Wed Dec 18 09:04:10 2019 From: Christophe.Dang at sidel.com (Dang Ngoc Chan, Christophe) Date: Wed, 18 Dec 2019 08:04:10 +0000 Subject: [Scilab-users] {EXT} Re: Scilab API sciprint to print on the same line In-Reply-To: <16f16a62e32.117d4044c282373.8337546216948381468@bytecode-asia.com> References: <16ef527f574.12799511f225859.7570712554584492025@bytecode-asia.com> <16efae04743.c61a96ce454183.7920217350096248729@bytecode-asia.com> <16f16a62e32.117d4044c282373.8337546216948381468@bytecode-asia.com> Message-ID: Hello, > De : Chin Luh Tan > Envoy? : mercredi 18 d?cembre 2019 02:36 > > Looks like the last command followed by the clc(1) would be ignore : > > [...] I've got the same result as you but additionally, I've got a different result using disp((1:10)') instead of the loop. The result is also weird but the number of lines that are suppressed is different. -- Christophe Dang Ngoc Chan Mechanical calculation engineer General This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From j-lan at online.no Wed Dec 18 13:29:39 2019 From: j-lan at online.no (=?UTF-8?Q?Jan_=c3=85ge_Langeland?=) Date: Wed, 18 Dec 2019 13:29:39 +0100 Subject: [Scilab-users] 3 byte integers In-Reply-To: <5511a09b-6aa2-669f-bf5d-d2bee2795d0f@fceia.unr.edu.ar> References: <881003e6-26bc-ecd6-44de-88f1f53db11a@fceia.unr.edu.ar> <5511a09b-6aa2-669f-bf5d-d2bee2795d0f@fceia.unr.edu.ar> Message-ID: <113a28aa-d057-6339-57b8-00d127bc71cd@online.no> As a quick fix, would it work to use a temporary file for the data you want to append?? Something like this wavwrite(wavdata_24,'temp') f1=mopen('temp.wav'.,'rb') wavdata_bytes=mget(n_bytes,'c',f1) f2=mopen('main.wav','ab') mput(wavdata_bytes(45:n_bytes),'c',f2) Brgds Jan On 2019-12-18 5:37 AM, Federico Miyara wrote: > > St?phane, > > Sorry for having explained myself so poorly. The problem with the > macros already available is that in order to save a wavfile in a > single operation, I need to have the whole signal loaded in a > variable. I'm not sure whether it is possible to handle a variable > with about 2 gigasamples (the maximum 16 bit mono file that Windows > allows --a total file size of 4 GB--). This would demand 16 GB just > for a single variable. > > I'm pretty sure that problems would arise even with an audio variable > much smaller than that. > > This is the reason why I need to be able to append new audio data to > an existing wave file, so that much less information is handled at a > time. Of course this requires to edit the header to update the file > size after the append, but this is quite easy. > > The tough part is to save three byte numbers, since the existing mput > command supports 1, 2, 4 and 8 byte formats, but not the 3 byte used > for 24 bit audio. If there were a native macro or primitive capable of > formatting numbers as 3 byte, it would be helpful. > > Thanks, > > Federico Miyara > > > > On 17/12/2019 18:37, Federico Miyara wrote: >> >> St?phane, >> >> wavewrite also supports 3 bytes, but as I commented, I cannot save, >> not evem generate huge files, so i must create them by successive >> appending, so i needto be able to save 3 byte numbers directly. >> >> Thanks anyway. >> >> Regards, >> >> Federico Miyara >> >> On 17/12/2019 17:15, St?phane Mottelet wrote: >>> Hello >>> >>> I think it is supported in savewave and loadwave. There was a pb >>> with savewave but fixed by >>> >>> https://codereview.scilab.org/#/c/19947/ >>> >>> in 6.0.2 >>> >>> S. >>> >>>> Le 17 d?c. 2019 ? 20:09, Federico Miyara >>>> a ?crit?: >>>> >>>> ? >>>> Dear All, >>>> >>>> While it is possible to create directly a wav file of reasonable >>>> size from Scilab, if the size is very large, say, 1 Gb,we willmost >>>> likely have memory problems. That's why I'm trying to program a >>>> script allowing to append new audio data to an existing wav file. >>>> >>>> It is simple to save 8 bit, 16 bit and 32 bit samples to a file. >>>> However, 24 bit is also a popular format and Scilab doesn't seem to >>>> support 3 byte integer format, either for variables and read/write >>>> file operations. >>>> >>>> Is there some way to save 3 byte integers other than creating a >>>> specialized routine from scratch? >>>> >>>> Regards, >>>> >>>> Federico Miyara >>>> _______________________________________________ >>>> users mailing list >>>> users at lists.scilab.org >>>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users >>> >>> _______________________________________________ >>> users mailing list >>> users at lists.scilab.org >>> http://lists.scilab.org/mailman/listinfo/users >> >> >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/users > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From perrichon.pierre at wanadoo.fr Sat Dec 21 01:14:52 2019 From: perrichon.pierre at wanadoo.fr (Perrichon) Date: Sat, 21 Dec 2019 01:14:52 +0100 Subject: [Scilab-users] extract data in a scope under xcos Message-ID: Dear, Is there anyway to extract the data in a scope under xcos? .May be because Datatips give every point X,Y But how to proceed ? I have added in my scheme a "TOWS_c > component ; it works, but the management is more heavy in the project. A solution to extract directly in the scope is welcome. Best regards. Pierre P. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Sat Dec 21 18:21:29 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Sat, 21 Dec 2019 14:21:29 -0300 Subject: [Scilab-users] efficiency in HD read Message-ID: Dear all, I'm curious about the following. Sometimes several data are retrieved from a file using several read operations, such as in this code from function wavread: wFormatTag = mget(1, "us", fid); // Data encoding format nChannels = mget(1, "us", fid); // Number of channels nSamplesPerSec = mget(1, "ui", fid); // Samples per second nAvgBytesPerSec = mget(1, "ui", fid); // Avg transfer rate nBlockAlign = mget(1, "us", fid); // Block alignment This could well have been done reading all data at once. It would be a bit more complicated to convert the data to the final form because of the heterogenuous size of the fields (some are two-byte and others four-byte). Doesn't this approach impose more mechanical stress on the hard drive? Or even larger access time? Or upon the first read a full sector is transferred to a buffer? Thanks for any insight! Regards, Federico Miyara -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.muehlmann at gmail.com Sat Dec 21 21:16:35 2019 From: p.muehlmann at gmail.com (P M) Date: Sat, 21 Dec 2019 21:16:35 +0100 Subject: [Scilab-users] designing a sound file Message-ID: Dear experts, I try to compose (design) a small sound file, made of several wav-files. My question: How to approach this task in the best way? Here some input: - sound 1: Tick-sound of a clock - sound 2: Tock-sound of a clock each wav-file has these properties: - length: 0.1 sec - bits: 32 - sample rate: 44100 Hz - mono Now: I want to create a tick-tock sound of length n-seconds .. where I can choice the length of n Each Tick-Tock-sound must be exactly 1-second apart from each other. I load the sounds with: loadwave Do I have to create a single "silent" wav file first, which is n-seconds long and than insert at the correct position the sound signal? Thank you, Philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: From j-lan at online.no Sun Dec 22 00:05:59 2019 From: j-lan at online.no (=?UTF-8?Q?Jan_=c3=85ge_Langeland?=) Date: Sun, 22 Dec 2019 00:05:59 +0100 Subject: [Scilab-users] designing a sound file In-Reply-To: References: Message-ID: <0e31ceda-e49b-8d8c-082d-9d6b616c6572@online.no> I am not really an expert in this format, but unless you want a very long file, the logical approach for me would be to make a vector with zeros representing all samples, then insert the imported tick and tack samples at the right places, and export to a file with wavewrite or savewave. Making sure to remove DC offset in the tick, tock data to avoid clicks. Maybe it will sound better in stereo ? Brgds Jan On 2019-12-21 21:16 PM, P M wrote: > Dear experts, > > I try to compose (design) a small sound file, made of several wav-files. > > My question:?????? How to approach this task in the best way? > > > Here some input: > > - sound 1: Tick-sound of a clock > - sound 2: Tock-sound of a clock > > each wav-file has these properties: > - length: 0.1 sec > - bits: 32 > - sample rate: 44100 Hz > - mono > > Now: > I want to create a tick-tock sound of length? n-seconds? .. where I > can choice the length of n > Each Tick-Tock-sound must be exactly 1-second apart from each other. > > I load the sounds with: loadwave > > Do I have to create a single "silent" wav file first, which is? > n-seconds long and than insert at the correct position the sound signal? > > Thank you, > Philipp > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.muehlmann at gmail.com Sun Dec 22 10:31:28 2019 From: p.muehlmann at gmail.com (P M) Date: Sun, 22 Dec 2019 10:31:28 +0100 Subject: [Scilab-users] designing a sound file In-Reply-To: <23909590-4bb7-34ac-10ea-302c48c67d6a@fceia.unr.edu.ar> References: <23909590-4bb7-34ac-10ea-302c48c67d6a@fceia.unr.edu.ar> Message-ID: ...ticket is solved. Thank you Jan + Federico. Creating a zero-vector of just the right length and inserting the sound at the correct position just does it. BR Philipp Am So., 22. Dez. 2019 um 00:23 Uhr schrieb Federico Miyara < fmiyara at fceia.unr.edu.ar>: > > Philipp, > > You can certainly use the strategy you propose. This should work: > > tick = wavread("path/tick.wav"); > tock = wavread("path/tock.wav"); > ntick = length(tick); > ntock = length(tock); > m = max(ntick, ntock; // Just in case both lengths differ > Fs = 44100; > x = zeros(1, n*Fs + m); // Allocate space allowing room for > the last sound > for k = 0:n > if floor(k/2)== k/2 // tick if k is even, tock if odd > x(k*Fs + 1:k*Fs + ntick) = tick; > else > x(k*Fs + 1:k*Fs + ntock) = tock; > end > end > > If you would like the sound to be a bit more realistic, you could apply > some reververberation. To do that, create an impulse response by generating > a random noise using grand with normal distribution and applying to it a > decreasing exponential envelope with a time constant about 1/14 times the > desired reverberation time (about 0.5 s for a normal living room). The > duration of the impulse response should be longer than the reverberation > time. > > Then convolve it with the dry signal x using conv. When you are done, sum > an attenuated version of the result to the dry signal. > > Redards, > > Federico Miyara > > > On 21/12/2019 17:16, P M wrote: > > Dear experts, > > I try to compose (design) a small sound file, made of several wav-files. > > My question: How to approach this task in the best way? > > > Here some input: > > - sound 1: Tick-sound of a clock > - sound 2: Tock-sound of a clock > > each wav-file has these properties: > - length: 0.1 sec > - bits: 32 > - sample rate: 44100 Hz > - mono > > Now: > I want to create a tick-tock sound of length n-seconds .. where I can > choice the length of n > Each Tick-Tock-sound must be exactly 1-second apart from each other. > > I load the sounds with: loadwave > > Do I have to create a single "silent" wav file first, which is n-seconds > long and than insert at the correct position the sound signal? > > Thank you, > Philipp > > _______________________________________________ > users mailing listusers at lists.scilab.orghttp://lists.scilab.org/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.muehlmann at gmail.com Mon Dec 23 11:09:41 2019 From: p.muehlmann at gmail.com (P M) Date: Mon, 23 Dec 2019 11:09:41 +0100 Subject: [Scilab-users] adding sound to avi-file within Scilab Message-ID: Dear Experts, is it possible to merge sound and video in one of the Scilab toolboxes? >From what I find the image processing toolboxes can create avi's, but only put image as frames into the avi. My current approach would be: - create (or already have) a set of images...each one represents a single frame - put all images into a single avi-file - create the sound and save it as a wav-file - use a 3rd party software to merge avi+sound Thanks, Philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Mon Dec 23 11:55:07 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Mon, 23 Dec 2019 11:55:07 +0100 Subject: [Scilab-users] extract data in a scope under xcos In-Reply-To: References: Message-ID: <122fd816-8c15-96d6-248c-c86f39803e90@free.fr> Hello Pierre, Le 21/12/2019 ? 01:14, Perrichon a ?crit?: > > Dear, > > Is there anyway to extract the data in a scope under xcos? > > ?May be because Datatips give every point X,Y > > But how to proceed ? > > I have added in my scheme a ?TOWS_c?? component?; it works, but the > management is more heavy in the project. > > A solution to extract directly in the scope is welcome. > Do you mean to extract some coordinates of curves displayed in a scope, and then display them as well on the scope? If so, there is apparently no sink or annotation block to do this. May be the scifunc_block_m could be hijacked to do the job. Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuel.enibe at unn.edu.ng Tue Dec 24 13:13:04 2019 From: samuel.enibe at unn.edu.ng (Samuel Enibe) Date: Tue, 24 Dec 2019 13:13:04 +0100 Subject: [Scilab-users] SCILAB 6.0.2 Not running on UBUNTU 18.04 LTS Message-ID: I have been using SCILAB for several years now on UBUNTU and decided to try the latest version today. Thus, I downloaded the 64 bit version of SCILAB 6.0.2 for LINUX and tried to run on UBUNTU 18.04 LTS. It produces the following error scilab-bin: error while loading shared libraries: libjava.so: cannot open shared object file: No such file or directory Is this a bug? I had the same experience with version 6.0.1 Any suggestions on the way out? Samuel Ogbonna Enibe University of Nigeria, Nsukka, Nigeria -------------- next part -------------- An HTML attachment was scrubbed... URL: From amonmayr at laas.fr Tue Dec 24 13:38:32 2019 From: amonmayr at laas.fr (Antoine Monmayrant) Date: Tue, 24 Dec 2019 13:38:32 +0100 Subject: [Scilab-users] =?utf-8?b?Pz09P3V0Zi04P3E/ICBTQ0lMQUIgNi4wLjIgTm90?= =?utf-8?q?_running_on_UBUNTU_18=2E04_LTS?= In-Reply-To: Message-ID: <941-5e020700-11-52fdb200@221245523> Hello Samuel, I am running 6.0.2 under ubuntu 64bits and I don't remember having this issue. Is your ubuntu install a vanilla one or did you change some default settings regarding java? We can try to compare our settings if this can help. Antoine Le Mardi, D?cembre 24, 2019 13:13 CET, Samuel Enibe a ?crit: > I have been using SCILAB for several years now on UBUNTU and decided to try > the latest version today. > > Thus, I downloaded the 64 bit version of SCILAB 6.0.2 for LINUX and tried > to run on UBUNTU 18.04 LTS. > > It produces the following error > > scilab-bin: error while loading shared libraries: libjava.so: cannot open > shared object file: No such file or directory > > Is this a bug? I had the same experience with version 6.0.1 > > Any suggestions on the way out? > > Samuel Ogbonna Enibe > University of Nigeria, Nsukka, Nigeria From samuel.enibe at unn.edu.ng Tue Dec 24 13:48:56 2019 From: samuel.enibe at unn.edu.ng (Samuel Enibe) Date: Tue, 24 Dec 2019 13:48:56 +0100 Subject: [Scilab-users] ?==?utf-8?q? SCILAB 6.0.2 Not running on UBUNTU 18.04 LTS In-Reply-To: <941-5e020700-11-52fdb200@221245523> References: <941-5e020700-11-52fdb200@221245523> Message-ID: Thanks Antoine. I didn't change the default settings on UBUNTU 18.04 LTS. I have checked again and seen that SCILAB 6.0.1 works but doesn't support ATOMS. The 6.0.2 was downloaded, the files extracted and placed in the default folder just as I did for 6.0.1. Should it be extracted using a special command? Samuel On Tue, 24 Dec 2019, 13:39 Antoine Monmayrant, wrote: > Hello Samuel, > > I am running 6.0.2 under ubuntu 64bits and I don't remember having this > issue. > Is your ubuntu install a vanilla one or did you change some default > settings regarding java? > > We can try to compare our settings if this can help. > > Antoine > > > Le Mardi, D?cembre 24, 2019 13:13 CET, Samuel Enibe < > samuel.enibe at unn.edu.ng> a ?crit: > > > I have been using SCILAB for several years now on UBUNTU and decided to > try > > the latest version today. > > > > Thus, I downloaded the 64 bit version of SCILAB 6.0.2 for LINUX and > tried > > to run on UBUNTU 18.04 LTS. > > > > It produces the following error > > > > scilab-bin: error while loading shared libraries: libjava.so: cannot open > > shared object file: No such file or directory > > > > Is this a bug? I had the same experience with version 6.0.1 > > > > Any suggestions on the way out? > > > > Samuel Ogbonna Enibe > > University of Nigeria, Nsukka, Nigeria > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From perrichon.pierre at wanadoo.fr Tue Dec 24 16:21:02 2019 From: perrichon.pierre at wanadoo.fr (Perrichon) Date: Tue, 24 Dec 2019 16:21:02 +0100 Subject: [Scilab-users] extract data in a scope under xcos In-Reply-To: <122fd816-8c15-96d6-248c-c86f39803e90@free.fr> References: <122fd816-8c15-96d6-248c-c86f39803e90@free.fr> Message-ID: Hello Samuel, In fact, my client want the equivalent of the data in a scilab numerical scope, but in a format .txt or .csv, as to introduce these files in his expert analysis software Flexpro. Since last time, I?ve worked around the structure of a scop, and written a routine hereafter. That a better solution than added a ?TOWS_c ? component in the xcos diagrams. I also think that the kind of routines are sorely missing in Xcos in ?File menu? (gateway to Excel for exemple). It could be an improvment Sorry for this disturbance Pierre P. Best regards a=gca() mat=a.children Legend=mat(1).text' // Channels titles nbv=size(Legend); nbv=nbv(2) // Number of channels Time=mat(2).data(:,1) lg=size(Time); lg=lg(1) // Size of each channel (nb. lines) NumReg=1 txtNumreg=sprintf("%02i_",NumReg) filename=txtNumreg + "Francis" + ".txt"; fd = mopen(filename, "w") // Line 1 : Print Legends //-------------------------------- mfprintf(fd,"Time") for i=1:nbv mfprintf(fd,"\t%s",Legend(i)) end mfprintf(fd,"\n") // Data line per line //------------------------------------- for i=1:lg // Print Time //-------------------- mfprintf(fd,"%0.2f",Time(i)) //Print Data line //---------------------------------- for k=nbv:-1:1 mfprintf(fd,"\t%f",mat(k+1).data(i,2)) end mfprintf(fd,"\n") // Next line end mclose(fd) De : users De la part de Samuel Gougeon Envoy? : lundi 23 d?cembre 2019 11:55 ? : users at lists.scilab.org Objet : Re: [Scilab-users] extract data in a scope under xcos Hello Pierre, Le 21/12/2019 ? 01:14, Perrichon a ?crit : Dear, Is there anyway to extract the data in a scope under xcos? May be because Datatips give every point X,Y But how to proceed ? I have added in my scheme a ?TOWS_c ? component ; it works, but the management is more heavy in the project. A solution to extract directly in the scope is welcome. Do you mean to extract some coordinates of curves displayed in a scope, and then display them as well on the scope? If so, there is apparently no sink or annotation block to do this. May be the scifunc_block_m could be hijacked to do the job. Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From perrichon.pierre at wanadoo.fr Thu Dec 26 12:01:31 2019 From: perrichon.pierre at wanadoo.fr (Perrichon) Date: Thu, 26 Dec 2019 12:01:31 +0100 Subject: [Scilab-users] =?iso-8859-1?q?Unexpected_Figure_n=B00_in_xload_in?= =?iso-8859-1?q?struction_under_XCOS_-_Buggzilla_16289?= Message-ID: Dear, Runing routine in xload help under XCOS, but adding a xload in figure n?100, also create an unexpected empty Figure n?0 So 2 figures are generated : Empty Figure 0 and Figure 100 in the following example t=0:0.01:10; subplot(211),plot2d(t,sin(t)) subplot(212),plot2d(t,sin(3*t)) xsave(TMPDIR + "/foo.scg", gcf()) clf() xload(TMPDIR + "/foo.scg",100) Workaround after the set of xload : // D?truire la fen?tre n?0 (bug?) //------------------------------- lista=winsid() b=find(lista==0) if b<>[] then xdel(lista(b)); end; Best regards. Pierre P. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Dec 26 19:56:13 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 26 Dec 2019 19:56:13 +0100 Subject: [Scilab-users] =?utf-8?q?Unexpected_Figure_n=C2=B00_in_xload_inst?= =?utf-8?q?ruction_under_XCOS_-_Buggzilla_16289?= In-Reply-To: References: Message-ID: <028f7d89-e943-9aac-4826-e220f0fe741b@free.fr> Le 26/12/2019 ? 12:01, Perrichon a ?crit?: > > Dear, > > Runing routine in xload help under XCOS, but adding a xload in figure > n?100, also create an unexpected empty Figure n?0 > > So 2 figures are generated : Empty Figure 0 and Figure 100 in the > following example > > t=0:0.01:10; > > subplot(211),plot2d(t,sin(t)) > > subplot(212),plot2d(t,sin(3*t)) > > xsave(TMPDIR + "/foo.scg", gcf()) > > clf() > > xload(TMPDIR + "/foo.scg",100) > I don't catch what you mean with /Runing routine in xload help under XCOS./ But running this code in the Scilab console yields what is expected. The default figure #0 where plots are drawn and finally cleared is kept, and its saved version is loaded in a separate figure #100. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From amonmayr at laas.fr Thu Dec 26 22:26:39 2019 From: amonmayr at laas.fr (Antoine Monmayrant) Date: Thu, 26 Dec 2019 22:26:39 +0100 Subject: [Scilab-users] =?utf-8?b?Pz09P3V0Zi04P3E/ID89PT91dGYtOD9xPyA/PSBT?= =?utf-8?q?CILAB_6=2E0=2E2_Not_running_on_UBUNTU_18=2E04_LT?= In-Reply-To: Message-ID: <699b-5e052580-19-7e846700@70081578> I just tried on an ubuntu 18.04.3 (not a clean install, un upgrade from 17.10) and it worked without any issue. Can you try to install a vm on your current setup and run an ubuntu live-cd and install scilab in it to see whether the problem is still there? Antoine Le Mardi, D?cembre 24, 2019 13:48 CET, Samuel Enibe a ?crit: > Thanks Antoine. > I didn't change the default settings on UBUNTU 18.04 LTS. > > I have checked again and seen that SCILAB 6.0.1 works but doesn't support > ATOMS. > > The 6.0.2 was downloaded, the files extracted and placed in the default > folder just as I did for 6.0.1. Should it be extracted using a special > command? > > Samuel > > On Tue, 24 Dec 2019, 13:39 Antoine Monmayrant, wrote: > > > Hello Samuel, > > > > I am running 6.0.2 under ubuntu 64bits and I don't remember having this > > issue. > > Is your ubuntu install a vanilla one or did you change some default > > settings regarding java? > > > > We can try to compare our settings if this can help. > > > > Antoine > > > > > > Le Mardi, D?cembre 24, 2019 13:13 CET, Samuel Enibe < > > samuel.enibe at unn.edu.ng> a ?crit: > > > > > I have been using SCILAB for several years now on UBUNTU and decided to > > try > > > the latest version today. > > > > > > Thus, I downloaded the 64 bit version of SCILAB 6.0.2 for LINUX and > > tried > > > to run on UBUNTU 18.04 LTS. > > > > > > It produces the following error > > > > > > scilab-bin: error while loading shared libraries: libjava.so: cannot open > > > shared object file: No such file or directory > > > > > > Is this a bug? I had the same experience with version 6.0.1 > > > > > > Any suggestions on the way out? > > > > > > Samuel Ogbonna Enibe > > > University of Nigeria, Nsukka, Nigeria > > > > _______________________________________________ > > users mailing list > > users at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/users > > From fmiyara at fceia.unr.edu.ar Fri Dec 27 07:54:40 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Fri, 27 Dec 2019 03:54:40 -0300 Subject: [Scilab-users] find name / path of open file Message-ID: <281229a1-0a35-7cd8-7b47-d3c300fd5519@fceia.unr.edu.ar> Dear All, How can I find the path and name of an open file from its file descriptor provided by mopen? Thanks, Federico Miyara -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Fri Dec 27 08:04:35 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Fri, 27 Dec 2019 04:04:35 -0300 Subject: [Scilab-users] find name / path of open file In-Reply-To: <281229a1-0a35-7cd8-7b47-d3c300fd5519@fceia.unr.edu.ar> References: <281229a1-0a35-7cd8-7b47-d3c300fd5519@fceia.unr.edu.ar> Message-ID: <2bfcc0ae-dc7f-ea5c-43de-7b6e278da153@fceia.unr.edu.ar> Sorry, it was easy. After searching for a while I finally found the function dispfiles(), which does the job... Federico Miyara On 27/12/2019 03:54, Federico Miyara wrote: > > Dear All, > > How can I find the path and name of an open file from its file > descriptor provided by mopen? > > Thanks, > > Federico Miyara > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From j-lan at online.no Fri Dec 27 10:01:46 2019 From: j-lan at online.no (=?UTF-8?Q?Jan_=c3=85ge_Langeland?=) Date: Fri, 27 Dec 2019 10:01:46 +0100 Subject: [Scilab-users] find name / path of open file In-Reply-To: <281229a1-0a35-7cd8-7b47-d3c300fd5519@fceia.unr.edu.ar> References: <281229a1-0a35-7cd8-7b47-d3c300fd5519@fceia.unr.edu.ar> Message-ID: <602e6c2d-6eb1-6ad5-6b48-76ac86373b08@online.no> [u,t,pathandfilename]=file(fd) Jan On 2019-12-27 7:54 AM, Federico Miyara wrote: > > Dear All, > > How can I find the path and name of an open file from its file > descriptor provided by mopen? > > Thanks, > > Federico Miyara > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From perrichon.pierre at wanadoo.fr Fri Dec 27 10:10:49 2019 From: perrichon.pierre at wanadoo.fr (Perrichon) Date: Fri, 27 Dec 2019 10:10:49 +0100 Subject: [Scilab-users] =?iso-8859-1?q?Unexpected_Figure_n=B00_in_xload_in?= =?iso-8859-1?q?struction_under_XCOS_-_Buggzilla_16289?= In-Reply-To: <028f7d89-e943-9aac-4826-e220f0fe741b@free.fr> References: <028f7d89-e943-9aac-4826-e220f0fe741b@free.fr> Message-ID: Ok Sorry De : users De la part de Samuel Gougeon Envoy? : jeudi 26 d?cembre 2019 19:56 ? : users at lists.scilab.org Objet : Re: [Scilab-users] Unexpected Figure n?0 in xload instruction under XCOS - Buggzilla 16289 Le 26/12/2019 ? 12:01, Perrichon a ?crit : Dear, Runing routine in xload help under XCOS, but adding a xload in figure n?100, also create an unexpected empty Figure n?0 So 2 figures are generated : Empty Figure 0 and Figure 100 in the following example t=0:0.01:10; subplot(211),plot2d(t,sin(t)) subplot(212),plot2d(t,sin(3*t)) xsave(TMPDIR + "/foo.scg", gcf()) clf() xload(TMPDIR + "/foo.scg",100) I don't catch what you mean with Runing routine in xload help under XCOS. But running this code in the Scilab console yields what is expected. The default figure #0 where plots are drawn and finally cleared is kept, and its saved version is loaded in a separate figure #100. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Fri Dec 27 17:00:07 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Fri, 27 Dec 2019 13:00:07 -0300 Subject: [Scilab-users] find name / path of open file In-Reply-To: <602e6c2d-6eb1-6ad5-6b48-76ac86373b08@online.no> References: <281229a1-0a35-7cd8-7b47-d3c300fd5519@fceia.unr.edu.ar> <602e6c2d-6eb1-6ad5-6b48-76ac86373b08@online.no> Message-ID: Jan, Oh, thanks! That's much better than dispfiles, since it gives the name as a variable. I had seen that function but somehow I didn't realize that possibility. Regards, Federico Miyara On 27/12/2019 06:01, Jan ?ge Langeland wrote: > > [u,t,pathandfilename]=file(fd) > > Jan > > On 2019-12-27 7:54 AM, Federico Miyara wrote: >> >> Dear All, >> >> How can I find the path and name of an open file from its file >> descriptor provided by mopen? >> >> Thanks, >> >> Federico Miyara >> >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From chinluh.tan at bytecode-asia.com Fri Dec 27 17:03:24 2019 From: chinluh.tan at bytecode-asia.com (Chin Luh Tan) Date: Sat, 28 Dec 2019 00:03:24 +0800 Subject: [Scilab-users] ?= SCILAB 6.0.2 Not running on UBUNTU 18.04 LT In-Reply-To: <699b-5e052580-19-7e846700@70081578> References: <699b-5e052580-19-7e846700@70081578> Message-ID: <16f48192125.b9ef3e2315626.4938545009196684537@bytecode-asia.com> Hi,? Similar issue was faced by another linux distro a couple of weeks ago, try the below: 1. Try to locate the libjava.so to see whether java is install. if you, u could try to temporary set the JAVA_HOME and try to run scilab again e.g.: $ locate libjava.so or $ update-java-alternatives -l and then $ export JAVA_HOME="/usr/lib/jvm/java-8-openjdk-amd64/"?? <-- use the path obtained from above $ scilab or $ SCIPATH/scilab 2. If the installed java does not works, try to install the openjdk-11 jre $ sudo apt-get install openjdk-11-jre repeat the export and run the scilab again. If it works, u could set the JAVA_HOME path at .bashrc to make it permanent Hope this helps. rgds, CL ---- On Fri, 27 Dec 2019 05:26:39 +0800 Antoine Monmayrant wrote ---- I just tried on an ubuntu 18.04.3 (not a clean install, un upgrade from 17.10) and it worked without any issue. Can you try to install a vm on your current setup and run an ubuntu live-cd and install scilab in it to see whether the problem is still there? Antoine Le Mardi, D?cembre 24, 2019 13:48 CET, Samuel Enibe a ?crit: > Thanks Antoine. > I didn't change the default settings on UBUNTU 18.04 LTS. > > I have checked again and seen that SCILAB 6.0.1 works but doesn't support > ATOMS. > > The 6.0.2 was downloaded, the files extracted and placed in the default > folder just as I did for 6.0.1. Should it be extracted using a special > command? > > Samuel > > On Tue, 24 Dec 2019, 13:39 Antoine Monmayrant, wrote: > > > Hello Samuel, > > > > I am running 6.0.2 under ubuntu 64bits and I don't remember having this > > issue. > > Is your ubuntu install a vanilla one or did you change some default > > settings regarding java? > > > > We can try to compare our settings if this can help. > > > > Antoine > > > > > > Le Mardi, D?cembre 24, 2019 13:13 CET, Samuel Enibe < > > samuel.enibe at unn.edu.ng> a ?crit: > > > > > I have been using SCILAB for several years now on UBUNTU and decided to > > try > > > the latest version today. > > > > > > Thus, I downloaded the 64 bit version of SCILAB 6.0.2 for LINUX and > > tried > > > to run on UBUNTU 18.04 LTS. > > > > > > It produces the following error > > > > > > scilab-bin: error while loading shared libraries: libjava.so: cannot open > > > shared object file: No such file or directory > > > > > > Is this a bug? I had the same experience with version 6.0.1 > > > > > > Any suggestions on the way out? > > > > > > Samuel Ogbonna Enibe > > > University of Nigeria, Nsukka, Nigeria > > > > _______________________________________________ > > users mailing list > > users at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/users > > _______________________________________________ users mailing list users at lists.scilab.org http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From j-lan at online.no Fri Dec 27 20:34:24 2019 From: j-lan at online.no (=?UTF-8?Q?Jan_=c3=85ge_Langeland?=) Date: Fri, 27 Dec 2019 20:34:24 +0100 Subject: [Scilab-users] find name / path of open file In-Reply-To: References: <281229a1-0a35-7cd8-7b47-d3c300fd5519@fceia.unr.edu.ar> <602e6c2d-6eb1-6ad5-6b48-76ac86373b08@online.no> Message-ID: <8ab8cf59-5d94-8916-ec05-02c9ccc8fa5e@online.no> Federico Yes, I thought that would be easier. But still not as good as it could be, as it is difficult to use these function calls directly in expressions. This is the way I think it should be done in Scilab 6: function fp=fparts(fid) [a,b,fpne,d,e]=file(fid); [pathname,filename,extname]=fileparts(fpne); fp=list(fpne,pathname,filename,extname); endfunction fparts(fid)(1)// full path/filename.ext fparts(fid)(2)// path fparts(fid)(3)// filename fparts(fid)(4)// extension Jan On 2019-12-27 17:00 PM, Federico Miyara wrote: > > Jan, > > Oh, thanks! That's much better than dispfiles, since it gives the name > as a variable. I had seen that function but somehow I didn't realize > that possibility. > > Regards, > > Federico Miyara > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Sat Dec 28 04:48:26 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Sat, 28 Dec 2019 00:48:26 -0300 Subject: [Scilab-users] wav files Message-ID: <13211eb2-14f6-d45d-d603-52c2ad3a4a92@fceia.unr.edu.ar> Dear all, Wav files usually contain PCM data, but they can also work as containers of other formats, such as compressed audio, for instance A-Law, Mu-Law, ADPCM or even MP3 or FLAC. There are over 200 registered format tags, however Scilab only accepts 2, integer PCM and 32 bit float PCM. It would be useful to have sample files to test, analyze and experiment with, particularly if someone would like to expand the support of Scilab's wadread. However, most audio software, including the open source Audacity, only creates PCM wav files. Other formats such as MP3 are exported under their own non-RIFF extension. I can export to ADPCM, A_Law and Mu-Law wav files using an old (non free) application calledCool Edit 2000 Is anybody aware of a free software capable of exporting more formats to the wav container? Regards, Federico Miyara -------------- next part -------------- An HTML attachment was scrubbed... URL: From perrichon.pierre at wanadoo.fr Sat Dec 28 10:33:37 2019 From: perrichon.pierre at wanadoo.fr (Perrichon) Date: Sat, 28 Dec 2019 10:33:37 +0100 Subject: [Scilab-users] C source directory doesn't exist in SCI/modules/scicos_blocks/src/c/ Message-ID: Hello, I was looking for the source file SCI/modules/scicos_blocks/src/c/tows_c.c (Type 4) But in fact, the C directory is not delivered in the windows package, Scilab 5.5.2 or 6.0.2 Must I write a bugzilla ? (type help on tows_c on the component into the Xcos workspace) Best regard -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Sat Dec 28 10:42:11 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 28 Dec 2019 10:42:11 +0100 Subject: [Scilab-users] C source directory doesn't exist in SCI/modules/scicos_blocks/src/c/ In-Reply-To: References: Message-ID: <231ac425-ed88-f839-cc34-ed11bbef957c@free.fr> Le 28/12/2019 ? 10:33, Perrichon a ?crit?: > > Hello, > > I was looking for the source file > SCI/modules/scicos_blocks/src/c/tows_c.c (Type 4) > > But in fact, the C directory is not delivered in the windows package, > Scilab 5.5.2 or 6.0.2 > Only .sci source files are delivered with the binary scilab, in the macros directories. To get all source files (help pages, C, C++, Java, Fortran codes, etc), the sources archive must be downloaded and browsed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Sat Dec 28 10:44:54 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 28 Dec 2019 10:44:54 +0100 Subject: [Scilab-users] wav files In-Reply-To: <13211eb2-14f6-d45d-d603-52c2ad3a4a92@fceia.unr.edu.ar> References: <13211eb2-14f6-d45d-d603-52c2ad3a4a92@fceia.unr.edu.ar> Message-ID: <652e51ca-a49e-ace9-0ce6-4b3bcd9d82a5@free.fr> Le 28/12/2019 ? 04:48, Federico Miyara a ?crit?: > > Dear all, > > Wav files usually contain PCM data, but they can also work as > containers of other formats, such as compressed audio, for instance > A-Law, Mu-Law, ADPCM or even MP3 or FLAC. There are over 200 > registered format tags, however Scilab only accepts 2, integer PCM and > 32 bit float PCM. > > It would be useful to have sample files to test, analyze and > experiment with, particularly if someone would like to expand the > support of Scilab's wadread. However, most audio software, including > the open source Audacity, only creates PCM wav files. Other formats > such as MP3 are exported under their own non-RIFF extension. > > I can export to ADPCM, A_Law and Mu-Law wav files using an old (non > free) application calledCool Edit 2000 > > Is anybody aware of a free software capable of exporting more formats > to the wav container? Federico, There is an ongoing work to interface Scilab with SoX. Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From perrichon.pierre at wanadoo.fr Sat Dec 28 10:55:10 2019 From: perrichon.pierre at wanadoo.fr (Perrichon) Date: Sat, 28 Dec 2019 10:55:10 +0100 Subject: [Scilab-users] C source directory doesn't exist in SCI/modules/scicos_blocks/src/c/ In-Reply-To: <231ac425-ed88-f839-cc34-ed11bbef957c@free.fr> References: <231ac425-ed88-f839-cc34-ed11bbef957c@free.fr> Message-ID: Hello Samuel Tanks for your response, but dowlnoad the source is no more available in the new scilab distribution site. In the past, it was possible, but now how to access the Source files ? Regards De : users De la part de Samuel Gougeon Envoy? : samedi 28 d?cembre 2019 10:42 ? : users at lists.scilab.org Objet : Re: [Scilab-users] C source directory doesn't exist in SCI/modules/scicos_blocks/src/c/ Le 28/12/2019 ? 10:33, Perrichon a ?crit : Hello, I was looking for the source file SCI/modules/scicos_blocks/src/c/tows_c.c (Type 4) But in fact, the C directory is not delivered in the windows package, Scilab 5.5.2 or 6.0.2 Only .sci source files are delivered with the binary scilab, in the macros directories. To get all source files (help pages, C, C++, Java, Fortran codes, etc), the sources archive must be downloaded and browsed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Sat Dec 28 11:03:04 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 28 Dec 2019 11:03:04 +0100 Subject: [Scilab-users] C source directory doesn't exist in SCI/modules/scicos_blocks/src/c/ In-Reply-To: References: <231ac425-ed88-f839-cc34-ed11bbef957c@free.fr> Message-ID: Le 28/12/2019 ? 10:55, Perrichon a ?crit?: > > Hello Samuel > > Tanks for your response, but dowlnoad the source is no more available > in the new scilab distribution site. > > In the past, it was possible, but now how to access the Source files?? > Right. Sources archives are now in the "Previous versions" item, what is quite misleading. https://www.scilab.org/previous-scilab-versions -------------- next part -------------- An HTML attachment was scrubbed... URL: From perrichon.pierre at wanadoo.fr Sat Dec 28 12:20:29 2019 From: perrichon.pierre at wanadoo.fr (Perrichon) Date: Sat, 28 Dec 2019 12:20:29 +0100 Subject: [Scilab-users] C source directory doesn't exist in SCI/modules/scicos_blocks/src/c/ In-Reply-To: References: <231ac425-ed88-f839-cc34-ed11bbef957c@free.fr> Message-ID: Thanks you so much Samuel Good WE De : users De la part de Samuel Gougeon Envoy? : samedi 28 d?cembre 2019 11:03 ? : users at lists.scilab.org Objet : Re: [Scilab-users] C source directory doesn't exist in SCI/modules/scicos_blocks/src/c/ Le 28/12/2019 ? 10:55, Perrichon a ?crit : Hello Samuel Tanks for your response, but dowlnoad the source is no more available in the new scilab distribution site. In the past, it was possible, but now how to access the Source files ? Right. Sources archives are now in the "Previous versions" item, what is quite misleading. https://www.scilab.org/previous-scilab-versions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppggbishop at gmail.com Mon Dec 30 12:13:14 2019 From: ppggbishop at gmail.com (Peter Bishop) Date: Mon, 30 Dec 2019 04:13:14 -0700 (MST) Subject: [Scilab-users] Question : XCOS Can't Find WFILE_F.sci In-Reply-To: References: Message-ID: <1577704394332-0.post@n3.nabble.com> Start xcos Open the help browser ("?" on the toolbar) Search for WFILE_F In the WFILE_F help page, scroll down to the Example at the end Click the example to start the xcos demo Drag W_FILE_F block in the demo to a blank xcos page And save the xcos page for future use (e.g. as WFILE_F.zcos) You can use this page as an extra palette to drag and drop the block into other Xcos pages. -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html