From p.muehlmann at gmail.com Tue Jan 4 09:29:15 2022 From: p.muehlmann at gmail.com (P M) Date: Tue, 4 Jan 2022 09:29:15 +0100 Subject: [Scilab-users] question to surf() Message-ID: Dear, is there a limitation for surf(), when displaying big matrices? Background: Imagine an image of size 900 x 1500. Scilab crashes, when I try to display the image using surf(). - I know there is imshow, Matplot etc... - for some cases it is nice to use surf() and take the pixel values as Z-coordinate - especially when the image contains 16 bit information and not 0-255 pixel values Now ... trying to display the image, Scilab closes unexpectedly. Since I can not share the image itself, please see the code below. Scilab does not close with this example, but the figure remains pure white. When choosing smaller values for width/height the code works as expected...e.g.: width = 900, height = 700 Scilab 6.1.0 Win 10 width = 900;height = 1500; x = linspace(1,width,width)y = linspace(1,height, height); for i = 1:width for j = 1:height z(i,j) = x(i)+y(j) endend //// normalization if necessary//zMin = min(z);//z = z - zMin;//zMax = max(z);//z = z .* 255 ./ zMax; f = figure();f.background = 256;f.color_map = hotcolormap(256);surf(x,y,z');e = gce();e.thickness = 0 printf("Reached end of code\n"); Thank you Philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinznabielek at me.com Tue Jan 4 12:22:44 2022 From: heinznabielek at me.com (Heinz Nabielek) Date: Tue, 4 Jan 2022 12:22:44 +0100 Subject: [Scilab-users] question to surf() In-Reply-To: References: Message-ID: <4A09CD8C-C20E-440B-BB1A-732DFF825DE9@me.com> SurfPlot is no problem here. Scilab Version: 6.1.1.988271013 macOS Catalina Version 10.15.7 Heinz > On 04.01.2022, at 09:29, P M wrote: > > width = 900; > height = 1500; > > > > x = linspace(1,width,width) > y = linspace(1,height, height); > > > > for i = 1:width > > > for j = 1:height > > > z(i,j) = x(i)+y(j) > > > end > end > > > > //// normalization if necessary > //zMin = min(z); > //z = z - zMin; > //zMax = max(z); > //z = z .* 255 ./ zMax; > > > > f = figure(); > f.background = 256; > f.color_map = hotcolormap(256); > surf(x,y,z'); > e = gce(); > e.thickness = 0 > printf("Reached end of code\n"); -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-1.png Type: image/png Size: 51979 bytes Desc: not available URL: From p.muehlmann at gmail.com Tue Jan 4 14:29:45 2022 From: p.muehlmann at gmail.com (P M) Date: Tue, 4 Jan 2022 14:29:45 +0100 Subject: [Scilab-users] question to surf() In-Reply-To: <4A09CD8C-C20E-440B-BB1A-732DFF825DE9@me.com> References: <4A09CD8C-C20E-440B-BB1A-732DFF825DE9@me.com> Message-ID: ...indeed..no problems with Scilab 6.1.1 Thank you, Philipp Am Di., 4. Jan. 2022 um 12:22 Uhr schrieb Heinz Nabielek < heinznabielek at me.com>: > SurfPlot is no problem here. > Scilab Version: 6.1.1.988271013 > macOS Catalina Version 10.15.7 > Heinz > > > > > On 04.01.2022, at 09:29, P M wrote: > > width = 900; > height = 1500; > > > > x = linspace(1,width,width) > y = linspace(1,height, height); > > > > for i = 1:width > > > for j = 1:height > > > z(i,j) = x(i)+y(j) > > > end > end > > > > //// normalization if necessary > //zMin = min(z); > //z = z - zMin; > //zMax = max(z); > //z = z .* 255 ./ zMax; > > > > f = figure(); > f.background = 256; > f.color_map = hotcolormap(256); > surf(x,y,z'); > e = gce(); > e.thickness = 0 > printf("Reached end of code\n"); > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-1.png Type: image/png Size: 51979 bytes Desc: not available URL: From sgougeon at free.fr Tue Jan 4 14:36:36 2022 From: sgougeon at free.fr (Samuel Gougeon) Date: Tue, 4 Jan 2022 14:36:36 +0100 Subject: [Scilab-users] question to surf() In-Reply-To: References: <4A09CD8C-C20E-440B-BB1A-732DFF825DE9@me.com> Message-ID: <29929a86-58f9-a4b1-04bd-f8fcd3a79b5f@free.fr> Le 04/01/2022 ? 14:29, P M a ?crit?: > ...indeed..no problems with Scilab 6.1.1 Likely because this example needs a bigger Java heap used for graphics. The default Java heap size has been increased from 256 to 512 MB in 6.1.1, for this kind of example. If you still work with Scilab < 6.1.1, you can increase the heap in your preferences => General Regards Samuel From p.muehlmann at gmail.com Tue Jan 4 18:41:13 2022 From: p.muehlmann at gmail.com (P M) Date: Tue, 4 Jan 2022 18:41:13 +0100 Subject: [Scilab-users] question to surf() In-Reply-To: <29929a86-58f9-a4b1-04bd-f8fcd3a79b5f@free.fr> References: <4A09CD8C-C20E-440B-BB1A-732DFF825DE9@me.com> <29929a86-58f9-a4b1-04bd-f8fcd3a79b5f@free.fr> Message-ID: Yes, that helped. Thank you, Philipp Am Di., 4. Jan. 2022 um 14:37 Uhr schrieb Samuel Gougeon : > Le 04/01/2022 ? 14:29, P M a ?crit : > > ...indeed..no problems with Scilab 6.1.1 > > > Likely because this example needs a bigger Java heap used for graphics. > The default Java heap size has been increased from 256 to 512 MB in > 6.1.1, for this kind of example. > If you still work with Scilab < 6.1.1, you can increase the heap in your > preferences => General > > 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 arctica1963 at gmail.com Wed Jan 5 09:46:47 2022 From: arctica1963 at gmail.com (Lester Anderson) Date: Wed, 5 Jan 2022 08:46:47 +0000 Subject: [Scilab-users] Cauchy Integral query Message-ID: Hello, I am trying to understand how to work the Cauchy integral inputs and replicate the results of a published example: .e.g. Compute the integral of e^(z^2) / (z-2) assumes C is closed (anticlockwise) and z=2 is inside C (a simple circle). The solution should be 2*pi*i*f(2) = 2*pi*i*e^4 In Scilab, the solution is defined from the Cauchy Integral (intl): y = intl(a, b, z0, r, f) a and b are real and z complex function y=f(z) y = exp((z^2)) // solution uses f(z) = e^(z^2) endfunction fz=intl(0, 2*%pi, 2+0*%i, 1, f) // gives round-off error // z position +2(real z), 0(imaginary z) Probably not setting up the inputs correctly; any guidance would be helpful. All a learning exercise. Thanks Lester -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Cauchy integral.PNG Type: image/png Size: 28459 bytes Desc: not available URL: From fujimoto2005 at gmail.com Wed Jan 5 09:58:35 2022 From: fujimoto2005 at gmail.com (Masahiro Fujimoto) Date: Wed, 5 Jan 2022 17:58:35 +0900 Subject: [Scilab-users] GPU in scilab Message-ID: I would like to use scilab6.1.1 to do fast numerical computation with GPU and is looking for the tool. Two candidate sciGPPU and sciGPGPU are not supported nowadays. If anyone knows the other tool, please let me know. Best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Jan 5 14:31:24 2022 From: sgougeon at free.fr (sgougeon at free.fr) Date: Wed, 5 Jan 2022 14:31:24 +0100 (CET) Subject: [Scilab-users] =?utf-8?q?Re=C2=A0=3A__Cauchy_Integral_query?= In-Reply-To: Message-ID: <1781770341.590099594.1641389484525.JavaMail.root@zimbra75-e12.priv.proxad.net> Hello Lester, The integrand is y = exp((z^2))/(z-2), not y = exp((z^2)). Then, provided that the (undocumented) absolute tolerance is increased wrt the default one, we get the expected result: --> function y=f(z) > y = exp((z.^2))./(z-2) > endfunction --> fz=intl(0, 2*%pi, 2, 1, f,1e-10) // gives round-off error fz = 4.199D-13 + 343.05029i --> 2*%pi*%i*%e^4 ans = 0. + 343.05029i Regards Samuel > ----- Mail d'origine ----- > De: Lester Anderson > Envoy?: Wed, 05 Jan 2022 09:46:47 +0100 (CET) > > Hello, > > I am trying to understand how to work the Cauchy integral inputs and > replicate the results of a published example: > > .e.g. Compute the integral of e^(z^2) / (z-2) assumes C is closed > (anticlockwise) and z=2 is inside C (a simple circle). The solution should > be 2*pi*i*f(2) = 2*pi*i*e^4 > > In Scilab, the solution is defined from the Cauchy Integral (intl): > y = intl(a, b, z0, r, f) > a and b are real and z complex > > function y=f(z) > y = exp((z^2)) // solution uses f(z) = e^(z^2) > endfunction > > fz=intl(0, 2*%pi, 2+0*%i, 1, f) // gives round-off error > // z position +2(real z), 0(imaginary z) > From arctica1963 at gmail.com Wed Jan 5 14:44:48 2022 From: arctica1963 at gmail.com (Lester Anderson) Date: Wed, 5 Jan 2022 13:44:48 +0000 Subject: [Scilab-users] Cauchy Integral query In-Reply-To: <1781770341.590099594.1641389484525.JavaMail.root@zimbra75-e12.priv.proxad.net> References: <1781770341.590099594.1641389484525.JavaMail.root@zimbra75-e12.priv.proxad.net> Message-ID: Many thanks Samuel. Happy New Year! Lester On Wed, 5 Jan 2022 at 13:32, wrote: > Hello Lester, > > The integrand is y = exp((z^2))/(z-2), not y = exp((z^2)). > Then, provided that the (undocumented) absolute tolerance is increased wrt > the default one, > we get the expected result: > > --> function y=f(z) > > y = exp((z.^2))./(z-2) > > endfunction > > --> fz=intl(0, 2*%pi, 2, 1, f,1e-10) // gives round-off error > fz = > 4.199D-13 + 343.05029i > > --> 2*%pi*%i*%e^4 > ans = > 0. + 343.05029i > > Regards > Samuel > > > ----- Mail d'origine ----- > > De: Lester Anderson > > Envoy?: Wed, 05 Jan 2022 09:46:47 +0100 (CET) > > > > Hello, > > > > I am trying to understand how to work the Cauchy integral inputs and > > replicate the results of a published example: > > > > .e.g. Compute the integral of e^(z^2) / (z-2) assumes C is closed > > (anticlockwise) and z=2 is inside C (a simple circle). The solution > should > > be 2*pi*i*f(2) = 2*pi*i*e^4 > > > > In Scilab, the solution is defined from the Cauchy Integral (intl): > > y = intl(a, b, z0, r, f) > > a and b are real and z complex > > > > function y=f(z) > > y = exp((z^2)) // solution uses f(z) = e^(z^2) > > endfunction > > > > fz=intl(0, 2*%pi, 2+0*%i, 1, f) // gives round-off error > > // z position +2(real z), 0(imaginary z) > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinznabielek at me.com Wed Jan 5 14:45:51 2022 From: heinznabielek at me.com (Heinz Nabielek) Date: Wed, 5 Jan 2022 14:45:51 +0100 Subject: [Scilab-users] Cauchy Integral query In-Reply-To: <1781770341.590099594.1641389484525.JavaMail.root@zimbra75-e12.priv.proxad.net> References: <1781770341.590099594.1641389484525.JavaMail.root@zimbra75-e12.priv.proxad.net> Message-ID: Is there a reason that my round-off error is 2.831D-13 ? Is there a way to get SciLab to print always 2.831e-13 so that I can copy numbers over to EXCEL? Heinz --> function y=f(z) > y = exp((z.^2))./(z-2) > endfunction --> fz=intl(0, 2*%pi, 2, 1, f,1e-10) // gives round-off error fz = 2.831D-13 + 343.05029i --> 2*%pi*%i*%e^4 ans = 0. + 343.05029i Scilab Version: 6.1.1.988271013 macOS Catalina Version 10.15.7 ______________- > On 05.01.2022, at 14:31, sgougeon at free.fr wrote: > > Hello Lester, > > The integrand is y = exp((z^2))/(z-2), not y = exp((z^2)). > Then, provided that the (undocumented) absolute tolerance is increased wrt the default one, > we get the expected result: > > --> function y=f(z) >> y = exp((z.^2))./(z-2) >> endfunction > > --> fz=intl(0, 2*%pi, 2, 1, f,1e-10) // gives round-off error > fz = > 4.199D-13 + 343.05029i > > --> 2*%pi*%i*%e^4 > ans = > 0. + 343.05029i > > Regards > Samuel > >> ----- Mail d'origine ----- >> De: Lester Anderson >> Envoy?: Wed, 05 Jan 2022 09:46:47 +0100 (CET) >> >> Hello, >> >> I am trying to understand how to work the Cauchy integral inputs and >> replicate the results of a published example: >> >> .e.g. Compute the integral of e^(z^2) / (z-2) assumes C is closed >> (anticlockwise) and z=2 is inside C (a simple circle). The solution should >> be 2*pi*i*f(2) = 2*pi*i*e^4 >> >> In Scilab, the solution is defined from the Cauchy Integral (intl): >> y = intl(a, b, z0, r, f) >> a and b are real and z complex >> >> function y=f(z) >> y = exp((z^2)) // solution uses f(z) = e^(z^2) >> endfunction >> >> fz=intl(0, 2*%pi, 2+0*%i, 1, f) // gives round-off error >> // z position +2(real z), 0(imaginary z) >> > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users From heinznabielek at me.com Wed Jan 5 15:49:46 2022 From: heinznabielek at me.com (Heinz Nabielek) Date: Wed, 5 Jan 2022 15:49:46 +0100 Subject: [Scilab-users] Linear Least-Squares Fitting In-Reply-To: References: Message-ID: <6DEF2E9E-3767-4A7D-9695-17E0036C71F9@me.com> Scilab can easily do linear least-squares fitting by inversion of a rectangular matrix, like so: np = 100; noise = 0.7*(rand(np,1)-0.5); x = linspace(0,2,np)'; yexact = x.^2 + x; // representing the underlying correlation ynoise = yexact + noise; // representing the measured data M=[x x^2]; // rectangular matrix Fitted_Constants=M\ynoise // matrix inversion yielding 0.9665752 and 1.0254576 plot(x,yexact,'k-'); plot(x,ynoise,'r.'); plot(x,M*Fitted_Constants,'g+','Markersize',15);xgrid; xtitle('Linear Least Squares Fitting','x-values','y-values'); legend("Underlying Correlation", "Original Measured Statistical Data", "Fitted Data by Matrix Inversion", 2); And it is fast, precise and efficient. And - again without any support functions - I can add a 95% confidence range arount the fit. Why do so many Scilab tutorials obfuscate the issue by raising all sorts of functions? E.g., why on earth would I want polyfit and horner ? See below. Heinz np = 100; noise = 0.7*(rand(np,1)-0.5); x = linspace(0,2,np)'; yexact = x.^2 + x; ynoise = yexact + noise; // degree 1 approximation p1 = polyfit(x, ynoise, 1); p1val = horner(p1,x); scf(10); clf(10); plot(x,yexact,'k-'); plot(x,ynoise,'b-'); plot(x,p1val,'r-'); From arctica1963 at gmail.com Wed Jan 5 17:39:04 2022 From: arctica1963 at gmail.com (Lester Anderson) Date: Wed, 5 Jan 2022 16:39:04 +0000 Subject: [Scilab-users] Cauchy Integral query In-Reply-To: References: <1781770341.590099594.1641389484525.JavaMail.root@zimbra75-e12.priv.proxad.net> Message-ID: I just checked my version and result: 2.154D-13 + 343.05029i --> [version, options] = getversion() version = "scilab-6.1.1" options = "VC++" "x64" "tk" "release" "Jul 15 2021" "15:32:10" Windows 10 Lester On Wed, 5 Jan 2022 at 13:45, Heinz Nabielek wrote: > Is there a reason that my round-off error is 2.831D-13 ? > > Is there a way to get SciLab to print always 2.831e-13 so that I can copy > numbers over to EXCEL? > > Heinz > > > --> function y=f(z) > > y = exp((z.^2))./(z-2) > > endfunction > > --> fz=intl(0, 2*%pi, 2, 1, f,1e-10) // gives round-off error > fz = 2.831D-13 + 343.05029i > > --> 2*%pi*%i*%e^4 > ans = 0. + 343.05029i > > Scilab Version: 6.1.1.988271013 > macOS Catalina Version 10.15.7 > > > ______________- > > > On 05.01.2022, at 14:31, sgougeon at free.fr wrote: > > > > Hello Lester, > > > > The integrand is y = exp((z^2))/(z-2), not y = exp((z^2)). > > Then, provided that the (undocumented) absolute tolerance is increased > wrt the default one, > > we get the expected result: > > > > --> function y=f(z) > >> y = exp((z.^2))./(z-2) > >> endfunction > > > > --> fz=intl(0, 2*%pi, 2, 1, f,1e-10) // gives round-off error > > fz = > > 4.199D-13 + 343.05029i > > > > --> 2*%pi*%i*%e^4 > > ans = > > 0. + 343.05029i > > > > Regards > > Samuel > > > >> ----- Mail d'origine ----- > >> De: Lester Anderson > >> Envoy?: Wed, 05 Jan 2022 09:46:47 +0100 (CET) > >> > >> Hello, > >> > >> I am trying to understand how to work the Cauchy integral inputs and > >> replicate the results of a published example: > >> > >> .e.g. Compute the integral of e^(z^2) / (z-2) assumes C is closed > >> (anticlockwise) and z=2 is inside C (a simple circle). The solution > should > >> be 2*pi*i*f(2) = 2*pi*i*e^4 > >> > >> In Scilab, the solution is defined from the Cauchy Integral (intl): > >> y = intl(a, b, z0, r, f) > >> a and b are real and z complex > >> > >> function y=f(z) > >> y = exp((z^2)) // solution uses f(z) = e^(z^2) > >> endfunction > >> > >> fz=intl(0, 2*%pi, 2+0*%i, 1, f) // gives round-off error > >> // z position +2(real z), 0(imaginary z) > >> > > _______________________________________________ > > users mailing list > > users at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinznabielek at me.com Wed Jan 5 17:47:38 2022 From: heinznabielek at me.com (Heinz Nabielek) Date: Wed, 5 Jan 2022 17:47:38 +0100 Subject: [Scilab-users] Cauchy Integral query In-Reply-To: References: <1781770341.590099594.1641389484525.JavaMail.root@zimbra75-e12.priv.proxad.net> Message-ID: <78F52AEE-6DBC-43DD-B436-3F5553B0C594@me.com> interesting... > On 05.01.2022, at 17:39, Lester Anderson wrote: > > I just checked my version and result: > > 2.154D-13 + 343.05029i > > --> [version, options] = getversion() > version = "scilab-6.1.1" > options = "VC++" "x64" "tk" "release" "Jul 15 2021" "15:32:10" > > Windows 10 > > Lester > > > > On Wed, 5 Jan 2022 at 13:45, Heinz Nabielek wrote: > Is there a reason that my round-off error is 2.831D-13 ? > > Is there a way to get SciLab to print always 2.831e-13 so that I can copy numbers over to EXCEL? > > Heinz > > > --> function y=f(z) > > y = exp((z.^2))./(z-2) > > endfunction > > --> fz=intl(0, 2*%pi, 2, 1, f,1e-10) // gives round-off error > fz = 2.831D-13 + 343.05029i > > --> 2*%pi*%i*%e^4 > ans = 0. + 343.05029i > > Scilab Version: 6.1.1.988271013 > macOS Catalina Version 10.15.7 > > > ______________- > > > On 05.01.2022, at 14:31, sgougeon at free.fr wrote: > > > > Hello Lester, > > > > The integrand is y = exp((z^2))/(z-2), not y = exp((z^2)). > > Then, provided that the (undocumented) absolute tolerance is increased wrt the default one, > > we get the expected result: > > > > --> function y=f(z) > >> y = exp((z.^2))./(z-2) > >> endfunction > > > > --> fz=intl(0, 2*%pi, 2, 1, f,1e-10) // gives round-off error > > fz = > > 4.199D-13 + 343.05029i > > > > --> 2*%pi*%i*%e^4 > > ans = > > 0. + 343.05029i > > > > Regards > > Samuel > > > >> ----- Mail d'origine ----- > >> De: Lester Anderson > >> Envoy?: Wed, 05 Jan 2022 09:46:47 +0100 (CET) > >> > >> Hello, > >> > >> I am trying to understand how to work the Cauchy integral inputs and > >> replicate the results of a published example: > >> > >> .e.g. Compute the integral of e^(z^2) / (z-2) assumes C is closed > >> (anticlockwise) and z=2 is inside C (a simple circle). The solution should > >> be 2*pi*i*f(2) = 2*pi*i*e^4 > >> > >> In Scilab, the solution is defined from the Cauchy Integral (intl): > >> y = intl(a, b, z0, r, f) > >> a and b are real and z complex > >> > >> function y=f(z) > >> y = exp((z^2)) // solution uses f(z) = e^(z^2) > >> endfunction > >> > >> fz=intl(0, 2*%pi, 2+0*%i, 1, f) // gives round-off error > >> // z position +2(real z), 0(imaginary z) > >> > > _______________________________________________ > > users mailing list > > users at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/users > From Serge.Steer at laposte.net Thu Jan 6 11:56:51 2022 From: Serge.Steer at laposte.net (Steer Serge) Date: Thu, 6 Jan 2022 11:56:51 +0100 Subject: [Scilab-users] Scilab application and File association Message-ID: Hello, I have developped a Scilab application which defines/uses? files with specific extensions. I would like to be able to associate? an action like scilab -e "StartMyApplication(file)" when a user double click on one of these files. It works fine when I? defines the association by hand.? Is it possible to write a script (linux, windows, mac,... ) which can be used for that purpose? Thanks Serge Steer From sgougeon at free.fr Sat Jan 15 23:17:51 2022 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 15 Jan 2022 23:17:51 +0100 Subject: [Scilab-users] Direct file access with write(fid,a,k,fm) ? Message-ID: Dear co-Scilabers, In the help page of the write() function @ https://help.scilab.org/docs/6.1.1/en_US/write.html, an enigmatic sentence somewhat describes a interesting writing mode: " /Direct access files : x = write(file_desc, a, k, format). Here k is the vector of records (one record// //?by row, i.e. m = prod(size(k))// / "/Direct access/ can be very useful, in order to write only targeted records, instead of the whole file. But here this description looks completely obscure to me, and there is no related example. I have tried many things using such a syntax with a text file, for instance with the following example, and all of them fail: a = rand(5,3)*100; File = "write_test.txt"; mdelete(File); fm = "(3(2x,f4.0))"; // 3*(2+4) = 18 bytes / row write(File, a, fm); fid = file("open",File,"unknown","direct",18); k = [3 4]; b = -a(k,:); write(fid, b, k, fm); file('close',fid) This yields an error: --> write(fid, b, k, fm) Incorrect file or format. Would anyone have any hints about this syntax, noticeably about the /k/ and /m/ meanings? Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfuttrup at gmail.com Fri Jan 21 20:58:52 2022 From: cfuttrup at gmail.com (Claus Futtrup) Date: Fri, 21 Jan 2022 20:58:52 +0100 Subject: [Scilab-users] xdel replaced by close() Message-ID: <7e9a0cb1-ba6b-606b-021d-3e257ead55ff@gmail.com> Hi Scilabers Today I tried to replace xdel(winsid()) in one of my scripts with close(winsid()) because Scilab shows a warning in the console: Warning: Feature xdel(...) is obsolete and will be permanently removed in Scilab 6.2 Warning: Please use close(...) instead. I am negatively surprised that the close() command takes a long time to execute with 5-10 windows open (a few seconds per window). The xdel() command can do it in a split second. What is the motivation for replacing xdel with close? Are there any plans to speed up the close() function? Best regards, Claus From sgougeon at free.fr Fri Jan 21 23:54:18 2022 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 21 Jan 2022 23:54:18 +0100 Subject: [Scilab-users] xdel replaced by close() In-Reply-To: <7e9a0cb1-ba6b-606b-021d-3e257ead55ff@gmail.com> References: <7e9a0cb1-ba6b-606b-021d-3e257ead55ff@gmail.com> Message-ID: <09397d88-fdcb-9fba-da6f-ee7911a21646@free.fr> Hello Claus, Le 21/01/2022 ? 20:58, Claus Futtrup a ?crit?: > Hi Scilabers > > Today I tried to replace xdel(winsid()) in one of my scripts with > close(winsid()) because Scilab shows a warning in the console: > > Warning: Feature xdel(...) is obsolete and will be permanently removed > in Scilab 6.2 > > Warning: Please use close(...) instead. > > I am negatively surprised that the close() command takes a long time > to execute with 5-10 windows open (a few seconds per window). The > xdel() command can do it in a split second. > The issue comes not from close() but from the change offindobj() that it calls , noticeably to perform findobj("figure_id",id) in 6.1.1. It does not impact only close() for this case, that was processed as a special accelerated case in the former findobj(). This downgradingwas reported 7 months before releasing 6.1.1, and knowingly ignored, while it is perfectly fixable by restoring the fast special case. > > What is the motivation for replacing xdel with close? Both do the same thing. Scilab does not need duplicates. Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdr at durietz.se Sat Jan 22 10:55:44 2022 From: sdr at durietz.se (Stefan Du Rietz) Date: Sat, 22 Jan 2022 10:55:44 +0100 Subject: [Scilab-users] xdel replaced by close() In-Reply-To: <09397d88-fdcb-9fba-da6f-ee7911a21646@free.fr> References: <7e9a0cb1-ba6b-606b-021d-3e257ead55ff@gmail.com> <09397d88-fdcb-9fba-da6f-ee7911a21646@free.fr> Message-ID: Hello, On 2022-01-21 23:54, Samuel Gougeon wrote: > Hello Claus, > > Le 21/01/2022 ? 20:58, Claus Futtrup a ?crit?: >> Hi Scilabers >> >> Today I tried to replace xdel(winsid()) in one of my scripts with >> close(winsid()) because Scilab shows a warning in the console: >> >> Warning: Feature xdel(...) is obsolete and will be permanently removed >> in Scilab 6.2 >> >> Warning: Please use close(...) instead. >> >> I am negatively surprised that the close() command takes a long time >> to execute with 5-10 windows open (a few seconds per window). The >> xdel() command can do it in a split second. >> > > The issue comes not from close() but from the change offindobj() that it > calls , noticeably > to perform findobj("figure_id",id) in 6.1.1. > It does not impact only close() for > this case, that was processed as a special accelerated case > > in the former findobj(). > > This downgradingwas reported > 7 months before > releasing 6.1.1, and knowingly ignored, while it is perfectly fixable by > restoring the fast special case. > > >> >> What is the motivation for replacing xdel with close? > > Both do the same thing. Scilab does not need duplicates. > > Regards > Samuel > > scf(id) is much faster than findobj("figure_id",id) --> winsid() ans = 0. 1. --> tic, f = []; for k=winsid(), f = [findobj("figure_id",k); f]; end, toc ans = 0.281087 --> tic, f = []; for k=winsid(), f = [scf(k); f]; end, toc ans = 0.000237 So, this is how to do it: --> for k=winsid(), delete(scf(k)); end Regards Stefan From stephane.mottelet at utc.fr Sat Jan 22 14:24:20 2022 From: stephane.mottelet at utc.fr (=?utf-8?Q?St=C3=A9phane_Mottelet?=) Date: Sat, 22 Jan 2022 14:24:20 +0100 Subject: [Scilab-users] xdel replaced by close() In-Reply-To: <09397d88-fdcb-9fba-da6f-ee7911a21646@free.fr> References: <09397d88-fdcb-9fba-da6f-ee7911a21646@free.fr> Message-ID: Hi, This is fixed for the next release: https://codereview.scilab.org/#/c/21803/ In the meantime, if you really need it you can download the patched version of findobj. S. > Le 21 janv. 2022 ? 23:54, Samuel Gougeon a ?crit : > > ? > Hello Claus, > >> Le 21/01/2022 ? 20:58, Claus Futtrup a ?crit : >> Hi Scilabers >> >> Today I tried to replace xdel(winsid()) in one of my scripts with close(winsid()) because Scilab shows a warning in the console: >> >> Warning: Feature xdel(...) is obsolete and will be permanently removed in Scilab 6.2 >> >> Warning: Please use close(...) instead. >> >> I am negatively surprised that the close() command takes a long time to execute with 5-10 windows open (a few seconds per window). The xdel() command can do it in a split second. >> > > The issue comes not from close() but from the change of findobj() that it calls, noticeably to perform findobj("figure_id",id) in 6.1.1. > It does not impact only close() for this case, that was processed as a special accelerated case in the former findobj(). > This downgrading was reported 7 months before releasing 6.1.1, and knowingly ignored, while it is perfectly fixable by restoring the fast special case. > > >> >> What is the motivation for replacing xdel with close? > > Both do the same thing. Scilab does not need duplicates. > > 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 cfuttrup at gmail.com Sat Jan 22 15:21:33 2022 From: cfuttrup at gmail.com (Claus Futtrup) Date: Sat, 22 Jan 2022 15:21:33 +0100 Subject: [Scilab-users] xdel replaced by close() In-Reply-To: References: <09397d88-fdcb-9fba-da6f-ee7911a21646@free.fr> Message-ID: <5068f9d7-063e-1bbd-c358-857c14c023d3@gmail.com> Hi Stephane Good news, thank you. Thank you to the other list members for the other responses as well. Best regards, Claus On 22-01-2022 14:24, St?phane Mottelet wrote: > Hi, > > This is fixed for the next release: > > https://codereview.scilab.org/#/c/21803/ > > In the meantime, if you really need it you can download the patched > version of findobj. > > S. > >> Le 21 janv. 2022 ? 23:54, Samuel Gougeon a ?crit?: >> >> ? >> Hello Claus, >> >> Le 21/01/2022 ? 20:58, Claus Futtrup a ?crit?: >>> Hi Scilabers >>> >>> Today I tried to replace xdel(winsid()) in one of my scripts with >>> close(winsid()) because Scilab shows a warning in the console: >>> >>> Warning: Feature xdel(...) is obsolete and will be permanently >>> removed in Scilab 6.2 >>> >>> Warning: Please use close(...) instead. >>> >>> I am negatively surprised that the close() command takes a long time >>> to execute with 5-10 windows open (a few seconds per window). The >>> xdel() command can do it in a split second. >>> >> >> The issue comes not from close() but from the change offindobj() that >> it calls , >> noticeably to perform findobj("figure_id",id) in 6.1.1. >> It does not impact only close() >> for this case, that was processed as a special accelerated case >> >> in the former findobj(). >> >> This downgradingwas reported >> 7 months before >> releasing 6.1.1, and knowingly ignored, while it is perfectly fixable >> by restoring the fast special case. >> >> >>> >>> What is the motivation for replacing xdel with close? >> >> Both do the same thing. Scilab does not need duplicates. >> >> Regards >> Samuel >> >> _______________________________________________ >> 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 stephane.mottelet at utc.fr Sat Jan 22 22:26:19 2022 From: stephane.mottelet at utc.fr (Stephane Mottelet) Date: Sat, 22 Jan 2022 22:26:19 +0100 Subject: [Scilab-users] xdel replaced by close() In-Reply-To: References: <09397d88-fdcb-9fba-da6f-ee7911a21646@free.fr> Message-ID: <322f6942442b5d21732b49e603c6548e@utc.fr> However, the findobj() fix that has been recently merged by Cl?ment restores only the speed of tags search. findbobj() won't be further fixed as it provides many useful features which were missing to its (fast but poor) previous version. Indeed, using findobj to get the handle of a figure knowing its id is the most complicated that one can imagine. It sounds to me like the affirmation: ? why make it simple when it can be made complicated ?... I mean, close() has to be fixed to use scf() as proposed in this thread. Sometimes adding useful and needed features can degrade the speed of a function (you can't make an omelette without breaking eggs). Finding handles given their tag has its original performance with this patch. But I repeat that h=findobj('figure_id",id) should be avoided in favour of h=scf(id), until findobj() is completely rewritten in C++ (which is planned). Moreover nobody was complaining about xdel() and making it deprecated was never discussed by the community. Many people don't use Scilab any more because it misses features. So Scilab needs features, not absurde/arbitrary cleaning . A word to the wise... S. Le 2022-01-22 14:24, St?phane Mottelet a ?crit : > Hi, > > This is fixed for the next release: > > https://codereview.scilab.org/#/c/21803/ [1] > > In the meantime, if you really need it you can download the patched > version of findobj. > > S. > >> Le 21 janv. 2022 ? 23:54, Samuel Gougeon a ?crit : > > Hello Claus, > > Le 21/01/2022 ? 20:58, Claus Futtrup a ?crit : Hi Scilabers > > Today I tried to replace xdel(winsid()) in one of my scripts with > close(winsid()) because Scilab shows a warning in the console: > > Warning: Feature xdel(...) is obsolete and will be permanently removed > in Scilab 6.2 > > Warning: Please use close(...) instead. > > I am negatively surprised that the close() command takes a long time to > execute with 5-10 windows open (a few seconds per window). The xdel() > command can do it in a split second. > > The issue comes not from close() but from the change of findobj() that > it calls [2], noticeably to perform findobj("figure_id",id) in 6.1.1. > It does not impact only [3] close() for this case, that was processed > as a special accelerated case [4] in the former findobj(). > This downgrading was reported [5] 7 months before releasing 6.1.1, and > knowingly ignored, while it is perfectly fixable by restoring the fast > special case. > > What is the motivation for replacing xdel with close? > Both do the same thing. Scilab does not need duplicates. > > Regards > Samuel > > _______________________________________________ > 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/v3?i=SGI0YVJGNmxZNE90Z2thMFYLWSxJOfIERJocpmb73Vs&r=SW5LV3JodE9QZkRVZ3JEYbCxfBpXCzNXFJI9eyEBCB_E8EQzXar_oWBGCSukLx6I&f=bnJjU3hQT3pQSmNQZVE3aPQ56ZBjot0Lu_H1dlHvp1727w_z78BVJc295PQlt99Z&u=http%3A//lists.scilab.org/mailman/listinfo/users&k=dFBm Links: ------ [1] https://antispam.utc.fr/proxy/v3?i=SGI0YVJGNmxZNE90Z2thMFYLWSxJOfIERJocpmb73Vs&r=SW5LV3JodE9QZkRVZ3JEYbCxfBpXCzNXFJI9eyEBCB_E8EQzXar_oWBGCSukLx6I&f=bnJjU3hQT3pQSmNQZVE3aPQ56ZBjot0Lu_H1dlHvp1727w_z78BVJc295PQlt99Z&u=https%3A//codereview.scilab.org/%23/c/21803/&k=dFBm [2] https://antispam.utc.fr/proxy/v3?i=SGI0YVJGNmxZNE90Z2thMFYLWSxJOfIERJocpmb73Vs&r=SW5LV3JodE9QZkRVZ3JEYbCxfBpXCzNXFJI9eyEBCB_E8EQzXar_oWBGCSukLx6I&f=bnJjU3hQT3pQSmNQZVE3aPQ56ZBjot0Lu_H1dlHvp1727w_z78BVJc295PQlt99Z&u=http%3A//bugzilla.scilab.org/show_bug.cgi%3Fid%3D13738%23c4&k=dFBm [3] https://antispam.utc.fr/proxy/v3?i=SGI0YVJGNmxZNE90Z2thMFYLWSxJOfIERJocpmb73Vs&r=SW5LV3JodE9QZkRVZ3JEYbCxfBpXCzNXFJI9eyEBCB_E8EQzXar_oWBGCSukLx6I&f=bnJjU3hQT3pQSmNQZVE3aPQ56ZBjot0Lu_H1dlHvp1727w_z78BVJc295PQlt99Z&u=http%3A//bugzilla.scilab.org/16734&k=dFBm [4] https://antispam.utc.fr/proxy/v3?i=SGI0YVJGNmxZNE90Z2thMFYLWSxJOfIERJocpmb73Vs&r=SW5LV3JodE9QZkRVZ3JEYbCxfBpXCzNXFJI9eyEBCB_E8EQzXar_oWBGCSukLx6I&f=bnJjU3hQT3pQSmNQZVE3aPQ56ZBjot0Lu_H1dlHvp1727w_z78BVJc295PQlt99Z&u=https%3A//codereview.scilab.org/%23/c/20953/6/scilab/modules/gui/macros/findobj.sci&k=dFBm [5] https://antispam.utc.fr/proxy/v3?i=SGI0YVJGNmxZNE90Z2thMFYLWSxJOfIERJocpmb73Vs&r=SW5LV3JodE9QZkRVZ3JEYbCxfBpXCzNXFJI9eyEBCB_E8EQzXar_oWBGCSukLx6I&f=bnJjU3hQT3pQSmNQZVE3aPQ56ZBjot0Lu_H1dlHvp1727w_z78BVJc295PQlt99Z&u=http%3A//bugzilla.scilab.org/show_bug.cgi%3Fid%3D7117%23c6&k=dFBm -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdr at durietz.se Tue Jan 25 13:09:25 2022 From: sdr at durietz.se (Stefan Du Rietz) Date: Tue, 25 Jan 2022 13:09:25 +0100 Subject: [Scilab-users] Scinotes background color Message-ID: Hello, with Scilab 6.1.1 and Linux (Ubuntu with XFCE) the background color in Scinotes turned grey, which makes almost all text unreadable. In Scinotes Preferences and in the Command window it is white. Is there anything I can do? Regards Stefan From stephane.mottelet at utc.fr Tue Jan 25 14:24:26 2022 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 25 Jan 2022 14:24:26 +0100 Subject: [Scilab-users] Scinotes background color In-Reply-To: References: Message-ID: <4870d2d1-a3cc-c43a-0a00-27c4c2d0cc84@utc.fr> Hello Stefan, First if all, please create a new issue in bugzilla.scilab.org. Then, can you try a with a different window manager (other than xfce) ? S. Le 25/01/2022 ? 13:09, Stefan Du Rietz a ?crit?: > Hello, > with Scilab 6.1.1 and Linux (Ubuntu with XFCE) the background color in > Scinotes turned grey, which makes almost all text unreadable. In > Scinotes Preferences and in the Command window it is white. > > Is there anything I can do? > > Regards > Stefan > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://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 sdr at durietz.se Tue Jan 25 16:21:41 2022 From: sdr at durietz.se (Stefan Du Rietz) Date: Tue, 25 Jan 2022 16:21:41 +0100 Subject: [Scilab-users] Scinotes background color In-Reply-To: <4870d2d1-a3cc-c43a-0a00-27c4c2d0cc84@utc.fr> References: <4870d2d1-a3cc-c43a-0a00-27c4c2d0cc84@utc.fr> Message-ID: Hello St?phane, I could just add to Bug #16735. Thanks Stefan On 2022-01-25 14:24, St?phane Mottelet wrote: > Hello Stefan, > > First if all, please create a new issue in bugzilla.scilab.org. Then, > can you try a with a different window manager (other than xfce) ? > > S. > > Le 25/01/2022 ? 13:09, Stefan Du Rietz a ?crit?: >> Hello, >> with Scilab 6.1.1 and Linux (Ubuntu with XFCE) the background color in >> Scinotes turned grey, which makes almost all text unreadable. In >> Scinotes Preferences and in the Command window it is white. >> >> Is there anything I can do? >> >> Regards >> Stefan >> >> >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/users >