From Patrice.MEGRET at umons.ac.be Tue Jan 8 09:11:10 2019 From: Patrice.MEGRET at umons.ac.be (Patrice MEGRET) Date: Tue, 8 Jan 2019 08:11:10 +0000 Subject: [Scilab-users] ticks_mark property in Scilab 6.0.1 Message-ID: Dear all, Since Scilab 6.0.1 the ticks_mark property seems to be broken: the following code works as expected in Scilab 5.5.2 but does not display the formatted ticks in Scilab 6.0.1. // test of ticks_format property // PM 2019-01-08 x = [0:%pi/100:2*%pi] plot2d(x,sin(x)) xgrid af=gca() // ticks_format ok, in Scilab 5.5.2 and broken in Scilab 6.0.1 af.ticks_format = ["%.1e","%.2f","%.1f"] //x-axis in exp notation with 1 decimal place and y-axis with 2 decimal places There is a bug 14790 reported Scilab's Bug Tracker. For publication it is generally vital to have a specified number of decimal places on the axes. So, will this be be solved in the next release or is there a clue to get the good behavior without using ticks_format? Thanks a lot. Patrice MEGRET -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Thu Jan 10 00:31:44 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Wed, 9 Jan 2019 20:31:44 -0300 Subject: [Scilab-users] improve accuracy of roots In-Reply-To: References: Message-ID: <5C368460.8000307@fceia.unr.edu.ar> Dear all, Consider this code: // Define polynomial variable p = poly(0, 'p', 'roots'); // Define fourth degree polynomial R = (1 + p)^4; // Find its roots z = roots(R) The result (Scilab 6.0.1) is z = -1.0001886 -1. + 0.0001886i -1. - 0.0001886i -0.9998114 It should be something closer to -1. -1. -1. -1. Using these roots C = coeff((p-z(1))*(p-z(2))*(p-z(3))*(p-z(4))) yield seemingly accurate coefficients C = 1. 4. 6. 4. 1. but C - [1 4 6 4 1] shows the actual error: ans = 3.775D-15 1.243D-14 1.155D-14 4.441D-15 0. This is acceptable for the coefficients, but the error in the roots is too large. Somehow the errors cancel out when assembling back the polynomial but each individual zero should be closer to the theoretical value Is there some way to improve the accuracy? Regards, Federico Miyara --- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus From Christophe.Dang at sidel.com Thu Jan 10 09:33:43 2019 From: Christophe.Dang at sidel.com (Dang Ngoc Chan, Christophe) Date: Thu, 10 Jan 2019 08:33:43 +0000 Subject: [Scilab-users] improve accuracy of roots Message-ID: Hello, > De : users [mailto:users-bounces at lists.scilab.org] De la part de Federico Miyara > Envoy? : jeudi 10 janvier 2019 00:32 > > // Define fourth degree polynomial > R = (1 + p)^4; > > // Find its roots > z = roots(R) > [...] > but the error in the roots is too large. The help page mentions that: "This implies that just representing the coefficients as IEEE doubles changes the roots." https://help.scilab.org/docs/6.0.1/en_US/roots.html > Is there some way to improve the accuracy? The "f" option does not work so I have no clue here, sorry. Regards -- Christophe Dang Ngoc Chan Mechanical calculation engineer Public 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 denis.crete at thalesgroup.com Thu Jan 10 14:32:33 2019 From: denis.crete at thalesgroup.com (CRETE Denis) Date: Thu, 10 Jan 2019 13:32:33 +0000 Subject: [Scilab-users] improve accuracy of roots In-Reply-To: <5C368460.8000307@fceia.unr.edu.ar> References: <5C368460.8000307@fceia.unr.edu.ar> Message-ID: Hello, I tried this correction to the initial roots z: z-4*(1+z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') ans = -1. - 1.923D-13i -1. + 1.189D-12i -1. - 1.189D-12i -1. - 1.919D-13i // Evaluation of new error, (and defining Z as the intended root, i.e. here Z=-1): z2=z-4*(z-Z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') z2 - Z ans = 2.233D-08 - 1.923D-13i -2.968D-08 + 1.189D-12i -2.968D-08 - 1.189D-12i 2.131D-08 - 1.919D-13i The factor 4 in the correction is a bit obscure to me, but it seems to work also for R=(3+p)^4, again with an accuracy on the roots of a ~2E-8. HTH Denis -----Message d'origine----- De?: users [mailto:users-bounces at lists.scilab.org] De la part de Federico Miyara Envoy??: jeudi 10 janvier 2019 00:32 ??: users at lists.scilab.org Objet?: [Scilab-users] improve accuracy of roots Dear all, Consider this code: // Define polynomial variable p = poly(0, 'p', 'roots'); // Define fourth degree polynomial R = (1 + p)^4; // Find its roots z = roots(R) The result (Scilab 6.0.1) is z = -1.0001886 -1. + 0.0001886i -1. - 0.0001886i -0.9998114 It should be something closer to -1. -1. -1. -1. Using these roots C = coeff((p-z(1))*(p-z(2))*(p-z(3))*(p-z(4))) yield seemingly accurate coefficients C = 1. 4. 6. 4. 1. but C - [1 4 6 4 1] shows the actual error: ans = 3.775D-15 1.243D-14 1.155D-14 4.441D-15 0. This is acceptable for the coefficients, but the error in the roots is too large. Somehow the errors cancel out when assembling back the polynomial but each individual zero should be closer to the theoretical value Is there some way to improve the accuracy? Regards, Federico Miyara --- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus _______________________________________________ users mailing list users at lists.scilab.org http://lists.scilab.org/mailman/listinfo/users From stephane.mottelet at utc.fr Thu Jan 10 14:51:29 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 10 Jan 2019 14:51:29 +0100 Subject: [Scilab-users] improve accuracy of roots In-Reply-To: References: <5C368460.8000307@fceia.unr.edu.ar> Message-ID: <1806a554-eec8-2044-eb45-138613ae3f09@utc.fr> Hi, This behavior has already been discussed here : http://bugzilla.scilab.org/show_bug.cgi?id=15349 S. Le 10/01/2019 ? 14:32, CRETE Denis a ?crit?: > Hello, > I tried this correction to the initial roots z: > > z-4*(1+z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') > ans = > > -1. - 1.923D-13i > -1. + 1.189D-12i > -1. - 1.189D-12i > -1. - 1.919D-13i > > // Evaluation of new error, (and defining Z as the intended root, i.e. here Z=-1): > z2=z-4*(z-Z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') > z2 - Z > ans = > > 2.233D-08 - 1.923D-13i > -2.968D-08 + 1.189D-12i > -2.968D-08 - 1.189D-12i > 2.131D-08 - 1.919D-13i > > The factor 4 in the correction is a bit obscure to me, but it seems to work also for R=(3+p)^4, again with an accuracy on the roots of a ~2E-8. > > HTH > Denis > > -----Message d'origine----- > De?: users [mailto:users-bounces at lists.scilab.org] De la part de Federico Miyara > Envoy??: jeudi 10 janvier 2019 00:32 > ??: users at lists.scilab.org > Objet?: [Scilab-users] improve accuracy of roots > > > Dear all, > > Consider this code: > > // Define polynomial variable > p = poly(0, 'p', 'roots'); > > // Define fourth degree polynomial > R = (1 + p)^4; > > // Find its roots > z = roots(R) > > The result (Scilab 6.0.1) is > > z = > > -1.0001886 > -1. + 0.0001886i > -1. - 0.0001886i > -0.9998114 > > It should be something closer to > > -1. > -1. > -1. > -1. > > Using these roots > > C = coeff((p-z(1))*(p-z(2))*(p-z(3))*(p-z(4))) > > yield seemingly accurate coefficients > C = > > 1. 4. 6. 4. 1. > > > but > > C - [1 4 6 4 1] > > shows the actual error: > > ans = > > 3.775D-15 1.243D-14 1.155D-14 4.441D-15 0. > > This is acceptable for the coefficients, but the error in the roots is > too large. Somehow the errors cancel out when assembling back the > polynomial but each individual zero should be closer to the theoretical > value > > Is there some way to improve the accuracy? > > Regards, > > Federico Miyara > > > > > --- > El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. > https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.avast.com/antivirus > > _______________________________________________ > 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 > 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 mice.recorder at yahoo.fr Thu Jan 10 15:35:08 2019 From: mice.recorder at yahoo.fr (yannick) Date: Thu, 10 Jan 2019 07:35:08 -0700 (MST) Subject: [Scilab-users] mput ( int16([1:len]), 's', fid ) ; Creates a file of 20296 bytes ! ! ! Message-ID: <1547130908900-0.post@n3.nabble.com> Hello, I try to go from MatLab to SciLab. I am a little disturbed by my first tests, maybe the change of context ... I'm probably using the instructions incorrectly, but my mistake is so huge that I can not see it. Can you help me open my eyes? The following code: * len = 10000 ; fid = mopen( 'C:\Users\yoon\Documents\MATLAB\Dorian\SciLab.bin' , 'w+' ); mput ( int16([1:len]), 's', fid ) ; mt1 = mtell(fid) ; mseek( 0 , fid ) ; rm = mget(len, 's', fid); mclose(fid); printf('%i %i', mt1, length(rm)) * creates a file of 20296 bytes. I expected exactly 20000... mt1 == 20296. Moreover "mget" reads only 25 short words. If I simply changes "[1:len]" for "zeros(1,len)", every thing becomes ok, (file size and rm length). If I use double words instead short " mput ( [1:len], 'd', fid ) ; " the file size is 80040 and rm's length 2060 !!! What's missing me? Thank's in advance, Yannick -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From stephane.mottelet at utc.fr Thu Jan 10 16:40:56 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 10 Jan 2019 16:40:56 +0100 Subject: [Scilab-users] mput ( int16([1:len]), 's', fid ) ; Creates a file of 20296 bytes ! ! ! In-Reply-To: <1547130908900-0.post@n3.nabble.com> References: <1547130908900-0.post@n3.nabble.com> Message-ID: Hello, With Scilab 6.0.1 under OSX or Linux, and your script len = 10000 ; fid = mopen(fullfile(TMPDIR,'Scilab.bin'),'wb+'); mput (int16([1:len]), 's', fid ) ; mt1 = mtell(fid) ; mseek(0, fid) ; rm = mget(len, 's', fid); mclose(fid); printf('%i %i', mt1, length(rm)) I got the expected answer: 20000 10000 --> mt1 ?mt1? = ?? 20000. However, I confirm that under Scilab 6.0.1 under Windows 7 I got the same result as yours: 20296 25 --> mt1 ?mt1? = ?? 20296. This is somewhat related to http://bugzilla.scilab.org/show_bug.cgi?id=3684 In order to have the correct behavior change "w+" to "wb+" in the mopen I will create a bug report on http://bugzilla.scilab.org S. Le 10/01/2019 ? 15:35, yannick a ?crit?: > Hello, > > I try to go from MatLab to SciLab. > > I am a little disturbed by my first tests, maybe the change of context ... > > I'm probably using the instructions incorrectly, but my mistake is so huge > that I can not see it. > Can you help me open my eyes? > > The following code: > * > len = 10000 ; > fid = mopen( 'C:\Users\yoon\Documents\MATLAB\Dorian\SciLab.bin' , 'w+' ); > > mput ( int16([1:len]), 's', fid ) ; mt1 = mtell(fid) ; > mseek( 0 , fid ) ; > rm = mget(len, 's', fid); > > mclose(fid); > > printf('%i %i', mt1, length(rm)) > * > creates a file of 20296 bytes. I expected exactly 20000... > mt1 == 20296. > Moreover "mget" reads only 25 short words. > > If I simply changes "[1:len]" for "zeros(1,len)", every thing becomes ok, > (file size and rm length). > > If I use double words instead short " mput ( [1:len], 'd', fid ) ; " > the file size is 80040 and rm's length 2060 !!! > > What's missing me? > > Thank's in advance, > Yannick > > > > -- > Sent from: https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html > _______________________________________________ > 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 stephane.mottelet at utc.fr Thu Jan 10 16:55:21 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 10 Jan 2019 16:55:21 +0100 Subject: [Scilab-users] mput ( int16([1:len]), 's', fid ) ; Creates a file of 20296 bytes ! ! ! In-Reply-To: References: <1547130908900-0.post@n3.nabble.com> Message-ID: The problem has already been pointed out here : http://bugzilla.scilab.org/show_bug.cgi?id=15206 S. Le 10/01/2019 ? 16:40, St?phane Mottelet a ?crit?: > Hello, > > With Scilab 6.0.1 under OSX or Linux, and your script > > len = 10000 ; > fid = mopen(fullfile(TMPDIR,'Scilab.bin'),'wb+'); > mput (int16([1:len]), 's', fid ) ; > mt1 = mtell(fid) ; > mseek(0, fid) ; > rm = mget(len, 's', fid); > mclose(fid); > printf('%i %i', mt1, length(rm)) > > I got the expected answer: > > 20000 10000 > --> mt1 > ?mt1? = > > ?? 20000. > > However, I confirm that under Scilab 6.0.1 under Windows 7 I got the > same result as yours: > > 20296 25 > --> mt1 > ?mt1? = > > ?? 20296. > > This is somewhat related to > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=3684 > > In order to have the correct behavior change "w+" to "wb+" in the mopen > > I will create a bug report on > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org > > > S. > > > Le 10/01/2019 ? 15:35, yannick a ?crit?: >> Hello, >> >> I try to go from MatLab to SciLab. >> >> I am a little disturbed by my first tests, maybe the change of >> context ... >> >> I'm probably using the instructions incorrectly, but my mistake is so >> huge >> that I can not see it. >> Can you help me open my eyes? >> >> The following code: >> * >> len = 10000 ; >> fid = mopen( 'C:\Users\yoon\Documents\MATLAB\Dorian\SciLab.bin' , >> 'w+' ); >> >> ??? mput ( int16([1:len]), 's', fid ) ;????? mt1 = mtell(fid) ; >> ??? mseek( 0 , fid? ) ; >> ??? rm = mget(len, 's', fid); >> >> mclose(fid); >> >> printf('%i %i', mt1, length(rm)) >> * >> creates a file of 20296 bytes. I expected exactly 20000... >> mt1 == 20296. >> Moreover "mget" reads only 25 short words. >> >> If I simply changes "[1:len]" for "zeros(1,len)", every thing becomes >> ok, >> (file size and rm length). >> >> If I use double words instead short? " mput ( [1:len], 'd', fid ) ; " >> ? the file size is 80040??? and rm's length 2060 !!! >> >> ?? What's missing me? >> >> ?? Thank's in advance, >> ??? Yannick >> >> >> >> -- >> Sent from: >> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html >> _______________________________________________ >> users mailing list >> 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 http://www.utc.fr/~mottelet From mice.recorder at yahoo.fr Thu Jan 10 17:06:39 2019 From: mice.recorder at yahoo.fr (yannick) Date: Thu, 10 Jan 2019 09:06:39 -0700 (MST) Subject: [Scilab-users] mput ( int16([1:len]), 's', fid ) ; Creates a file of 20296 bytes ! ! ! In-Reply-To: <1547130908900-0.post@n3.nabble.com> References: <1547130908900-0.post@n3.nabble.com> Message-ID: <1547136399411-0.post@n3.nabble.com> Thank you, I felt like I was going crazy. Sincerely Yannick. -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From paul.carrico at esterline.com Fri Jan 11 09:28:54 2019 From: paul.carrico at esterline.com (Carrico, Paul) Date: Fri, 11 Jan 2019 08:28:54 +0000 Subject: [Scilab-users] h5write data in a compressed format Message-ID: <3A6B7233274DB449A2A0053A47684F953FF1ACBD@BGS-EX01.auxitrol.ad> Dear All Some months ago I used h5py library to write compressed h5 file (using native gzip) and Scilab to read it; it worked fine and allowed to deal with several Go of data. Now I would like to write/read huge amount of data using mainly Scilab (typically after several csvRead), but I'm wondering if it's to optimize h5 file size using gzip capability? HDFview can confirm that using h5write the data are not compressed, and I do not see such feature in the help doc. Thanks for a feedback Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Sat Jan 12 04:01:36 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Sat, 12 Jan 2019 00:01:36 -0300 Subject: [Scilab-users] improve accuracy of roots In-Reply-To: References: <5C368460.8000307@fceia.unr.edu.ar> Message-ID: <5C395890.6070800@fceia.unr.edu.ar> Denis, Thank you. If this were really a general solution it would be great, since it improves the root accuracy by several orders, but I don't fully get the rationale behind this method. It seems you are trying to apply a variant of the Raphson-Newton method, aren't you? However, in cases like this, in which there are repeated roots, the derivative approaches zero as you get closer to the root, but the polynomial goes to zero faster. In that case the factor 4 may imlpy that the next approximation gets closer to the actual root. But this is speculation. It could also overshoot. Regards, Federico Miyara On 10/01/2019 10:32, CRETE Denis wrote: > Hello, > I tried this correction to the initial roots z: > > z-4*(1+z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') > ans = > > -1. - 1.923D-13i > -1. + 1.189D-12i > -1. - 1.189D-12i > -1. - 1.919D-13i > > // Evaluation of new error, (and defining Z as the intended root, i.e. here Z=-1): > z2=z-4*(z-Z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') > z2 - Z > ans = > > 2.233D-08 - 1.923D-13i > -2.968D-08 + 1.189D-12i > -2.968D-08 - 1.189D-12i > 2.131D-08 - 1.919D-13i > > The factor 4 in the correction is a bit obscure to me, but it seems to work also for R=(3+p)^4, again with an accuracy on the roots of a ~2E-8. > > HTH > Denis > > -----Message d'origine----- > De : users [mailto:users-bounces at lists.scilab.org] De la part de Federico Miyara > Envoy? : jeudi 10 janvier 2019 00:32 > ? :users at lists.scilab.org > Objet : [Scilab-users] improve accuracy of roots > > > Dear all, > > Consider this code: > > // Define polynomial variable > p = poly(0, 'p', 'roots'); > > // Define fourth degree polynomial > R = (1 + p)^4; > > // Find its roots > z = roots(R) > > The result (Scilab 6.0.1) is > > z = > > -1.0001886 > -1. + 0.0001886i > -1. - 0.0001886i > -0.9998114 > > It should be something closer to > > -1. > -1. > -1. > -1. > > Using these roots > > C = coeff((p-z(1))*(p-z(2))*(p-z(3))*(p-z(4))) > > yield seemingly accurate coefficients > C = > > 1. 4. 6. 4. 1. > > > but > > C - [1 4 6 4 1] > > shows the actual error: > > ans = > > 3.775D-15 1.243D-14 1.155D-14 4.441D-15 0. > > This is acceptable for the coefficients, but the error in the roots is > too large. Somehow the errors cancel out when assembling back the > polynomial but each individual zero should be closer to the theoretical > value > > Is there some way to improve the accuracy? > > Regards, > > Federico Miyara > > > > > --- > El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. > https://www.avast.com/antivirus > > _______________________________________________ > 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 fmiyara at fceia.unr.edu.ar Sat Jan 12 07:52:05 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Sat, 12 Jan 2019 03:52:05 -0300 Subject: [Scilab-users] improve accuracy of roots In-Reply-To: References: <5C368460.8000307@fceia.unr.edu.ar> Message-ID: <5C398E95.1000008@fceia.unr.edu.ar> Denis, I've found the correction here, https://en.wikipedia.org/wiki/Newton%27s_method It is useful to accelerate convergence in case of multiple roots, but I guess it is not valid to apply it once to improve accuracy because of the risk of overshoot. Regards, Federico Miyara On 10/01/2019 10:32, CRETE Denis wrote: > Hello, > I tried this correction to the initial roots z: > > z-4*(1+z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') > ans = > > -1. - 1.923D-13i > -1. + 1.189D-12i > -1. - 1.189D-12i > -1. - 1.919D-13i > > // Evaluation of new error, (and defining Z as the intended root, i.e. here Z=-1): > z2=z-4*(z-Z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') > z2 - Z > ans = > > 2.233D-08 - 1.923D-13i > -2.968D-08 + 1.189D-12i > -2.968D-08 - 1.189D-12i > 2.131D-08 - 1.919D-13i > > The factor 4 in the correction is a bit obscure to me, but it seems to work also for R=(3+p)^4, again with an accuracy on the roots of a ~2E-8. > > HTH > Denis > > -----Message d'origine----- > De : users [mailto:users-bounces at lists.scilab.org] De la part de Federico Miyara > Envoy? : jeudi 10 janvier 2019 00:32 > ? : users at lists.scilab.org > Objet : [Scilab-users] improve accuracy of roots > > > Dear all, > > Consider this code: > > // Define polynomial variable > p = poly(0, 'p', 'roots'); > > // Define fourth degree polynomial > R = (1 + p)^4; > > // Find its roots > z = roots(R) > > The result (Scilab 6.0.1) is > > z = > > -1.0001886 > -1. + 0.0001886i > -1. - 0.0001886i > -0.9998114 > > It should be something closer to > > -1. > -1. > -1. > -1. > > Using these roots > > C = coeff((p-z(1))*(p-z(2))*(p-z(3))*(p-z(4))) > > yield seemingly accurate coefficients > C = > > 1. 4. 6. 4. 1. > > > but > > C - [1 4 6 4 1] > > shows the actual error: > > ans = > > 3.775D-15 1.243D-14 1.155D-14 4.441D-15 0. > > This is acceptable for the coefficients, but the error in the roots is > too large. Somehow the errors cancel out when assembling back the > polynomial but each individual zero should be closer to the theoretical > value > > Is there some way to improve the accuracy? > > Regards, > > Federico Miyara > > > > > --- > El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. > https://www.avast.com/antivirus > > _______________________________________________ > 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 > > From chrisp at poundsc.org Sun Jan 13 10:45:28 2019 From: chrisp at poundsc.org (Pndsc) Date: Sun, 13 Jan 2019 02:45:28 -0700 (MST) Subject: [Scilab-users] Data from XCos plots? Message-ID: <1547372728055-0.post@n3.nabble.com> I was wondering if theres a way to export data from Xcos plots that show the result of simulations. Graphs are OK but I need to interrogate the raw values. Is there a way to export to CSV or something? I'm assuming that its something simple that I've missed. -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From n.strelkov at gmail.com Sun Jan 13 11:55:28 2019 From: n.strelkov at gmail.com (Nikolay Strelkov) Date: Sun, 13 Jan 2019 13:55:28 +0300 Subject: [Scilab-users] Data from XCos plots? In-Reply-To: <1547372728055-0.post@n3.nabble.com> References: <1547372728055-0.post@n3.nabble.com> Message-ID: Dear Pndsc! It is possible. If you have figure with axis from Xcos model then you can get its data: a = gca(); x = a.children.data(:,1); y = a.children.data(:,2); and then manipulate them as you need. -- *With best regards,Ph.D., * *associate professor at MPEI ,IEEE member,maintainer of Mathieu functions toolbox for Scilab ,Nikolay Strelkov.* ??, 13 ???. 2019 ?. ? 12:45, Pndsc : > I was wondering if theres a way to export data from Xcos plots that show > the > result of simulations. Graphs are OK but I need to interrogate the raw > values. > > Is there a way to export to CSV or something? I'm assuming that its > something simple that I've missed. > > > > -- > Sent from: > http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emmanuel.irog-irog at lsu.edu.ph Sun Jan 13 12:16:38 2019 From: emmanuel.irog-irog at lsu.edu.ph (Emmanuel Irog-irog) Date: Sun, 13 Jan 2019 19:16:38 +0800 Subject: [Scilab-users] Data from XCos plots? In-Reply-To: References: <1547372728055-0.post@n3.nabble.com> Message-ID: Is there a way to export Xcos data during simulation the "to workspace" block only exports data after the simulation? On Sun, 13 Jan 2019, 6:56 pm Nikolay Strelkov Dear Pndsc! > > It is possible. If you have figure with axis from Xcos model then you can > get its data: > > a = gca(); > x = a.children.data(:,1); > y = a.children.data(:,2); > > and then manipulate them as you need. > > -- > > *With best regards,Ph.D., * > > > > *associate professor at MPEI > ,IEEE member,maintainer of > Mathieu functions toolbox for Scilab > ,Nikolay Strelkov.* > > > ??, 13 ???. 2019 ?. ? 12:45, Pndsc : > >> I was wondering if theres a way to export data from Xcos plots that show >> the >> result of simulations. Graphs are OK but I need to interrogate the raw >> values. >> >> Is there a way to export to CSV or something? I'm assuming that its >> something simple that I've missed. >> >> >> >> -- >> Sent from: >> http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html >> _______________________________________________ >> 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 fmiyara at fceia.unr.edu.ar Sun Jan 13 20:52:50 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Sun, 13 Jan 2019 16:52:50 -0300 Subject: [Scilab-users] Data from XCos plots? In-Reply-To: References: <1547372728055-0.post@n3.nabble.com> Message-ID: <5C3B9712.5000508@fceia.unr.edu.ar> Probably it is a = gca(); x = a.children.children.data(:,1); y = a.children.children.data(:,2); since a.children doesn't have the "data" proerty, but its child is of type "Polyline" which does have the "data" property Federico Miyara On 13/01/2019 07:55, Nikolay Strelkov wrote: > a = gca(); > x = a.children.data(:,1); > y = a.children.data(:,2); > --- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From Holger.Niedermaier at ESTW.DE Mon Jan 14 08:27:54 2019 From: Holger.Niedermaier at ESTW.DE (Niedermaier.Holger) Date: Mon, 14 Jan 2019 07:27:54 +0000 Subject: [Scilab-users] Mingw Compiler error, Xcos model compiler Error Message-ID: <417a0221b1804096a7c808f34b377192@ESTW.DE> Unfortunately it seems that nobody got an idea how to solve the issue. Or it remains unanswered because of the X-mas holidays? Therefor again my question. Maybe someone can help? _____________________________ Dear all, it's maybe an easy problem but I myself aren't able to solve it. I installed MinGw compiler via ATOMOS and, as described in the help text, the windows 64 bit interface module afterwards, using the link given. After restart my computer and running Scilab I got a huge number of messages like the following Mingw Compiler support for Scilab Load macros Converting Libraries. Build libblasplus.a Conversion failed libblasplus.a Build liblibf2c.a Conversion failed liblibf2c.a Build libcore.a Conversion failed libcore.a Build libcore_f.a ... I've absolute no idea how to handle it. Can anyone help? Thanks in advance Holger Erlanger Stadtwerke AG Vorsitzender des Aufsichtsrats: Oberbuergermeister Dr. Florian Janik Vorstand: Wolfgang Geus (Vorsitzender), Matthias Exner, Frank Oneseit HR B Nr. 539, Amtsgericht, 90762 Fuerth -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.crete at thalesgroup.com Mon Jan 14 17:47:59 2019 From: denis.crete at thalesgroup.com (CRETE Denis) Date: Mon, 14 Jan 2019 16:47:59 +0000 Subject: [Scilab-users] improve accuracy of roots In-Reply-To: <5C398E95.1000008@fceia.unr.edu.ar> References: <5C368460.8000307@fceia.unr.edu.ar> <5C398E95.1000008@fceia.unr.edu.ar> Message-ID: <73bfc1ad05ad4a648ffbf5057f891688@thalesgroup.com> Thank you Frederico! According to the page you refer to, the method seems to converge more rapidly with this factor equal to the multiplicity of the root. About overshoot, it is well known to occur for |x|^a where a <1. But for a>1, the risk of overshoot with the Newton-Raphson method seems to be very small... Best regards Denis [@@ THALES GROUP INTERNAL @@] Unit? Mixte de Physique CNRS / THALES 1 Avenue Augustin Fresnel 91767 Palaiseau CEDEx - France Tel : +33 (0)1 69 41 58 52 Fax : +33 (0)1 69 41 58 78 e-mail : denis.crete at thalesgroup.com http://www.trt.thalesgroup.com/ump-cnrs-thales http://www.research.thalesgroup.com -----Message d'origine----- De?: users [mailto:users-bounces at lists.scilab.org] De la part de Federico Miyara Envoy??: samedi 12 janvier 2019 07:52 ??: Users mailing list for Scilab Objet?: Re: [Scilab-users] improve accuracy of roots Denis, I've found the correction here, https://en.wikipedia.org/wiki/Newton%27s_method It is useful to accelerate convergence in case of multiple roots, but I guess it is not valid to apply it once to improve accuracy because of the risk of overshoot. Regards, Federico Miyara On 10/01/2019 10:32, CRETE Denis wrote: > Hello, > I tried this correction to the initial roots z: > > z-4*(1+z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') > ans = > > -1. - 1.923D-13i > -1. + 1.189D-12i > -1. - 1.189D-12i > -1. - 1.919D-13i > > // Evaluation of new error, (and defining Z as the intended root, i.e. here Z=-1): > z2=z-4*(z-Z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') > z2 - Z > ans = > > 2.233D-08 - 1.923D-13i > -2.968D-08 + 1.189D-12i > -2.968D-08 - 1.189D-12i > 2.131D-08 - 1.919D-13i > > The factor 4 in the correction is a bit obscure to me, but it seems to work also for R=(3+p)^4, again with an accuracy on the roots of a ~2E-8. > > HTH > Denis > > -----Message d'origine----- > De : users [mailto:users-bounces at lists.scilab.org] De la part de Federico Miyara > Envoy? : jeudi 10 janvier 2019 00:32 > ? : users at lists.scilab.org > Objet : [Scilab-users] improve accuracy of roots > > > Dear all, > > Consider this code: > > // Define polynomial variable > p = poly(0, 'p', 'roots'); > > // Define fourth degree polynomial > R = (1 + p)^4; > > // Find its roots > z = roots(R) > > The result (Scilab 6.0.1) is > > z = > > -1.0001886 > -1. + 0.0001886i > -1. - 0.0001886i > -0.9998114 > > It should be something closer to > > -1. > -1. > -1. > -1. > > Using these roots > > C = coeff((p-z(1))*(p-z(2))*(p-z(3))*(p-z(4))) > > yield seemingly accurate coefficients > C = > > 1. 4. 6. 4. 1. > > > but > > C - [1 4 6 4 1] > > shows the actual error: > > ans = > > 3.775D-15 1.243D-14 1.155D-14 4.441D-15 0. > > This is acceptable for the coefficients, but the error in the roots is > too large. Somehow the errors cancel out when assembling back the > polynomial but each individual zero should be closer to the theoretical > value > > Is there some way to improve the accuracy? > > Regards, > > Federico Miyara > > > > > --- > El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. > https://www.avast.com/antivirus > > _______________________________________________ > 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 From fmiyara at fceia.unr.edu.ar Mon Jan 14 21:07:35 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Mon, 14 Jan 2019 17:07:35 -0300 Subject: [Scilab-users] improve accuracy of roots In-Reply-To: <73bfc1ad05ad4a648ffbf5057f891688@thalesgroup.com> References: <5C368460.8000307@fceia.unr.edu.ar> <5C398E95.1000008@fceia.unr.edu.ar> <73bfc1ad05ad4a648ffbf5057f891688@thalesgroup.com> Message-ID: <5C3CEC07.5050403@fceia.unr.edu.ar> Denis, What I meant is that convergence is a limiting process. On average, as the number of iterations rises you?ll be closer to the limit, bu there is no guarantee that any single iteration will bring you any closer; it may be a question of luck. Maybe (though it would require a proof, it is not self-evident for me) in the exact case of a single multiple root as (x - a)^n the convergence process is monotonous, but what if you have (x - a1)* ... * (x - an) where ak are all very similar but not identical, say, with relative differences of the order of those reported by the application of the regular version of roots. Regards, Federico Miyara On 14/01/2019 13:47, CRETE Denis wrote: > Thank you Frederico! > According to the page you refer to, the method seems to converge more rapidly with this factor equal to the multiplicity of the root. > About overshoot, it is well known to occur for |x|^a where a <1. But for a>1, the risk of overshoot with the Newton-Raphson method seems to be very small... > Best regards > Denis > > [@@ THALES GROUP INTERNAL @@] > > Unit? Mixte de Physique CNRS / THALES > 1 Avenue Augustin Fresnel > 91767 Palaiseau CEDEx - France > Tel : +33 (0)1 69 41 58 52 Fax : +33 (0)1 69 41 58 78 > e-mail : > denis.crete at thalesgroup.com > http://www.trt.thalesgroup.com/ump-cnrs-thales > http://www.research.thalesgroup.com > > > -----Message d'origine----- > De : users [mailto:users-bounces at lists.scilab.org] De la part de Federico Miyara > Envoy? : samedi 12 janvier 2019 07:52 > ? : Users mailing list for Scilab > Objet : Re: [Scilab-users] improve accuracy of roots > > > Denis, > > I've found the correction here, > > https://en.wikipedia.org/wiki/Newton%27s_method > > It is useful to accelerate convergence in case of multiple roots, but I > guess it is not valid to apply it once to improve accuracy because of > the risk of overshoot. > > Regards, > > Federico Miyara > > > On 10/01/2019 10:32, CRETE Denis wrote: >> Hello, >> I tried this correction to the initial roots z: >> >> z-4*(1+z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') >> ans = >> >> -1. - 1.923D-13i >> -1. + 1.189D-12i >> -1. - 1.189D-12i >> -1. - 1.919D-13i >> >> // Evaluation of new error, (and defining Z as the intended root, i.e. here Z=-1): >> z2=z-4*(z-Z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') >> z2 - Z >> ans = >> >> 2.233D-08 - 1.923D-13i >> -2.968D-08 + 1.189D-12i >> -2.968D-08 - 1.189D-12i >> 2.131D-08 - 1.919D-13i >> >> The factor 4 in the correction is a bit obscure to me, but it seems to work also for R=(3+p)^4, again with an accuracy on the roots of a ~2E-8. >> >> HTH >> Denis >> >> -----Message d'origine----- >> De : users [mailto:users-bounces at lists.scilab.org] De la part de Federico Miyara >> Envoy? : jeudi 10 janvier 2019 00:32 >> ? : users at lists.scilab.org >> Objet : [Scilab-users] improve accuracy of roots >> >> >> Dear all, >> >> Consider this code: >> >> // Define polynomial variable >> p = poly(0, 'p', 'roots'); >> >> // Define fourth degree polynomial >> R = (1 + p)^4; >> >> // Find its roots >> z = roots(R) >> >> The result (Scilab 6.0.1) is >> >> z = >> >> -1.0001886 >> -1. + 0.0001886i >> -1. - 0.0001886i >> -0.9998114 >> >> It should be something closer to >> >> -1. >> -1. >> -1. >> -1. >> >> Using these roots >> >> C = coeff((p-z(1))*(p-z(2))*(p-z(3))*(p-z(4))) >> >> yield seemingly accurate coefficients >> C = >> >> 1. 4. 6. 4. 1. >> >> >> but >> >> C - [1 4 6 4 1] >> >> shows the actual error: >> >> ans = >> >> 3.775D-15 1.243D-14 1.155D-14 4.441D-15 0. >> >> This is acceptable for the coefficients, but the error in the roots is >> too large. Somehow the errors cancel out when assembling back the >> polynomial but each individual zero should be closer to the theoretical >> value >> >> Is there some way to improve the accuracy? >> >> Regards, >> >> Federico Miyara >> >> >> >> >> --- >> El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. >> https://www.avast.com/antivirus >> >> _______________________________________________ >> 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 > _______________________________________________ > 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 Jan 15 03:36:50 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Mon, 14 Jan 2019 23:36:50 -0300 Subject: [Scilab-users] Seemingly inconsistent behavior In-Reply-To: <5C3CEC07.5050403@fceia.unr.edu.ar> References: <5C368460.8000307@fceia.unr.edu.ar> <5C398E95.1000008@fceia.unr.edu.ar> <73bfc1ad05ad4a648ffbf5057f891688@thalesgroup.com> <5C3CEC07.5050403@fceia.unr.edu.ar> Message-ID: <5C3D4742.3080809@fceia.unr.edu.ar> Dear all, This statement a = {[%f, %t], {2; poly([3, 2],'v')}} defines a cell array whose first element is a boolean row vector and whose second element in turn is another cell array. Invoking a{1}(1) correctly returns the boolean value F. But a{2}{1} does not return 2, as expected but an error: Error: syntax error, unexpected {, expecting end of file However b = a{2} b{1} returns the correct value 2. Why, if a{2} is a cell array, its entries cannot be extracted with the curly brackets {}? Moreover a{2}(1) and a{2}(2) should be the constant 2. and the polynomial 2 6 -5v +v respectively, but they are reported as cell arrays, since iscell(a{2}(1)) and iscell(a{2}(2)) are both True Why is a cell array responsive to () at all and why it returns a sub ell array? Thank you in advance. Regards, Federico Miyara --- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus From stephane.mottelet at utc.fr Tue Jan 15 08:22:17 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 15 Jan 2019 08:22:17 +0100 Subject: [Scilab-users] Seemingly inconsistent behavior In-Reply-To: <5C3D4742.3080809@fceia.unr.edu.ar> References: <5C368460.8000307@fceia.unr.edu.ar> <5C398E95.1000008@fceia.unr.edu.ar> <73bfc1ad05ad4a648ffbf5057f891688@thalesgroup.com> <5C3CEC07.5050403@fceia.unr.edu.ar> <5C3D4742.3080809@fceia.unr.edu.ar> Message-ID: <59a666ca-3716-a884-f6da-c622f191017a@utc.fr> Hello, This limitation is alreay pointed out here : http://bugzilla.scilab.org/show_bug.cgi?id=15756 S. Le 15/01/2019 ? 03:36, Federico Miyara a ?crit?: > > Dear all, > > This statement > > a = {[%f, %t], {2; poly([3, 2],'v')}} > > defines a cell array whose first element is a boolean row vector and > whose second element in turn is another cell array. > > Invoking a{1}(1) correctly returns the boolean value F. > > But a{2}{1} does not return 2, as expected but an error: > > Error: syntax error, unexpected {, expecting end of file > > However > > b? =? a{2} > b{1} > > returns the correct value 2. > > Why, if a{2} is a cell array, its entries cannot be extracted with the > curly brackets {}? > > Moreover a{2}(1) and a{2}(2) should be the constant 2. and the polynomial > > ?????????? 2 > ?? 6 -5v +v > > respectively,? but they are reported as cell arrays, since > > iscell(a{2}(1)) and? iscell(a{2}(2)) are both True > > Why is a cell array responsive to () at all and why it returns a sub > ell array? > > Thank you in advance. > > Regards, > > Federico Miyara > > > > > --- > El software de antivirus Avast ha analizado este correo electr?nico en > busca de virus. > https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.avast.com/antivirus > > > _______________________________________________ > 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 paul.carrico at esterline.com Tue Jan 15 09:56:05 2019 From: paul.carrico at esterline.com (Carrico, Paul) Date: Tue, 15 Jan 2019 08:56:05 +0000 Subject: [Scilab-users] vectorization difficulty Message-ID: <3A6B7233274DB449A2A0053A47684F953FF1B02B@BGS-EX01.auxitrol.ad> Dear All May I ask you advices in order to use vectorization instead of the loop? All the trials I did have failed - the problem I'm confront to comes from the S matrix Thanks for your feedback Paul ######################################################## clc mode(0) clear function V=eigen_val(S11, S12, S13, S22, S23, S33) S_u = [0 S12 S13 ; 0 0 S23 ; 0. 0. 0.]; S_d = [S11 ; S22 ; S33]; S = S_u + S_u' + diag(S_d); V = gsort(spec(S),'lr','d')'; clear S; clear S_u; clear S_d; endfunction n = 10; m = 1; S11 = rand(n,m); S22 = rand(n,m); S33 = rand(n,m); S12 = rand(n,m); S23 = rand(n,m); S13 = rand(n,m); princ = zeros(n,3); // with a loop tic(); princ1 = zeros(n,3*m); for i = 1 : n S_u = [0 S12(i,m) S13(i,m) ; 0 0 S23(i,m) ; 0. 0. 0.]; S_d = [S11(i,m) ; S22(i,1) ; S33(i,m)]; S = S_u + S_u' + diag(S_d); princ1(i,:) = gsort(spec(S),'lr','d')'; clear S; clear S_u; clear S_d; end duration1 = toc(); printf("Duration 1 = %g\n",duration1); // using a function tic(); princ2 = zeros(n,3*m); for i = 1 : n princ2(i,:) = eigen_val(S11(i,m),S12(i,m),S13(i,m),S22(i,m),S23(i,m),S33(i,m)); end duration2 = toc(); printf("Duration 2 = %g\n",duration2); isequal(princ1,princ2) // using vectorization (in combination with the function ?) i = (1:n)'; S = zeros(3,3,n) -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Tue Jan 15 18:14:05 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 15 Jan 2019 18:14:05 +0100 Subject: [Scilab-users] improve accuracy of roots In-Reply-To: <5C3CEC07.5050403@fceia.unr.edu.ar> References: <5C368460.8000307@fceia.unr.edu.ar> <5C398E95.1000008@fceia.unr.edu.ar> <73bfc1ad05ad4a648ffbf5057f891688@thalesgroup.com> <5C3CEC07.5050403@fceia.unr.edu.ar> Message-ID: <978489d2-0606-e1a3-b484-2873fcb27065@utc.fr> Hello, After a quick search on the internet I have found and translated in Scilab "multroot", a Matlab Package computing polynomial roots and multiplicities. If you are interested proceed to this url: http://bugzilla.scilab.org/show_bug.cgi?id=15349#c9 Enjoy ! S. Le 14/01/2019 ? 21:07, Federico Miyara a ?crit?: > > Denis, > > What I meant is that convergence is a limiting process. On average, as > the number of iterations rises you?ll be closer to the limit, bu there > is no guarantee that any single iteration will bring you any closer; > it may be a question of luck. Maybe (though it would require a proof, > it is not self-evident for me) in the exact case of a single multiple > root as (x - a)^n the convergence process is monotonous, but what if > you have (x - a1)* ... * (x? - an) where ak are all very similar but > not identical, say, with relative differences of the order of those > reported by the application of the regular version? of roots. > Regards, > > Federico Miyara > > > On 14/01/2019 13:47, CRETE Denis wrote: >> Thank you Frederico! >> According to the page you refer to, the method seems to converge more rapidly with this factor equal to the multiplicity of the root. >> About overshoot, it is well known to occur for |x|^a where a <1. But for a>1, the risk of overshoot with the Newton-Raphson method seems to be very small... >> Best regards >> Denis >> >> [@@ THALES GROUP INTERNAL @@] >> >> Unit? Mixte de Physique CNRS / THALES >> 1 Avenue Augustin Fresnel >> 91767 Palaiseau CEDEx - France >> Tel : +33 (0)1 69 41 58 52 Fax : +33 (0)1 69 41 58 78 >> e-mail : >> denis.crete at thalesgroup.com >> http://www.trt.thalesgroup.com/ump-cnrs-thales >> http://www.research.thalesgroup.com >> >> >> -----Message d'origine----- >> De?: users [mailto:users-bounces at lists.scilab.org] De la part de Federico Miyara >> Envoy??: samedi 12 janvier 2019 07:52 >> ??: Users mailing list for Scilab >> Objet?: Re: [Scilab-users] improve accuracy of roots >> >> >> Denis, >> >> I've found the correction here, >> >> https://en.wikipedia.org/wiki/Newton%27s_method >> >> It is useful to accelerate convergence in case of multiple roots, but I >> guess it is not valid to apply it once to improve accuracy because of >> the risk of overshoot. >> >> Regards, >> >> Federico Miyara >> >> >> On 10/01/2019 10:32, CRETE Denis wrote: >>> Hello, >>> I tried this correction to the initial roots z: >>> >>> z-4*(1+z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') >>> ans = >>> >>> -1. - 1.923D-13i >>> -1. + 1.189D-12i >>> -1. - 1.189D-12i >>> -1. - 1.919D-13i >>> >>> // Evaluation of new error, (and defining Z as the intended root, i.e. here Z=-1): >>> z2=z-4*(z-Z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') >>> z2 - Z >>> ans = >>> >>> 2.233D-08 - 1.923D-13i >>> -2.968D-08 + 1.189D-12i >>> -2.968D-08 - 1.189D-12i >>> 2.131D-08 - 1.919D-13i >>> >>> The factor 4 in the correction is a bit obscure to me, but it seems to work also for R=(3+p)^4, again with an accuracy on the roots of a ~2E-8. >>> >>> HTH >>> Denis >>> >>> -----Message d'origine----- >>> De : users [mailto:users-bounces at lists.scilab.org] De la part de Federico Miyara >>> Envoy? : jeudi 10 janvier 2019 00:32 >>> ? :users at lists.scilab.org >>> Objet : [Scilab-users] improve accuracy of roots >>> >>> >>> Dear all, >>> >>> Consider this code: >>> >>> // Define polynomial variable >>> p = poly(0, 'p', 'roots'); >>> >>> // Define fourth degree polynomial >>> R = (1 + p)^4; >>> >>> // Find its roots >>> z = roots(R) >>> >>> The result (Scilab 6.0.1) is >>> >>> z = >>> >>> -1.0001886 >>> -1. + 0.0001886i >>> -1. - 0.0001886i >>> -0.9998114 >>> >>> It should be something closer to >>> >>> -1. >>> -1. >>> -1. >>> -1. >>> >>> Using these roots >>> >>> C = coeff((p-z(1))*(p-z(2))*(p-z(3))*(p-z(4))) >>> >>> yield seemingly accurate coefficients >>> C = >>> >>> 1. 4. 6. 4. 1. >>> >>> >>> but >>> >>> C - [1 4 6 4 1] >>> >>> shows the actual error: >>> >>> ans = >>> >>> 3.775D-15 1.243D-14 1.155D-14 4.441D-15 0. >>> >>> This is acceptable for the coefficients, but the error in the roots is >>> too large. Somehow the errors cancel out when assembling back the >>> polynomial but each individual zero should be closer to the theoretical >>> value >>> >>> Is there some way to improve the accuracy? >>> >>> Regards, >>> >>> Federico Miyara >>> >>> >>> >>> >>> --- >>> El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. >>> https://www.avast.com/antivirus >>> >>> _______________________________________________ >>> 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 >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/users >> >> > > > > Libre de virus. www.avast.com > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > _______________________________________________ > 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 Tue Jan 15 19:49:02 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Tue, 15 Jan 2019 15:49:02 -0300 Subject: [Scilab-users] improve accuracy of roots In-Reply-To: <978489d2-0606-e1a3-b484-2873fcb27065@utc.fr> References: <5C368460.8000307@fceia.unr.edu.ar> <5C398E95.1000008@fceia.unr.edu.ar> <73bfc1ad05ad4a648ffbf5057f891688@thalesgroup.com> <5C3CEC07.5050403@fceia.unr.edu.ar> <978489d2-0606-e1a3-b484-2873fcb27065@utc.fr> Message-ID: <5C3E2B1E.6030707@fceia.unr.edu.ar> St?phane, Thank you very much for your contribution! Best regards, Federico Miyara On 15/01/2019 14:14, St?phane Mottelet wrote: > Hello, > > After a quick search on the internet I have found and translated in > Scilab "multroot", a Matlab Package computing polynomial roots and > multiplicities. If you are interested proceed to this url: > http://bugzilla.scilab.org/show_bug.cgi?id=15349#c9 > > Enjoy ! > > S. > > Le 14/01/2019 ? 21:07, Federico Miyara a ?crit : >> >> Denis, >> >> What I meant is that convergence is a limiting process. On average, >> as the number of iterations rises you?ll be closer to the limit, bu >> there is no guarantee that any single iteration will bring you any >> closer; it may be a question of luck. Maybe (though it would require >> a proof, it is not self-evident for me) in the exact case of a single >> multiple root as (x - a)^n the convergence process is monotonous, but >> what if you have (x - a1)* ... * (x - an) where ak are all very >> similar but not identical, say, with relative differences of the >> order of those reported by the application of the regular version of >> roots. >> Regards, >> >> Federico Miyara >> >> >> On 14/01/2019 13:47, CRETE Denis wrote: >>> Thank you Frederico! >>> According to the page you refer to, the method seems to converge more rapidly with this factor equal to the multiplicity of the root. >>> About overshoot, it is well known to occur for |x|^a where a <1. But for a>1, the risk of overshoot with the Newton-Raphson method seems to be very small... >>> Best regards >>> Denis >>> >>> [@@ THALES GROUP INTERNAL @@] >>> >>> Unit? Mixte de Physique CNRS / THALES >>> 1 Avenue Augustin Fresnel >>> 91767 Palaiseau CEDEx - France >>> Tel : +33 (0)1 69 41 58 52 Fax : +33 (0)1 69 41 58 78 >>> e-mail : >>> denis.crete at thalesgroup.com >>> http://www.trt.thalesgroup.com/ump-cnrs-thales >>> http://www.research.thalesgroup.com >>> >>> >>> -----Message d'origine----- >>> De : users [mailto:users-bounces at lists.scilab.org] De la part de Federico Miyara >>> Envoy? : samedi 12 janvier 2019 07:52 >>> ? : Users mailing list for Scilab >>> Objet : Re: [Scilab-users] improve accuracy of roots >>> >>> >>> Denis, >>> >>> I've found the correction here, >>> >>> https://en.wikipedia.org/wiki/Newton%27s_method >>> >>> It is useful to accelerate convergence in case of multiple roots, but I >>> guess it is not valid to apply it once to improve accuracy because of >>> the risk of overshoot. >>> >>> Regards, >>> >>> Federico Miyara >>> >>> >>> On 10/01/2019 10:32, CRETE Denis wrote: >>>> Hello, >>>> I tried this correction to the initial roots z: >>>> >>>> z-4*(1+z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') >>>> ans = >>>> >>>> -1. - 1.923D-13i >>>> -1. + 1.189D-12i >>>> -1. - 1.189D-12i >>>> -1. - 1.919D-13i >>>> >>>> // Evaluation of new error, (and defining Z as the intended root, i.e. here Z=-1): >>>> z2=z-4*(z-Z).^4 ./([ones(z),z,z.^2,z.^3]*(C(2:5).*(1:4))') >>>> z2 - Z >>>> ans = >>>> >>>> 2.233D-08 - 1.923D-13i >>>> -2.968D-08 + 1.189D-12i >>>> -2.968D-08 - 1.189D-12i >>>> 2.131D-08 - 1.919D-13i >>>> >>>> The factor 4 in the correction is a bit obscure to me, but it seems to work also for R=(3+p)^4, again with an accuracy on the roots of a ~2E-8. >>>> >>>> HTH >>>> Denis >>>> >>>> -----Message d'origine----- >>>> De : users [mailto:users-bounces at lists.scilab.org] De la part de Federico Miyara >>>> Envoy? : jeudi 10 janvier 2019 00:32 >>>> ? :users at lists.scilab.org >>>> Objet : [Scilab-users] improve accuracy of roots >>>> >>>> >>>> Dear all, >>>> >>>> Consider this code: >>>> >>>> // Define polynomial variable >>>> p = poly(0, 'p', 'roots'); >>>> >>>> // Define fourth degree polynomial >>>> R = (1 + p)^4; >>>> >>>> // Find its roots >>>> z = roots(R) >>>> >>>> The result (Scilab 6.0.1) is >>>> >>>> z = >>>> >>>> -1.0001886 >>>> -1. + 0.0001886i >>>> -1. - 0.0001886i >>>> -0.9998114 >>>> >>>> It should be something closer to >>>> >>>> -1. >>>> -1. >>>> -1. >>>> -1. >>>> >>>> Using these roots >>>> >>>> C = coeff((p-z(1))*(p-z(2))*(p-z(3))*(p-z(4))) >>>> >>>> yield seemingly accurate coefficients >>>> C = >>>> >>>> 1. 4. 6. 4. 1. >>>> >>>> >>>> but >>>> >>>> C - [1 4 6 4 1] >>>> >>>> shows the actual error: >>>> >>>> ans = >>>> >>>> 3.775D-15 1.243D-14 1.155D-14 4.441D-15 0. >>>> >>>> This is acceptable for the coefficients, but the error in the roots is >>>> too large. Somehow the errors cancel out when assembling back the >>>> polynomial but each individual zero should be closer to the theoretical >>>> value >>>> >>>> Is there some way to improve the accuracy? >>>> >>>> Regards, >>>> >>>> Federico Miyara >>>> >>>> >>>> >>>> >>>> --- >>>> El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. >>>> https://www.avast.com/antivirus >>>> >>>> _______________________________________________ >>>> 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 >>> _______________________________________________ >>> users mailing list >>> users at lists.scilab.org >>> http://lists.scilab.org/mailman/listinfo/users >>> >>> >> >> >> >> Libre de virus. www.avast.com >> >> >> >> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >> _______________________________________________ >> 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 Fri Jan 18 15:21:49 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 18 Jan 2019 15:21:49 +0100 Subject: [Scilab-users] vectorization difficulty In-Reply-To: <3A6B7233274DB449A2A0053A47684F953FF1B02B@BGS-EX01.auxitrol.ad> References: <3A6B7233274DB449A2A0053A47684F953FF1B02B@BGS-EX01.auxitrol.ad> Message-ID: Hello Paul, If you stick to 3x3, you can vectorize the Cardan formulas applied to the characteristic polynomial of each individual matrix. S. Le 15/01/2019 ? 09:56, Carrico, Paul a ?crit?: > > clc > > mode(0) > > clear > > function*V*=_eigen_val_(*S11*, *S12*, *S13*, *S22*, *S23*, *S33*) > > S_u = [0 *S12* *S13* ; 0 0 *S23* ; 0. 0. 0.]; > > S_d = [*S11* ; *S22* ; *S33*]; > > S = S_u + S_u' + diag(S_d); > > *V* = gsort(spec(S),'lr','d')'; clear S; clear S_u; clear S_d; > > endfunction > > n= 10; m = 1; > > S11= rand(n,m); > > S22= rand(n,m); > > S33= rand(n,m); > > S12= rand(n,m); > > S23= rand(n,m); > > S13= rand(n,m); > > princ= zeros(n,3); > > /// with a loop/ > > tic(); > > princ1= zeros(n,3*m); > > fori = 1 : n > > S_u = [0 S12(i,m) S13(i,m) ; 0 0 S23(i,m) ; 0. 0. 0.]; > > S_d = [S11(i,m) ; S22(i,1) ; S33(i,m)]; > > S = S_u + S_u' + diag(S_d); > > princ1(i,:) = gsort(spec(S),'lr','d')'; clear S; clear S_u; clear S_d; > > end > > duration1= toc(); printf("Duration 1 = %g\n",duration1); > > /// using a function/ > > tic(); > > princ2= zeros(n,3*m); > > fori = 1 : n > > princ2(i,:) = > _eigen_val_(S11(i,m),S12(i,m),S13(i,m),S22(i,m),S23(i,m),S33(i,m)); > > end > > duration2= toc(); printf("Duration 2 = %g\n",duration2); > > isequal(princ1,princ2) > > /// using vectorization (in combination with the function ?)/ > > i= (1:n)'; > > S= zeros(3,3,n) -- 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 Fri Jan 18 17:43:24 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 18 Jan 2019 17:43:24 +0100 Subject: [Scilab-users] vectorization difficulty In-Reply-To: References: <3A6B7233274DB449A2A0053A47684F953FF1B02B@BGS-EX01.auxitrol.ad> Message-ID: <1ef21d46-69b9-f9f6-31a9-5b0bbfeb254f@utc.fr> Like this (I have simplified your script a little bit) for n=1000 there is a x60 speedup with Cardan's formulas: clear n = 1000; S11 = rand(n,1); S22 = rand(n,1); S33 = rand(n,1); S12 = rand(n,1); S23 = rand(n,1); S13 = rand(n,1); princ = zeros(n,3); // with a loop tic(); princ1 = zeros(n,3); for i = 1 : n S=[S11(i) S12(i) S13(i) S12(i) S22(i) S23(i) S13(i) S23(i) S33(i)]; princ1(i,:) = gsort(spec(S))'; end duration1 = toc(); printf("Duration 1 = %g\n",duration1); // using Cardan formulas tic(); // characteristic polynomial is poly([d c b a],"x","coeff") S13sq = S13.*S13; S12sq = S12.*S12; S23sq = S23.*S23; //a=1; (not used) b=-S11-S22-S33; c=S11.*S22+S11.*S33+S22.*S33-S23sq-S13sq-S12sq; d=S11.*S23sq+S22.*S13sq+S12sq.*S33 - S11.*S22.*S33-2*S13.*S12.*S23; b2=b.*b; p=-b2/3+c; q=b.*(2*b2-9*c)/27+d; //delta=-(4*p.*p.*p+27*q.*q) (not used since matrix is symetric =>real eigenvalues) princ2=zeros(n,3); theta=acos(1.5*q./p.*sqrt(-3./p))/3; for k=0:2 princ2(:,k+1)=2*sqrt(-p/3).*cos(theta+2*k*%pi/3)-b/3; end princ2=gsort(princ2,"c") duration2 = toc(); printf("Duration 2 = %g\n",duration2); disp(norm(princ1-princ2,%inf)) disp(duration1/duration2) S. Le 18/01/2019 ? 15:21, St?phane Mottelet a ?crit?: > Hello Paul, > > If you stick to 3x3, you can vectorize the Cardan formulas applied to > the characteristic polynomial of each individual matrix. > > S. > > > > Le 15/01/2019 ? 09:56, Carrico, Paul a ?crit?: >> >> clc >> >> mode(0) >> >> clear >> >> function*V*=_eigen_val_(*S11*, *S12*, *S13*, *S22*, *S23*, *S33*) >> >> S_u = [0 *S12* *S13* ; 0 0 *S23* ; 0. 0. 0.]; >> >> S_d = [*S11* ; *S22* ; *S33*]; >> >> S = S_u + S_u' + diag(S_d); >> >> *V* = gsort(spec(S),'lr','d')'; clear S; clear S_u; clear S_d; >> >> endfunction >> >> n= 10; m = 1; >> >> S11= rand(n,m); >> >> S22= rand(n,m); >> >> S33= rand(n,m); >> >> S12= rand(n,m); >> >> S23= rand(n,m); >> >> S13= rand(n,m); >> >> princ= zeros(n,3); >> >> /// with a loop/ >> >> tic(); >> >> princ1= zeros(n,3*m); >> >> fori = 1 : n >> >> S_u = [0 S12(i,m) S13(i,m) ; 0 0 S23(i,m) ; 0. 0. 0.]; >> >> S_d = [S11(i,m) ; S22(i,1) ; S33(i,m)]; >> >> S = S_u + S_u' + diag(S_d); >> >> princ1(i,:) = gsort(spec(S),'lr','d')'; clear S; clear S_u; clear S_d; >> >> end >> >> duration1= toc(); printf("Duration 1 = %g\n",duration1); >> >> /// using a function/ >> >> tic(); >> >> princ2= zeros(n,3*m); >> >> fori = 1 : n >> >> princ2(i,:) = >> _eigen_val_(S11(i,m),S12(i,m),S13(i,m),S22(i,m),S23(i,m),S33(i,m)); >> >> end >> >> duration2= toc(); printf("Duration 2 = %g\n",duration2); >> >> isequal(princ1,princ2) >> >> /// using vectorization (in combination with the function ?)/ >> >> i= (1:n)'; >> >> S= zeros(3,3,n) > > > -- > 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 fmiyara at fceia.unr.edu.ar Sun Jan 20 09:46:03 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Sun, 20 Jan 2019 05:46:03 -0300 Subject: [Scilab-users] compact layout for console In-Reply-To: <1ef21d46-69b9-f9f6-31a9-5b0bbfeb254f@utc.fr> References: <3A6B7233274DB449A2A0053A47684F953FF1B02B@BGS-EX01.auxitrol.ad> <1ef21d46-69b9-f9f6-31a9-5b0bbfeb254f@utc.fr> Message-ID: <5C44354B.7090803@fceia.unr.edu.ar> Dear all, Is there any way to get a more compact presentation of results in the console? I mean to avoid the unnecessary extra blank lines between output lines. Matlab allows so from the preferences, but I couldn't find a similar option in Scilab. Maybe there is some undocumented feature somehere...? Regards, Federico Miyara --- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus From sgougeon at free.fr Sun Jan 20 11:09:59 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Sun, 20 Jan 2019 11:09:59 +0100 Subject: [Scilab-users] compact layout for console In-Reply-To: <5C44354B.7090803@fceia.unr.edu.ar> References: <3A6B7233274DB449A2A0053A47684F953FF1B02B@BGS-EX01.auxitrol.ad> <1ef21d46-69b9-f9f6-31a9-5b0bbfeb254f@utc.fr> <5C44354B.7090803@fceia.unr.edu.ar> Message-ID: Hello Federico, The most compact you can get is after having used --> mode(1) https://help.scilab.org/docs/6.0.1/en_US/mode.html Regards Samuel Le 20/01/2019 ? 09:46, Federico Miyara a ?crit : > > Dear all, > > Is there any way to get a more compact presentation of results in the > console? > > I mean to avoid the unnecessary extra blank lines between output lines. > > Matlab allows so from the preferences, but I couldn't find a similar > option in Scilab. Maybe there is some undocumented feature somehere...? > > Regards, > > Federico Miyara > > --- > El software de antivirus Avast ha analizado este correo electr?nico en > busca de virus. > https://www.avast.com/antivirus > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > From fmiyara at fceia.unr.edu.ar Mon Jan 21 01:21:21 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Sun, 20 Jan 2019 21:21:21 -0300 Subject: [Scilab-users] compact layout for console In-Reply-To: References: <3A6B7233274DB449A2A0053A47684F953FF1B02B@BGS-EX01.auxitrol.ad> <1ef21d46-69b9-f9f6-31a9-5b0bbfeb254f@utc.fr> <5C44354B.7090803@fceia.unr.edu.ar> Message-ID: <5C451081.1030503@fceia.unr.edu.ar> Samuel, Thank you! Regards, Federico On 20/01/2019 07:09, Samuel Gougeon wrote: > Hello Federico, > > The most compact you can get is after having used > --> mode(1) > > https://help.scilab.org/docs/6.0.1/en_US/mode.html > > Regards > Samuel > > Le 20/01/2019 ? 09:46, Federico Miyara a ?crit : >> >> Dear all, >> >> Is there any way to get a more compact presentation of results in the >> console? >> >> I mean to avoid the unnecessary extra blank lines between output lines. >> >> Matlab allows so from the preferences, but I couldn't find a similar >> option in Scilab. Maybe there is some undocumented feature somehere...? >> >> Regards, >> >> Federico Miyara >> >> --- >> El software de antivirus Avast ha analizado este correo electr?nico >> en busca de virus. >> https://www.avast.com/antivirus >> >> _______________________________________________ >> 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 > > --- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.gulunay at gmail.com Thu Jan 24 05:08:30 2019 From: n.gulunay at gmail.com (Necati Gulunay) Date: Thu, 24 Jan 2019 07:08:30 +0300 Subject: [Scilab-users] A bug on saving the user parameters in memory? Message-ID: I have been struggling with scilab 6.0.1 (64 bit) on windows in the sense that when I change my code and rerun a program it seems the machine still keeps the part (or all?) of the old code and seems to make the previous run. So I am unable to see what my changes to the code make to the run of the program which drives me crazy. When I close scilab and reopen it then the code runs proper. It seems this is a bug with the run platform. Anybody familiar with this problem and is there a cure for this. Scilab 5 did not have this problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aweeks at hidglobal.com Fri Jan 25 11:01:17 2019 From: aweeks at hidglobal.com (Adrian Weeks) Date: Fri, 25 Jan 2019 10:01:17 +0000 Subject: [Scilab-users] 4-D plots. Message-ID: <690097ba0e4049448963c4d725ed64c1@hidglobal.com> Hello, I want to plot a function of three independent variables ( v = f(x, y, z) ) so that I can visualize it. Essentially, this requires a 4-D plot but I can do it by using param3d to give me three independent axes then representing the value of the function at each point by using the colour or size of the dot. This all works nicely but the problem is the slowness of the plotting operation: for i = 1: size(dots, 'r') do param3d(dots(i, 1), dots(i, 2), dots(i, 3)); pl = gce(); pl.line_mode = 'off'; pl.mark_mode = 'on'; pl.mark_size_unit = 'point'; pl.mark_size = 10; // Using dot colour to display the dependent variable pl.mark_foreground = dots(i, 4); // pl.mark_size = dots(i, 4); // Using dot size to display the dependent variable // pl.mark_foreground = size(cmap, 'r') - 1; end Is it possible to 'vectorize' this operation ? At present the dot information is stored in a single matrix using columns for x, y, z & colour: it needn't be done this way. Notice the line_mode, mark_mode etc. switching - I haven't found a way to set these values as defaults. Instead of plotting each dot I tried plotting a single, master dot, then copying its handle to all the other points. The effect of this was that changing the colour of one changed the colour of them all. The full test programme is given below. I'm using Windows 7 and Scilab 5.4.1 Many thanks in anticipation, Adrian. //******************************************************************************* // 3D plot trial. //******************************************************************************* // 1) The number of colours in the colour map sets the granularity of the displayed values. // 2) A step size, in conjunction with the range of each of the three independent variables, sets // the total number of dots. // 3) For all combinations of the independent variable values, calculate the dependent variable. // 4) Optionally, remove all dependent variable values lying outside prescribed limits. // 5) Convert all (remaining) dependent variable values to a colour number. // 6) Plot all dots using the calculated colour map. // 7) Dot size could be varied, as an alternative to dot colour. xdel(winsid()); clear; clearglobal; resethistory; clc; //------------------------------------------------------------------------------- // Graded-colour generator. // xgrade is a continuous parameter, range 0 to 1, which varies the colour grade (brightness) // between limits pale & dark where pale = 255 would mean white and dark = 0 would mean black. // Practical values are pale = 220, dark = 120. function RGB = SetColour(pale, dark, colour, xgrade) k1 = pale + 255 - dark; k2 = round(xgrade * k1); if xgrade <= pale / k1 then p = 255; s = pale - k2; else p = pale + 255 - k2; s = 0; end select colour case #rd then RGB = [p, s, s]; case #yw then RGB = [p, p, s]; case #gn then RGB = [s, p, s]; case #cn then RGB = [s, p, p]; case #be then RGB = [s, s, p]; case #ma then RGB = [p, s, p]; else RGB = [0, 0, 0]; end endfunction #rd = 1 #yw = 2 #gn = 3 #cn = 4 #be = 5 #ma = 6 Ncolour = 6 Ngrade = 11 pale = 220 dark = 120 //------------------------------------------------------------------------------- // Graded-colour colour-map generator. // Colours are mapped consecutively in blocks of Ngrade RGB values. // The RGB triplet for a particular colour and grade is accessed by calculating the row index using: // r = Ngrade(colour - 1) + grade. function cmap = ColourMap(Ncolour, Ngrade) cmap = [] for colour = 1: Ncolour do for xgrade = linspace(0, 1, Ngrade) do RGB = SetColour(pale, dark, colour, xgrade) / 255; cmap = [cmap; RGB]; end end cmap = [cmap; [0, 0, 0]]; // Add black & white cmap = [cmap; [1, 1, 1]] endfunction //------------------------------------------------------------------------------- // An arbitrary example function, suitable for plotting, which generates values between 1 & 11 // dependent on the three input variables. // The output range 1..11 suits the colour-map range. function v = F(x, y, z) v = round((x/10 + y/10 + (z - 5.5)^2/20.25 - 0.2)/0.28) + 1; endfunction //------------------------------------------------------------------------------- // Generate the dots to be plotted. colour = #rd index = Ngrade * (colour - 1) N = 10 values = linspace(1, 10, N) dots = [] for x = values do for y = values do for z = values do dots = [dots; x, y, z, F(x, y, z) + index]; end end end //------------------------------------------------------------------------------- // Prepare a 3D plot with appropriate colour-map. cmap = ColourMap(Ncolour, Ngrade); fg = scf(); //fg.figure_position = [,]; //fg.figure_size = [,]; fg.color_map = cmap; fg.background = size(cmap, 'r'); da = gda(); da.line_mode = 'off'; da.mark_mode = 'on'; da.mark_size_unit = 'point'; da.mark_size = 10; //da.mark_foreground = size(cmap, 'r') - 1; ax = newaxes(); ax.margins = [0.07,0.07,0.03,0.07]; ax.tight_limits = 'on'; ax.data_bounds = [0.8,0.8,0.8;10.2,10.2,10.2]; ax.cube_scaling = 'on'; ax.zoom_box = [0.8,0.8,10.2,10.2,0.8,10.2]; ax.hidden_axis_color = size(cmap, 'r') - 1; //ax.line_mode = 'off' //ax.mark_mode = 'on' //ax.mark_size_unit = 'point' //ax.mark_size = 10 //ax.mark_foreground = 1 //------------------------------------------------------------------------------- // Plot all dots as separate polylines, each having just one point, in its own colour value. // Dot size can be used instead of dot colour. for i = 1: size(dots, 'r') do param3d(dots(i, 1), dots(i, 2), dots(i, 3)); pl = gce(); pl.line_mode = 'off'; pl.mark_mode = 'on'; pl.mark_size_unit = 'point'; pl.mark_size = 10; // Using dot colour to display the dependent variable pl.mark_foreground = dots(i, 4); // pl.mark_size = dots(i, 4); // Using dot size to display the dependent variable // pl.mark_foreground = size(cmap, 'r') - 1; end //******************************************************************************* Adrian Weeks. Engineer, Hardware Engineering EMEA. Office: +44 (0) 2920 528500 | Direct: +44 (0) 2920 528523 Email: aweeks at hidglobal.com [HID Global Logo] HID Global, 3 Cae Gwrydd, Green Meadow Springs, Cardiff, CF15 7AB , United Kingdom www.hidglobal.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2408 bytes Desc: image001.gif URL: From sgougeon at free.fr Fri Jan 25 13:58:20 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 25 Jan 2019 13:58:20 +0100 Subject: [Scilab-users] 4-D plots. In-Reply-To: <690097ba0e4049448963c4d725ed64c1@hidglobal.com> References: <690097ba0e4049448963c4d725ed64c1@hidglobal.com> Message-ID: Le 25/01/2019 ? 11:01, Adrian Weeks a ?crit : > > Hello, > > I want to plot a function of three independent variables ( v = f(x, y, > z) ) so that I can visualize it. > > Essentially, this requires a 4-D plot but I can do it by using param3d > to give me three independent axes then representing the value of the > function at each point by using the colour or size of the dot. > > This all works nicely but the problem is the slowness of the plotting > operation: > > for i = 1: size(dots, 'r') do > > param3d(dots(i, 1), dots(i, 2), dots(i, 3)); > > pl = gce(); > > pl.line_mode = 'off'; > > pl.mark_mode = 'on'; > > pl.mark_size_unit = 'point'; > > pl.mark_size = 10; // Using dot colour to display the > dependent variable > > pl.mark_foreground = dots(i, 4); > > // pl.mark_size = dots(i, > 4); // Using dot size to > display the dependent variable > > // pl.mark_foreground = size(cmap, 'r') - 1; > > end > > Is it possible to 'vectorize' this operation ? > Hello Adrian, You may have a look to https://help.scilab.org/docs/6.0.1/en_US/scatter3.html Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Fri Jan 25 17:30:24 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 25 Jan 2019 17:30:24 +0100 Subject: [Scilab-users] norm() and %inf, %nan Message-ID: <874db0e1-7ce9-f064-45e5-a28b5c28f7b1@utc.fr> Hello all, In Scilab 6.0.1 (and previous versions), norm() does not support %inf and %nan in the argument: --> norm([1 %inf]) norm: Wrong value for argument #1: Must not contain NaN or Inf. --> norm([1 %nan]) norm: Wrong value for argument #1: Must not contain NaN or Inf. We plan to change this in Scilab 6.0.2, i.e. returning a value instead of raising based on the following rationale: since, at least for vectors, we have for finite p norm(x,p)=sum(abs(x).^p)^(1/p) we should have, for example, -%inf case: --> p=2;x=[1 %inf]; sum(abs(x).^p)^(1/p) ?ans? = ?? Inf -%nan case: --> p=2;x=[1 %nan]; sum(abs(x).^p)^(1/p) ?ans? = ?? Nan -%inf and %nan case --> p=2;x=[1 %nan %inf]; sum(abs(x).^p)^(1/p) ?ans? = ?? Nan hence, norm([1 %inf],p) -> %inf, norm([1 %nan],p) -> %nan norm([1 %nan %inf],p) -> %nan Thank you for your feedback ! S. -- 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 aweeks at hidglobal.com Fri Jan 25 18:06:46 2019 From: aweeks at hidglobal.com (Adrian Weeks) Date: Fri, 25 Jan 2019 17:06:46 +0000 Subject: [Scilab-users] 4-D plots. In-Reply-To: References: <690097ba0e4049448963c4d725ed64c1@hidglobal.com> Message-ID: Hello Samuel, Thank you very much for your reply, this is exactly what I need. Why re-invent the wheel when someone else has already done it. Maybe it's time I updated to Scilab 6... Thanks again, Adrian. Adrian Weeks. Engineer, Hardware Engineering EMEA. Office: +44 (0) 2920 528500 | Direct: +44 (0) 2920 528523 Email: aweeks at hidglobal.com [HID Global Logo] HID Global, 3 Cae Gwrydd, Green Meadow Springs, Cardiff, CF15 7AB , United Kingdom www.hidglobal.com From: users On Behalf Of Samuel Gougeon Sent: 25 January 2019 12:58 To: Users mailing list for Scilab Subject: Re: [Scilab-users] 4-D plots. Le 25/01/2019 ? 11:01, Adrian Weeks a ?crit : Hello, I want to plot a function of three independent variables ( v = f(x, y, z) ) so that I can visualize it. Essentially, this requires a 4-D plot but I can do it by using param3d to give me three independent axes then representing the value of the function at each point by using the colour or size of the dot. This all works nicely but the problem is the slowness of the plotting operation: for i = 1: size(dots, 'r') do param3d(dots(i, 1), dots(i, 2), dots(i, 3)); pl = gce(); pl.line_mode = 'off'; pl.mark_mode = 'on'; pl.mark_size_unit = 'point'; pl.mark_size = 10; // Using dot colour to display the dependent variable pl.mark_foreground = dots(i, 4); // pl.mark_size = dots(i, 4); // Using dot size to display the dependent variable // pl.mark_foreground = size(cmap, 'r') - 1; end Is it possible to 'vectorize' this operation ? Hello Adrian, You may have a look to https://help.scilab.org/docs/6.0.1/en_US/scatter3.html Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2408 bytes Desc: image001.gif URL: From sgougeon at free.fr Fri Jan 25 22:00:22 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 25 Jan 2019 22:00:22 +0100 Subject: [Scilab-users] A bug on saving the user parameters in memory? In-Reply-To: References: Message-ID: Hello, I've never had this issue. However, there is sometime an issue with error messages on Scilab 6.0: A part of the stack of an error message includes some line coming from a previous error. This can be very misleading. It is hard to reproduce it in a deterministic way. So i am not sure that this issue is reported yet. In this case, the only way i found is to quit and restart a new Scilab session, as you does for the issue you are addressing on your side. Samuel Le 24/01/2019 ? 05:08, Necati Gulunay a ?crit : > > > I have been struggling with scilab 6.0.1 (64 bit) on windows in the > sense that when I change my code and rerun a program it seems the > machine still keeps the part (or all?) of the old code and seems to > make the previous run. > > So I am unable to see what my changes to the code make to the run of > the program which drives me crazy. When I close scilab and reopen it > then the code runs proper. > > It seems this is a bug with the run platform. > > Anybody familiar with this problem and is there a cure for this. > > Scilab 5 did not have this problem. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebjpalma at yahoo.com.ar Tue Jan 29 00:48:40 2019 From: ebjpalma at yahoo.com.ar (=?UTF-8?Q?Jos=C3=BFffffffffffe9_Palma?=) Date: Mon, 28 Jan 2019 23:48:40 +0000 (UTC) Subject: [Scilab-users] rltool - error References: <80806215.2708283.1548719320517.ref@mail.yahoo.com> Message-ID: <80806215.2708283.1548719320517@mail.yahoo.com> Hi. I want to use the rltool atom, but I can not. I work in linux mint 19.1, I downloaded Scilab 6.0.1, but that tool does not work in this version. I wanted to install Scilab 5.5.2, but crash with core dump. It does not allow me to compile it from the source code. with wine Scilab version 5.5.2 works and I managed to install the tool, but I want to execute it and it gives me an error. I would like to know if you can help me, because I do not understand that it is in the source code of the tool and does not work. Another thing I did was try to use builder.sce, but it says that "development_tool" does not exist. Please help. Thank you. From ebjpalma at yahoo.com.ar Tue Jan 29 00:50:39 2019 From: ebjpalma at yahoo.com.ar (jotalp) Date: Mon, 28 Jan 2019 16:50:39 -0700 (MST) Subject: [Scilab-users] rltool - error Message-ID: <1548719439223-0.post@n3.nabble.com> Hi. I want to use the rltool atom, but I can not. I work in linux mint 19.1, I downloaded Scilab 6.0.1, but that tool does not work in this version. I wanted to install Scilab 5.5.2, but crash with core dump. It does not allow me to compile it from the source code. with wine Scilab version 5.5.2 works and I managed to install the tool, but I want to execute it and it gives me an error. I would like to know if you can help me, because I do not understand that it is in the source code of the tool and does not work. Another thing I did was try to use builder.sce, but it says that "development_tool" does not exist. Please help. Thank you. -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From sgougeon at free.fr Tue Jan 29 07:05:50 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Tue, 29 Jan 2019 07:05:50 +0100 Subject: [Scilab-users] rltool - error In-Reply-To: <1548719439223-0.post@n3.nabble.com> References: <1548719439223-0.post@n3.nabble.com> Message-ID: <0567bf3f-db25-724d-0f57-485e6a9a849e@free.fr> Hello, Le 29/01/2019 ? 00:50, jotalp a ?crit : > Hi. I want to use the rltool atom, but I can not. I work in linux mint 19.1, > I downloaded Scilab 6.0.1, but that tool does not work in this version. I > wanted to install Scilab 5.5.2, but crash with core dump. It does not allow > me to compile it from the source code. with wine Scilab version 5.5.2 works > and I managed to install the tool, but I want to execute it and it gives me > an error. I would like to know if you can help me, because I do not > understand that it is in the source code of the tool and does not work. > Another thing I did was try to use builder.sce, but it says that > "development_tool" does not exist. You might have unchecked this module in the Scilab installer, while you need it to build some external packages like rltool. You may reinstal Scilab including this module. Regards From paul.carrico at esterline.com Tue Jan 29 16:45:59 2019 From: paul.carrico at esterline.com (Carrico, Paul) Date: Tue, 29 Jan 2019 15:45:59 +0000 Subject: [Scilab-users] acos leads to complex values Message-ID: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> Dear All I spent some time in looking for a mistake in my code ; finally I've found that the ACOS of a real vector leads to some complex values (???) acos(Scar_P(:,1) ./ CM_x_CN(:,1)) (the formula worked so far) I checked that the input values are correct: - Comprised between [-1; 1] using MIN and MAX - Composed only of real values using ISREAL (all the vectors are correct) Thus I do not understand why complex values appear ? May it come from the vectorization ? Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Tue Jan 29 16:49:53 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 29 Jan 2019 16:49:53 +0100 Subject: [Scilab-users] acos leads to complex values In-Reply-To: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> Message-ID: <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> Le 29/01/2019 ? 16:45, Carrico, Paul a ?crit?: > > Dear All > > I spent some time in looking for a mistake in my code?; finally I?ve > found that the ACOS of a real vector leads to some complex values (???) > > acos(Scar_P(:,1)./ CM_x_CN(:,1)) Are your really sure, because we may have --> x=-1-%eps ?x? = ? -1. --> acos(x) ?ans? = ?? 3.1415927 - 2.107D-08i S. > (the formula worked so far) > > I checked that the input values are correct: > > -Comprised between [-1; 1] using MIN and MAX > > -Composed only of real values using ISREAL (all the vectors are correct) > > Thus I do not understand why complex values appear ? > > May it come from the vectorization ? > > Paul > > > _______________________________________________ > 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 paul.carrico at esterline.com Tue Jan 29 16:55:09 2019 From: paul.carrico at esterline.com (Carrico, Paul) Date: Tue, 29 Jan 2019 15:55:09 +0000 Subject: [Scilab-users] [EXTERNAL] Re: acos leads to complex values In-Reply-To: <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> Message-ID: <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> When I scroll to the list, the lowest (positive) value is 8.4E-08 (works fine) and no %eps . How Can I check if %eps is in? De : users [mailto:users-bounces at lists.scilab.org] De la part de St?phane Mottelet Envoy? : mardi 29 janvier 2019 16:50 ? : users at lists.scilab.org Objet : [EXTERNAL] Re: [Scilab-users] acos leads to complex values Le 29/01/2019 ? 16:45, Carrico, Paul a ?crit : Dear All I spent some time in looking for a mistake in my code ; finally I've found that the ACOS of a real vector leads to some complex values (???) acos(Scar_P(:,1) ./ CM_x_CN(:,1)) Are your really sure, because we may have --> x=-1-%eps x = -1. --> acos(x) ans = 3.1415927 - 2.107D-08i S. (the formula worked so far) I checked that the input values are correct: - Comprised between [-1; 1] using MIN and MAX - Composed only of real values using ISREAL (all the vectors are correct) Thus I do not understand why complex values appear ? May it come from the vectorization ? Paul _______________________________________________ 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 Jan 29 16:58:54 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 29 Jan 2019 16:58:54 +0100 Subject: [Scilab-users] [EXTERNAL] Re: acos leads to complex values In-Reply-To: <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> Message-ID: It is the same if x is slightly > 1: --> x=1+%eps ?x? = ?? 1. --> acos(x) ?ans? = ?? 2.107D-08i --> format(25); x ?x? = ?? 1.0000000000000002220446 Le 29/01/2019 ? 16:55, Carrico, Paul a ?crit?: > > When I scroll to the list, the lowest (positive) value is 8.4^E -08 > (works fine) and no %eps . > > How Can I check if %eps is in? > > *De?:*users [mailto:users-bounces at lists.scilab.org] *De la part de* > St?phane Mottelet > *Envoy??:* mardi 29 janvier 2019 16:50 > *??:* users at lists.scilab.org > *Objet?:* [EXTERNAL] Re: [Scilab-users] acos leads to complex values > > Le 29/01/2019 ? 16:45, Carrico, Paul a ?crit?: > > Dear All > > I spent some time in looking for a mistake in my code?; finally > I?ve found that the ACOS of a real vector leads to some complex > values (???) > > acos(Scar_P(:,1)./CM_x_CN(:,1)) > > Are your really sure, because we may have > > --> x=-1-%eps > ?x? = > > ? -1. > > > --> acos(x) > ?ans? = > > ?? 3.1415927 - 2.107D-08i > > S. > > (the formula worked so far) > > I checked that the input values are correct: > > -Comprised between [-1; 1] using MIN and MAX > > -Composed only of real values using ISREAL (all the vectors are > correct) > > Thus I do not understand why complex values appear ? > > May it come from the vectorization ? > > Paul > > > > _______________________________________________ > > 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 paul.carrico at esterline.com Tue Jan 29 19:15:09 2019 From: paul.carrico at esterline.com (Carrico, Paul) Date: Tue, 29 Jan 2019 18:15:09 +0000 Subject: [Scilab-users] [EXTERNAL] Re: acos leads to complex values In-Reply-To: References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> Message-ID: <3A6B7233274DB449A2A0053A47684F953FF1DB85@BGS-EX01.auxitrol.ad> Stephane pointed out on the issue : after calculation and prior to the Acos one, some values were "1.0000000000000002220446" leading to "acos = 2.107D-08i" ; in addition he suggested me to use something like "acos(max(-1,min(1,-1.0000000000000002220446)))" or "acos(max(-1,min(1,1.0000000000000002220446)))" ... very smart :) Thanks Paul EXPORT CONTROL : Cet email ne contient pas de donn?es techniques This email does not contain technical data De : users [mailto:users-bounces at lists.scilab.org] De la part de St?phane Mottelet Envoy? : mardi 29 janvier 2019 16:59 ? : users at lists.scilab.org Objet : Re: [Scilab-users] [EXTERNAL] Re: acos leads to complex values It is the same if x is slightly > 1: --> x=1+%eps x = 1. --> acos(x) ans = 2.107D-08i --> format(25); x x = 1.0000000000000002220446 Le 29/01/2019 ? 16:55, Carrico, Paul a ?crit : When I scroll to the list, the lowest (positive) value is 8.4E-08 (works fine) and no %eps . How Can I check if %eps is in? De : users [mailto:users-bounces at lists.scilab.org] De la part de St?phane Mottelet Envoy? : mardi 29 janvier 2019 16:50 ? : users at lists.scilab.org Objet : [EXTERNAL] Re: [Scilab-users] acos leads to complex values Le 29/01/2019 ? 16:45, Carrico, Paul a ?crit : Dear All I spent some time in looking for a mistake in my code ; finally I've found that the ACOS of a real vector leads to some complex values (???) acos(Scar_P(:,1) ./ CM_x_CN(:,1)) Are your really sure, because we may have --> x=-1-%eps x = -1. --> acos(x) ans = 3.1415927 - 2.107D-08i S. (the formula worked so far) I checked that the input values are correct: - Comprised between [-1; 1] using MIN and MAX - Composed only of real values using ISREAL (all the vectors are correct) Thus I do not understand why complex values appear ? May it come from the vectorization ? Paul _______________________________________________ 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 fmiyara at fceia.unr.edu.ar Tue Jan 29 20:48:48 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Tue, 29 Jan 2019 16:48:48 -0300 Subject: [Scilab-users] [EXTERNAL] Re: acos leads to complex values In-Reply-To: References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> Message-ID: <5C50AE20.1000004@fceia.unr.edu.ar> I think it would be interesting to include an input argument check in some functions prone to give complex results in limiting cases (such as acos or asin) so that if inside the domain (to within 1 %eps) where the output argument should be real the imaginary part is canceled. Something like this for scalars: function y=acos1(x) if isreal(x) if -1<=x & x<=1 y = real(acos(x)) else y = acos(x) end end endfunction However, I must say that acos(1-%eps) gives on my Scilab 6.0.1 (Windows 7, i7 processor) a result of 0.000000021073424255447, being %eps 0.0000000000000002220446 I get no imaginary part. I guess there must be some dependency on the arithmetic engine. Federico Miyara On 29/01/2019 12:58, St?phane Mottelet wrote: > It is the same if x is slightly > 1: > > --> x=1+%eps > x = > > 1. > > > --> acos(x) > ans = > > 2.107D-08i > > --> format(25); x > x = > > 1.0000000000000002220446 > > Le 29/01/2019 ? 16:55, Carrico, Paul a ?crit : >> >> When I scroll to the list, the lowest (positive) value is 8.4^E -08 >> (works fine) and no %eps . >> >> How Can I check if %eps is in? >> >> *De :*users [mailto:users-bounces at lists.scilab.org] *De la part de* >> St?phane Mottelet >> *Envoy? :* mardi 29 janvier 2019 16:50 >> *? :* users at lists.scilab.org >> *Objet :* [EXTERNAL] Re: [Scilab-users] acos leads to complex values >> >> Le 29/01/2019 ? 16:45, Carrico, Paul a ?crit : >> >> Dear All >> >> I spent some time in looking for a mistake in my code ; finally >> I?ve found that the ACOS of a real vector leads to some complex >> values (???) >> >> acos(Scar_P(:,1)./CM_x_CN(:,1)) >> >> Are your really sure, because we may have >> >> --> x=-1-%eps >> x = >> >> -1. >> >> >> --> acos(x) >> ans = >> >> 3.1415927 - 2.107D-08i >> >> S. >> >> (the formula worked so far) >> >> I checked that the input values are correct: >> >> -Comprised between [-1; 1] using MIN and MAX >> >> -Composed only of real values using ISREAL (all the vectors are >> correct) >> >> Thus I do not understand why complex values appear ? >> >> May it come from the vectorization ? >> >> Paul >> >> >> >> _______________________________________________ >> >> 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 --- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Tue Jan 29 20:49:02 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Tue, 29 Jan 2019 16:49:02 -0300 Subject: [Scilab-users] [EXTERNAL] Re: acos leads to complex values In-Reply-To: References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> Message-ID: <5C50AE2E.9010202@fceia.unr.edu.ar> In this case it should be imaginary... Federico Miyara On 29/01/2019 12:58, St?phane Mottelet wrote: > It is the same if x is slightly > 1: > > --> x=1+%eps > x = > > 1. > > > --> acos(x) > ans = > > 2.107D-08i > > --> format(25); x > x = > > 1.0000000000000002220446 > > Le 29/01/2019 ? 16:55, Carrico, Paul a ?crit : >> >> When I scroll to the list, the lowest (positive) value is 8.4^E -08 >> (works fine) and no %eps . >> >> How Can I check if %eps is in? >> >> *De :*users [mailto:users-bounces at lists.scilab.org] *De la part de* >> St?phane Mottelet >> *Envoy? :* mardi 29 janvier 2019 16:50 >> *? :* users at lists.scilab.org >> *Objet :* [EXTERNAL] Re: [Scilab-users] acos leads to complex values >> >> Le 29/01/2019 ? 16:45, Carrico, Paul a ?crit : >> >> Dear All >> >> I spent some time in looking for a mistake in my code ; finally >> I?ve found that the ACOS of a real vector leads to some complex >> values (???) >> >> acos(Scar_P(:,1)./CM_x_CN(:,1)) >> >> Are your really sure, because we may have >> >> --> x=-1-%eps >> x = >> >> -1. >> >> >> --> acos(x) >> ans = >> >> 3.1415927 - 2.107D-08i >> >> S. >> >> (the formula worked so far) >> >> I checked that the input values are correct: >> >> -Comprised between [-1; 1] using MIN and MAX >> >> -Composed only of real values using ISREAL (all the vectors are >> correct) >> >> Thus I do not understand why complex values appear ? >> >> May it come from the vectorization ? >> >> Paul >> >> >> >> _______________________________________________ >> >> 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 --- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Tue Jan 29 21:16:19 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 29 Jan 2019 21:16:19 +0100 Subject: [Scilab-users] [EXTERNAL] Re: acos leads to complex values In-Reply-To: <5C50AE20.1000004@fceia.unr.edu.ar> References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> <5C50AE20.1000004@fceia.unr.edu.ar> Message-ID: <916859f7-6573-cf33-a2ee-452c30f08120@utc.fr> Le 29/01/2019 ? 20:48, Federico Miyara a ?crit?: > > I think it would be interesting to include an input argument check in > some functions prone to give complex results in limiting cases (such > as acos or asin) so that if inside the domain (to within 1 %eps) where > the output argument should be real the imaginary part is canceled. > Something like this for scalars: > > function y=acos1(x) > if isreal(x) > if -1<=x & x<=1 > y = real(acos(x)) > else > y = acos(x) > end > end > endfunction > > However, I must say that acos(1-%eps) gives on my Scilab 6.0.1 > (Windows 7, i7 processor) a result of Federico, you have to try 1+%eps or -1-%eps ! > > 0.000000021073424255447, > > being %eps > > 0.0000000000000002220446 > > I get no imaginary part. I guess there must be some dependency on the > arithmetic engine. > > > Federico Miyara > > > On 29/01/2019 12:58, St?phane Mottelet wrote: >> It is the same if x is slightly > 1: >> >> --> x=1+%eps >> ?x? = >> >> ?? 1. >> >> >> --> acos(x) >> ?ans? = >> >> ?? 2.107D-08i >> >> --> format(25); x >> ?x? = >> >> ?? 1.0000000000000002220446 >> >> Le 29/01/2019 ? 16:55, Carrico, Paul a ?crit?: >>> >>> When I scroll to the list, the lowest (positive) value is 8.4^E -08 >>> (works fine) and no %eps . >>> >>> How Can I check if %eps is in? >>> >>> *De?:*users [mailto:users-bounces at lists.scilab.org] *De la part de* >>> St?phane Mottelet >>> *Envoy??:* mardi 29 janvier 2019 16:50 >>> *??:* users at lists.scilab.org >>> *Objet?:* [EXTERNAL] Re: [Scilab-users] acos leads to complex values >>> >>> Le 29/01/2019 ? 16:45, Carrico, Paul a ?crit?: >>> >>> Dear All >>> >>> I spent some time in looking for a mistake in my code?; finally >>> I?ve found that the ACOS of a real vector leads to some complex >>> values (???) >>> >>> acos(Scar_P(:,1)./CM_x_CN(:,1)) >>> >>> Are your really sure, because we may have >>> >>> --> x=-1-%eps >>> ?x? = >>> >>> ? -1. >>> >>> >>> --> acos(x) >>> ?ans? = >>> >>> ?? 3.1415927 - 2.107D-08i >>> >>> S. >>> >>> (the formula worked so far) >>> >>> I checked that the input values are correct: >>> >>> -Comprised between [-1; 1] using MIN and MAX >>> >>> -Composed only of real values using ISREAL (all the vectors are >>> correct) >>> >>> Thus I do not understand why complex values appear ? >>> >>> May it come from the vectorization ? >>> >>> Paul >>> >>> >>> >>> _______________________________________________ >>> >>> 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 > > > > ------------------------------------------------------------------------ > Avast logo > > > > El software de antivirus Avast ha analizado este correo electr?nico en > busca de virus. > www.avast.com > > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > _______________________________________________ > 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 Jan 29 21:35:30 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Tue, 29 Jan 2019 17:35:30 -0300 Subject: [Scilab-users] [EXTERNAL] Re: acos leads to complex values In-Reply-To: References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> Message-ID: <5C50B912.8000804@fceia.unr.edu.ar> This is an improved version of the acos function with input argument check: function y=acos1(x) // Check if components are real is_real = imag(x)==0; // Leave real-only components x1 = is_real.*x; // Check if components are real and belong to [-1, 1] in_domain = is_real & (-1<=x1 & x1<=1); // Imaginary part of acos(x) is accepted only if // x does not belong to [-1, 1] y = in_domain.*real(acos(x)) + (~in_domain).*acos(x); endfunction This works on vectors and arrays as well. Unfortunately i couldn't find a component-wise isreal() function, otherwise it would have been simpler! Federico Miyara On 29/01/2019 12:58, St?phane Mottelet wrote: > It is the same if x is slightly > 1: > > --> x=1+%eps > x = > > 1. > > > --> acos(x) > ans = > > 2.107D-08i > > --> format(25); x > x = > > 1.0000000000000002220446 > > Le 29/01/2019 ? 16:55, Carrico, Paul a ?crit : >> >> When I scroll to the list, the lowest (positive) value is 8.4^E -08 >> (works fine) and no %eps . >> >> How Can I check if %eps is in? >> >> *De :*users [mailto:users-bounces at lists.scilab.org] *De la part de* >> St?phane Mottelet >> *Envoy? :* mardi 29 janvier 2019 16:50 >> *? :* users at lists.scilab.org >> *Objet :* [EXTERNAL] Re: [Scilab-users] acos leads to complex values >> >> Le 29/01/2019 ? 16:45, Carrico, Paul a ?crit : >> >> Dear All >> >> I spent some time in looking for a mistake in my code ; finally >> I?ve found that the ACOS of a real vector leads to some complex >> values (???) >> >> acos(Scar_P(:,1)./CM_x_CN(:,1)) >> >> Are your really sure, because we may have >> >> --> x=-1-%eps >> x = >> >> -1. >> >> >> --> acos(x) >> ans = >> >> 3.1415927 - 2.107D-08i >> >> S. >> >> (the formula worked so far) >> >> I checked that the input values are correct: >> >> -Comprised between [-1; 1] using MIN and MAX >> >> -Composed only of real values using ISREAL (all the vectors are >> correct) >> >> Thus I do not understand why complex values appear ? >> >> May it come from the vectorization ? >> >> Paul >> >> >> >> _______________________________________________ >> >> 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 ------------------------------------------------------------------------ Avast logo El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> --- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: avast-mail-stamp.png Type: image/png Size: 1308 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ users mailing list users at lists.scilab.org http://lists.scilab.org/mailman/listinfo/users From fmiyara at fceia.unr.edu.ar Tue Jan 29 23:10:23 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Tue, 29 Jan 2019 19:10:23 -0300 Subject: [Scilab-users] [EXTERNAL] Re: acos leads to complex values In-Reply-To: <916859f7-6573-cf33-a2ee-452c30f08120@utc.fr> References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> <5C50AE20.1000004@fceia.unr.edu.ar> <916859f7-6573-cf33-a2ee-452c30f08120@utc.fr> Message-ID: <5C50CF4F.4040302@fceia.unr.edu.ar> Stephane, >> However, I must say that acos(1-%eps) gives on my Scilab 6.0.1 >> (Windows 7, i7 processor) a result of > Federico, you have to try 1+%eps or -1-%eps ! acos(x) with x > 1 is indeed imaginary, so there is no unexpected result. However, I see now that it hadn't been said that in-domain arguments yielded complex results but -1 - %eps was the culprit. But, for instance, min([-1-%eps, -1-%eps*2/3, -1, -1+ %eps, -0.9]) >= -1 is false (on my system), so the test performed by Paul Carrico would not succeed if there were a -1-%eps among the values of the vector. Only when alpha*%eps with alpha < 0.5 is the minimum the test is successful, but in such case acos() yields a value close to %pi, not a complex value --> acos(-1 - 0.499*%eps) ans = 3.141592653589793100000 When alpha > 0.5 the test is not successful nor is the acos() real: --> acos(-1 - 0.50000001*%eps) ans = 3.141592653589793100000 - 0.000000021073424255447i (this is a binary rounding situation since %eps is 2^-52) I think the original question is not completely solved. Why a number that is not smaller to -1 (asuming the min test is successful) yields a complex acos? An why it does in some systems and not in others? (Assuming Paul's report is accurate) There is another situation where this happens, when an fft is performed on a real signal, then filtered in the frequency domain and then the ifft is applied. The result should be real, but sometimes there are small imaginary parts. In this case there is a reason, complex exponentials are used in the algorithm so arithmetioc errors may not completely cancel out because of arithmetic and precision issues. Federico Miyara --- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Tue Jan 29 23:38:45 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 29 Jan 2019 23:38:45 +0100 Subject: [Scilab-users] [EXTERNAL] Re: acos leads to complex values In-Reply-To: <5C50CF4F.4040302@fceia.unr.edu.ar> References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> <5C50AE20.1000004@fceia.unr.edu.ar> <916859f7-6573-cf33-a2ee-452c30f08120@utc.fr> <5C50CF4F.4040302@fceia.unr.edu.ar> Message-ID: Le 29/01/2019 ? 23:10, Federico Miyara a ?crit?: > > Stephane, > >>> However, I must say that acos(1-%eps) gives on my Scilab 6.0.1 >>> (Windows 7, i7 processor) a result of >> Federico, you have to try 1+%eps or -1-%eps ! > > acos(x) with x > 1 is indeed imaginary, so there is no unexpected result. > > However, I see now that it hadn't been said that in-domain arguments > yielded complex results but -1 - %eps was the culprit. > > But, for instance, > > min([-1-%eps, -1-%eps*2/3, -1, -1+ %eps, -0.9]) >= -1 > > is false (on my system), so the test performed by Paul Carrico would > not succeed if there were a -1-%eps among the values of the vector. > > Only when alpha*%eps? with alpha < 0.5 is the minimum the test is > successful, but in such case acos() yields a value close to %pi, not a > complex value > > --> acos(-1 - 0.499*%eps) > ?ans? = > > ?? 3.141592653589793100000 logical, since --> -1 - 0.499*%eps == -1 ?ans? = ? T --> acos(-1 - 0.499*%eps)==%pi ?ans? = ? T S. > > When alpha > 0.5 the test is not successful nor is the acos() real: > > --> acos(-1 - 0.50000001*%eps) > ?ans? = > > ?? 3.141592653589793100000 - 0.000000021073424255447i > > (this is a binary rounding situation since %eps is 2^-52) > > I think the original question is not completely solved. Why a number > that is not smaller to -1 (asuming the min test is successful) yields > a complex acos? > > An why it does in some systems and not in others? (Assuming Paul's > report is accurate) > > There is another situation where this happens, when an fft is > performed on a real signal, then filtered in the frequency domain and > then the ifft is applied. The result should be real, but sometimes > there are small imaginary parts. > > In this case there is a reason, complex exponentials are used in the > algorithm so arithmetioc errors may not completely cancel out because > of arithmetic and precision issues. > > Federico Miyara > > > ------------------------------------------------------------------------ > Avast logo > > > > El software de antivirus Avast ha analizado este correo electr?nico en > busca de virus. > www.avast.com > > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > _______________________________________________ > 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 Christophe.Dang at sidel.com Wed Jan 30 09:13:26 2019 From: Christophe.Dang at sidel.com (Dang Ngoc Chan, Christophe) Date: Wed, 30 Jan 2019 08:13:26 +0000 Subject: [Scilab-users] {EXT} Re: [EXTERNAL] Re: acos leads to complex values In-Reply-To: <5C50B912.8000804@fceia.unr.edu.ar> References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> <5C50B912.8000804@fceia.unr.edu.ar> Message-ID: Hello, > De : Federico Miyara > Envoy? : mardi 29 janvier 2019 21:36 > > This is an improved version of the acos function with input argument check: I would personally write it in the following way: function y=acos1(x) // Check if components are real // Check if components are real and belong to [-1, 1] absx = abs(x); in_domain = (imag(x)==0) & (-1<=absx) & (absx<=1); // Imaginary part of acos(x) is accepted only if // x does not belong to [-1, 1] y=acos(x); y(in_domain) = real(y(in_domain)); endfunction Regards -- Christophe Dang Ngoc Chan Mechanical calculation engineer Public 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmiyara at fceia.unr.edu.ar Wed Jan 30 23:02:52 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Wed, 30 Jan 2019 19:02:52 -0300 Subject: [Scilab-users] Unexpected END OF FILE In-Reply-To: <916859f7-6573-cf33-a2ee-452c30f08120@utc.fr> References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> <5C50AE20.1000004@fceia.unr.edu.ar> <916859f7-6573-cf33-a2ee-452c30f08120@utc.fr> Message-ID: <5C521F0C.6090402@fceia.unr.edu.ar> Dear all, I'm trying to read data from a file (in this case a wave file) with the following code (Scilab 6.0.1) fid = mopen('g:\Mis documentos\Ondas\440Hz_0.2s.wav', 'r') mseek(0, fid) h = mgeti(1000,'uc',fid) I should get a vector with 1000 unsigned 1 byte integer components but I end with only 164 entries. Viewing the file with an hex viewer, the last correctly read data are 34 3E 34 3E (decimal 52 62 52 62) Then the following data and further data 1A 3D 1A 3D? ... are not read at all. No warning like having reached EOF. By the way, the repeated pairs are because it is a stereo file with identical left and right channels. The same happens changing the way the file data are to be decoded. Seems to get stuck when 1A or 1A 3D appears. Any idea of what may be going on and how to solve it? Federico Miyara <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> --- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 440Hz_0.2s.wav Type: audio/x-wav Size: 40332 bytes Desc: not available URL: From antoine.elias at scilab-enterprises.com Thu Jan 31 00:07:58 2019 From: antoine.elias at scilab-enterprises.com (Antoine ELIAS) Date: Thu, 31 Jan 2019 00:07:58 +0100 Subject: [Scilab-users] Unexpected END OF FILE In-Reply-To: <5C521F0C.6090402@fceia.unr.edu.ar> References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> <5C50AE20.1000004@fceia.unr.edu.ar> <916859f7-6573-cf33-a2ee-452c30f08120@utc.fr> <5C521F0C.6090402@fceia.unr.edu.ar> Message-ID: Hello Frederico, On Windows, you should open your file in binary mode, with "rb". --> fd = mopen("440Hz_0.2s.wav", "rb"); --> h = mgeti(1000, "uc", fd); --> size(h) ?ans? = ?? 1.?? 1000. --> dec2hex(h(1:5)) ?ans? = !52? 49? 46? 46? 84? ! Regards, Antoine Le 30/01/2019 ? 23:02, Federico Miyara a ?crit?: > > Dear all, > > I'm trying to read data from a file (in this case a wave file) with > the following code (Scilab 6.0.1) > fid = mopen('g:\Mis documentos\Ondas\440Hz_0.2s.wav', 'r') > mseek(0, fid) > h = mgeti(1000,'uc',fid) > I should get a vector with 1000 unsigned 1 byte integer components but > I end with only 164 entries. Viewing the file with an hex viewer, the > last correctly read data are > > 34 3E 34 3E > > (decimal 52 62 52 62) > > Then the following data and further data > > 1A 3D 1A 3D?? ... > > are not read at all. No warning like having reached EOF. By the way, > the repeated pairs are because it is a stereo file with identical left > and right channels. > > The same happens changing the way the file data are to be decoded. > Seems to get stuck when 1A or 1A 3D appears. > > Any idea of what may be going on and how to solve it? > > Federico Miyara > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > _______________________________________________ > 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 Jan 31 01:20:58 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Wed, 30 Jan 2019 21:20:58 -0300 Subject: [Scilab-users] Unexpected END OF FILE In-Reply-To: References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> <5C50AE20.1000004@fceia.unr.edu.ar> <916859f7-6573-cf33-a2ee-452c30f08120@utc.fr> <5C521F0C.6090402@fceia.unr.edu.ar> Message-ID: <5C523F6A.1020508@fceia.unr.edu.ar> Antoine, Thank you VERY MUCH! That works. Is there a fundamental reason why not specifying binary fails somewhere? Some sort of EOF code that may present itself randomly according to file content? Regards, Federico On 30/01/2019 20:07, Antoine ELIAS wrote: > Hello Frederico, > > On Windows, you should open your file in binary mode, with "rb". > --> fd = mopen("440Hz_0.2s.wav", "rb"); > --> h = mgeti(1000, "uc", fd); > --> size(h) > ans = > 1. 1000. > > --> dec2hex(h(1:5)) > ans = > !52 49 46 46 84 ! > > Regards, > Antoine > Le 30/01/2019 ? 23:02, Federico Miyara a ?crit : >> >> Dear all, >> >> I'm trying to read data from a file (in this case a wave file) with >> the following code (Scilab 6.0.1) >> fid = mopen('g:\Mis documentos\Ondas\440Hz_0.2s.wav', 'r') >> mseek(0, fid) >> h = mgeti(1000,'uc',fid) >> I should get a vector with 1000 unsigned 1 byte integer components >> but I end with only 164 entries. Viewing the file with an hex viewer, >> the last correctly read data are >> >> 34 3E 34 3E >> >> (decimal 52 62 52 62) >> >> Then the following data and further data >> >> 1A 3D 1A 3D? ... >> >> are not read at all. No warning like having reached EOF. By the way, >> the repeated pairs are because it is a stereo file with identical >> left and right channels. >> >> The same happens changing the way the file data are to be decoded. >> Seems to get stuck when 1A or 1A 3D appears. >> >> Any idea of what may be going on and how to solve it? >> >> Federico Miyara >> >> >> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >> _______________________________________________ >> 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 --- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Thu Jan 31 07:27:35 2019 From: stephane.mottelet at utc.fr (=?utf-8?Q?St=C3=A9phane_Mottelet?=) Date: Thu, 31 Jan 2019 07:27:35 +0100 Subject: [Scilab-users] Unexpected END OF FILE In-Reply-To: <5C523F6A.1020508@fceia.unr.edu.ar> References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> <5C50AE20.1000004@fceia.unr.edu.ar> <916859f7-6573-cf33-a2ee-452c30f08120@utc.fr> <5C521F0C.6090402@fceia.unr.edu.ar> <5C523F6A.1020508@fceia.unr.edu.ar> Message-ID: <1B9C57B7-5F1D-4EF6-BD68-E624D2688416@utc.fr> Hello Frederico, We just fixed it for Scilab 6.0.2, see https://codereview.scilab.org/#/c/20688/ S. > Le 31 janv. 2019 ? 01:20, Federico Miyara a ?crit : > > > Antoine, > > Thank you VERY MUCH! > > That works. Is there a fundamental reason why not specifying binary fails somewhere? Some sort of EOF code that may present itself randomly according to file content? > > Regards, > > Federico > > >> On 30/01/2019 20:07, Antoine ELIAS wrote: >> Hello Frederico, >> >> On Windows, you should open your file in binary mode, with "rb". >> --> fd = mopen("440Hz_0.2s.wav", "rb"); >> --> h = mgeti(1000, "uc", fd); >> --> size(h) >> ans = >> 1. 1000. >> >> --> dec2hex(h(1:5)) >> ans = >> !52 49 46 46 84 ! >> >> Regards, >> Antoine >>> Le 30/01/2019 ? 23:02, Federico Miyara a ?crit : >>> >>> Dear all, >>> >>> I'm trying to read data from a file (in this case a wave file) with the following code (Scilab 6.0.1) >>> fid = mopen('g:\Mis documentos\Ondas\440Hz_0.2s.wav', 'r') >>> mseek(0, fid) >>> h = mgeti(1000,'uc',fid) >>> I should get a vector with 1000 unsigned 1 byte integer components but I end with only 164 entries. Viewing the file with an hex viewer, the last correctly read data are >>> >>> 34 3E 34 3E >>> >>> (decimal 52 62 52 62) >>> >>> Then the following data and further data >>> >>> 1A 3D 1A 3D? ... >>> >>> are not read at all. No warning like having reached EOF. By the way, the repeated pairs are because it is a stereo file with identical left and right channels. >>> >>> The same happens changing the way the file data are to be decoded. Seems to get stuck when 1A or 1A 3D appears. >>> >>> Any idea of what may be going on and how to solve it? >>> >>> Federico Miyara >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Thu Jan 31 08:30:34 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 31 Jan 2019 08:30:34 +0100 Subject: [Scilab-users] Unexpected END OF FILE In-Reply-To: <1B9C57B7-5F1D-4EF6-BD68-E624D2688416@utc.fr> References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> <5C50AE20.1000004@fceia.unr.edu.ar> <916859f7-6573-cf33-a2ee-452c30f08120@utc.fr> <5C521F0C.6090402@fceia.unr.edu.ar> <5C523F6A.1020508@fceia.unr.edu.ar> <1B9C57B7-5F1D-4EF6-BD68-E624D2688416@utc.fr> Message-ID: <320f14e7-60d5-16a6-a3f4-a888b0bed0f7@utc.fr> Le 31/01/2019 ? 07:27, St?phane Mottelet a ?crit?: > Hello Frederico, > > We just fixed it for Scilab 6.0.2, see > > https://codereview.scilab.org/#/c/20688/ > > > S. I mean, the doc says that binary mode for writing or reading is the default but it was not the case under Windows, where *text* mode was the default, and in this mode char of hex code 1A is EOF (in binary EOF is just a condition not a char). S. > > Le 31 janv. 2019 ? 01:20, Federico Miyara > a ?crit?: > >> >> Antoine, >> >> Thank you VERY MUCH! >> >> That works. Is there a fundamental reason why not specifying binary >> fails somewhere? Some sort of EOF code that may present itself >> randomly according to file content? >> >> Regards, >> >> Federico >> >> >> On 30/01/2019 20:07, Antoine ELIAS wrote: >>> Hello Frederico, >>> >>> On Windows, you should open your file in binary mode, with "rb". >>> --> fd = mopen("440Hz_0.2s.wav", "rb"); >>> --> h = mgeti(1000, "uc", fd); >>> --> size(h) >>> ?ans? = >>> ?? 1.?? 1000. >>> >>> --> dec2hex(h(1:5)) >>> ?ans? = >>> !52? 49? 46? 46? 84? ! >>> >>> Regards, >>> Antoine >>> Le 30/01/2019 ? 23:02, Federico Miyara a ?crit?: >>>> >>>> Dear all, >>>> >>>> I'm trying to read data from a file (in this case a wave file) with >>>> the following code (Scilab 6.0.1) >>>> fid = mopen('g:\Mis documentos\Ondas\440Hz_0.2s.wav', 'r') >>>> mseek(0, fid) >>>> h = mgeti(1000,'uc',fid) >>>> I should get a vector with 1000 unsigned 1 byte integer components >>>> but I end with only 164 entries. Viewing the file with an hex >>>> viewer, the last correctly read data are >>>> >>>> 34 3E 34 3E >>>> >>>> (decimal 52 62 52 62) >>>> >>>> Then the following data and further data >>>> >>>> 1A 3D 1A 3D?? ... >>>> >>>> are not read at all. No warning like having reached EOF. By the >>>> way, the repeated pairs are because it is a stereo file with >>>> identical left and right channels. >>>> >>>> The same happens changing the way the file data are to be decoded. >>>> Seems to get stuck when 1A or 1A 3D appears. >>>> >>>> Any idea of what may be going on and how to solve it? >>>> >>>> Federico Miyara >>>> >>>> >>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>>> >>>> _______________________________________________ >>>> 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 >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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 Thu Jan 31 08:55:58 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Thu, 31 Jan 2019 04:55:58 -0300 Subject: [Scilab-users] Unexpected END OF FILE In-Reply-To: <320f14e7-60d5-16a6-a3f4-a888b0bed0f7@utc.fr> References: <3A6B7233274DB449A2A0053A47684F953FF1DAE6@BGS-EX01.auxitrol.ad> <3c32884c-3845-1f84-859d-180a05f4db98@utc.fr> <3A6B7233274DB449A2A0053A47684F953FF1DAF9@BGS-EX01.auxitrol.ad> <5C50AE20.1000004@fceia.unr.edu.ar> <916859f7-6573-cf33-a2ee-452c30f08120@utc.fr> <5C521F0C.6090402@fceia.unr.edu.ar> <5C523F6A.1020508@fceia.unr.edu.ar> <1B9C57B7-5F1D-4EF6-BD68-E624D2688416@utc.fr> <320f14e7-60d5-16a6-a3f4-a888b0bed0f7@utc.fr> Message-ID: <5C52AA0E.5070603@fceia.unr.edu.ar> St?phane, > I mean, the doc says that binary mode for writing or reading is the > default but it was not the case under Windows, where *text* mode was > the default, and in this mode char of hex code 1A is EOF (in binary > EOF is just a condition not a char). > Thank you for crlarifying. Now I completely understand the issue! Regards, Federico --- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus From paul.carrico at esterline.com Thu Jan 31 09:07:25 2019 From: paul.carrico at esterline.com (Carrico, Paul) Date: Thu, 31 Jan 2019 08:07:25 +0000 Subject: [Scilab-users] Scilab nighly builds Message-ID: <3A6B7233274DB449A2A0053A47684F953FF1DF23@BGS-EX01.auxitrol.ad> Hi All, A recent post reminded me that I do not see for a while the nightly builds in the download page (since the website has been updated) ; the 6.01 one is nearly 1 year old Thus I'm wondering how to get a newer release, even in development ? Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Thu Jan 31 09:26:42 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 31 Jan 2019 09:26:42 +0100 Subject: [Scilab-users] Scilab nighly builds In-Reply-To: <3A6B7233274DB449A2A0053A47684F953FF1DF23@BGS-EX01.auxitrol.ad> References: <3A6B7233274DB449A2A0053A47684F953FF1DF23@BGS-EX01.auxitrol.ad> Message-ID: <4e327ecb-f4cc-a95d-df4c-1f900e1bd9f8@utc.fr> They are here (bottom of the page) https://www.scilab.org/about/scilab-open-source-software We could suggest to ESI to move them in the download page ! S. Le 31/01/2019 ? 09:07, Carrico, Paul a ?crit?: > > Hi All, > > A recent post reminded me that I do not see for a while the nightly > builds in the download page (since the website has been updated) ; the > 6.01 one is nearly 1 year old > > Thus I?m wondering how to get a newer release, even in development ? > > Paul > > > _______________________________________________ > 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 paul.carrico at esterline.com Thu Jan 31 09:29:34 2019 From: paul.carrico at esterline.com (Carrico, Paul) Date: Thu, 31 Jan 2019 08:29:34 +0000 Subject: [Scilab-users] [EXTERNAL] Re: Scilab nighly builds In-Reply-To: <4e327ecb-f4cc-a95d-df4c-1f900e1bd9f8@utc.fr> References: <3A6B7233274DB449A2A0053A47684F953FF1DF23@BGS-EX01.auxitrol.ad> <4e327ecb-f4cc-a95d-df4c-1f900e1bd9f8@utc.fr> Message-ID: <3A6B7233274DB449A2A0053A47684F953FF1DF47@BGS-EX01.auxitrol.ad> Ah yes ... +1 for Stephane proposal Paul De : users [mailto:users-bounces at lists.scilab.org] De la part de St?phane Mottelet Envoy? : jeudi 31 janvier 2019 09:27 ? : users at lists.scilab.org Objet : [EXTERNAL] Re: [Scilab-users] Scilab nighly builds They are here (bottom of the page) https://www.scilab.org/about/scilab-open-source-software We could suggest to ESI to move them in the download page ! S. Le 31/01/2019 ? 09:07, Carrico, Paul a ?crit : Hi All, A recent post reminded me that I do not see for a while the nightly builds in the download page (since the website has been updated) ; the 6.01 one is nearly 1 year old Thus I'm wondering how to get a newer release, even in development ? Paul _______________________________________________ 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 paul.carrico at esterline.com Thu Jan 31 10:39:30 2019 From: paul.carrico at esterline.com (Carrico, Paul) Date: Thu, 31 Jan 2019 09:39:30 +0000 Subject: [Scilab-users] nightly build (latest) release Message-ID: <3A6B7233274DB449A2A0053A47684F953FF1DFBC@BGS-EX01.auxitrol.ad> Just a feedback on the latest branch/nightly build release I downloaded this moring: - Scilab opens and immediately closes under Windows 7 (64 bits) - It does not open and remains blocked without opening under CentOS 7 (64 bits) I'm going back to the old one Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.elias at scilab-enterprises.com Thu Jan 31 11:20:06 2019 From: antoine.elias at scilab-enterprises.com (Antoine ELIAS) Date: Thu, 31 Jan 2019 11:20:06 +0100 Subject: [Scilab-users] nightly build (latest) release In-Reply-To: <3A6B7233274DB449A2A0053A47684F953FF1DFBC@BGS-EX01.auxitrol.ad> References: <3A6B7233274DB449A2A0053A47684F953FF1DFBC@BGS-EX01.auxitrol.ad> Message-ID: <113472d9-2670-4b21-0076-91624f813727@scilab-enterprises.com> Thank you Paul ! It seems that in the packaged Windows version some files are missing in xml module. I will fix that asap. Antoine Le 31/01/2019 ? 10:39, Carrico, Paul a ?crit?: > > Just a feedback on the latest branch/nightly build release?I > downloaded this moring: > > -Scilab opens and immediately closes under Windows 7 (64 bits) > > -It does not open and remains blocked without opening ?under CentOS 7 > (64 bits) > > I?m going back to the old one > > Paul > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From iwoj at il.pw.edu.pl Thu Jan 31 19:06:40 2019 From: iwoj at il.pw.edu.pl (=?UTF-8?Q?Izabela_W=C3=B3jcik-Grz=C4=85ba?=) Date: Thu, 31 Jan 2019 19:06:40 +0100 Subject: [Scilab-users] Different results inside a function and in the console Message-ID: <2c4f82fd22fb913acd2b1043e3d54084@il.pw.edu.pl> Hello, I have a strange problem with simple calculations which are done inside a function. I will put here exact data and formula: p_x= 0. 0. 0. 0. 0. 0. p_x_pocz= 0. 0. 0. 0. 0. 0. reakcje= 1. 1.03 2.1 -2.1 1. 2. 4. 0.92 2.45 -2.45 5. 2. luzne_nr= 1. 4. u= 4.6 3.6 -2.4 -4.4 -1.4 l_poziom= 5.1 4.56 p_x(reakcje(:,5))=p_x_pocz(reakcje(:,5))+u(luzne_nr).*reakcje(:,2)./l_poziom; When it is calculated inside the function I get a result: p_x= 0.93 0. 0. 0. -0.89 When I use the same data and formula in the Console I get a correct result: p_x = 0.93 0. 0. 0. -0.89 0. To check the input values I displayed the input data before the formula in the function with disp, and then I used these values for calculations in the Console. Has andybody any idea what can be wrong? Am I missing something? Thanks for any help. Kind regards, Iza From fmiyara at fceia.unr.edu.ar Thu Jan 31 22:40:22 2019 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Thu, 31 Jan 2019 18:40:22 -0300 Subject: [Scilab-users] Different results inside a function and in the console In-Reply-To: <2c4f82fd22fb913acd2b1043e3d54084@il.pw.edu.pl> References: <2c4f82fd22fb913acd2b1043e3d54084@il.pw.edu.pl> Message-ID: <5C536B46.3070102@fceia.unr.edu.ar> Izabela, It is difficult to tell what's happening without seeing the function code. However, it appears as if variable p_x were cleared or redefined to have only 5 components prior to the assignment of two of its elements (those with indices 1 and 5) when executing the formula. What I would do is to create a new function removing all function code not related to the problem, trying to track what happens to p_x before applying the formula. Regards, Federico Miyara On 31/01/2019 15:06, Izabela W?jcik-Grz?ba wrote: > Hello, > > I have a strange problem with simple calculations which are done > inside a function. I will put here exact data and formula: > > p_x= > > 0. > 0. > 0. > 0. > 0. > 0. > > p_x_pocz= > > 0. > 0. > 0. > 0. > 0. > 0. > > reakcje= > > 1. 1.03 2.1 -2.1 1. 2. > 4. 0.92 2.45 -2.45 5. 2. > > luzne_nr= > > 1. > 4. > > u= > > 4.6 > 3.6 > -2.4 > -4.4 > -1.4 > > l_poziom= > > 5.1 > 4.56 > > p_x(reakcje(:,5))=p_x_pocz(reakcje(:,5))+u(luzne_nr).*reakcje(:,2)./l_poziom; > > > When it is calculated inside the function I get a result: > > p_x= > > 0.93 > 0. > 0. > 0. > -0.89 > > When I use the same data and formula in the Console I get a correct > result: > > p_x = > > 0.93 > 0. > 0. > 0. > -0.89 > 0. > > To check the input values I displayed the input data before the > formula in the function with disp, and then I used these values for > calculations in the Console. > > Has andybody any idea what can be wrong? Am I missing something? > > Thanks for any help. > > Kind regards, > Iza > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > --- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: