Hello all,
The subject has been already discussed a lot but I would like it to be discussed again because I now have a real rationale to promote a change in the way complex numbers with small imaginary part are displayed. I don't know if some of you were aware of the clever technique of complex-step derivative approximation, but until yesterday I was not (see e.g. http://mdolab.engin.umich.edu/sites/default/files/Martins2003CSD.pdf). Roughly speaking, using the extension of a real function x->f(x) to the complex plane allows to compute an approximation of the derivative f'(x0) at a real x0 without using a substraction, like in the central difference formula (f(x0+h)-f(x0-h))/2/h which is subject to substractive cancelation when h is small. In Scilab most operators and elementary functions are already complex-aware so this is easy to illustrate the technique. For example let us approximate the derivative of x->cos(x) at x=%pi/4, first with the central difference formula, then with the complex step technique: --> format("e",24) --> h=%eps/128, x0=%pi/4 h = 1.73472347597680709D-18 x0 = 7.85398163397448279D-01 --> (cos(x0+h)-cos(x0-h))/2/h ans = 0.00000000000000000D+00 --> imag(cos(x0+%i*h))/h ans = -7.07106781186547462D-01 --> -sin(x0) ans = -7.07106781186547462D-01 You can see the pathological approximation with central difference formula and the perfect (up to relative machine precision) approximation of complex-step formula. However, the following is a pity: --> cos(x0+%i*h) ans = 7.07106781186547573D-01 We cannot see the imaginary part although seeing the latter is fundamental in the complex-step technique. We have to force the display like this, and frankly I don't like having to do that with my students: --> imag(cos(x0+%i*h)) ans = -1.22663473334669916D-18 I hope that you will find that this example is a good rationale to change the default display of Scilab. To feed the discussion, here is how Matlab displays things, without having to change the default settings: >> h=eps/128, x0=pi/4 h = 1.7347e-18 x0 = 0.7854 >> (cos(x0+h)-cos(x0-h))/2/h ans = 0 >> cos(x0+i*h) ans = 0.7071 - 0.0000i >> imag(cos(x0+i*h))/h ans = -0.7071 >> -sin(x0) ans = -0.7071 -- 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 [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Antoine ELIAS-2 |
Hello Stéphane,
In Scilab 6.0.2 without format("e", 24) --> h = %eps/128, x0=%pi/4 h = 1.735D-18 x0 = 0.7853982 --> (cos(x0+h)-cos(x0-h))/2/h ans = 0. --> cos(x0+%i*h) ans = 0.7071068 --> imag(cos(x0+%i*h))/h ans = -0.7071068 --> -sin(x0) ans = -0.7071068 It seems to be close of Matlab's outputs, no ? I probably not understand your problem ... Antoine Le 12/09/2019 à 10:26, Stéphane Mottelet a écrit : > Hello all, > > The subject has been already discussed a lot but I would like it to be > discussed again because I now have a real rationale to promote a > change in the way complex numbers with small imaginary part are > displayed. > > I don't know if some of you were aware of the clever technique of > complex-step derivative approximation, but until yesterday I was not > (see e.g. > http://mdolab.engin.umich.edu/sites/default/files/Martins2003CSD.pdf). > Roughly speaking, using the extension of a real function x->f(x) to > the complex plane allows to compute an approximation of the derivative > f'(x0) at a real x0 without using a substraction, like in the central > difference formula (f(x0+h)-f(x0-h))/2/h which is subject to > substractive cancelation when h is small. In Scilab most operators and > elementary functions are already complex-aware so this is easy to > illustrate the technique. For example let us approximate the > derivative of x->cos(x) at x=%pi/4, first with the central difference > formula, then with the complex step technique: > > --> format("e",24) > > --> h=%eps/128, x0=%pi/4 > h = > > 1.73472347597680709D-18 > > x0 = > > 7.85398163397448279D-01 > > > --> (cos(x0+h)-cos(x0-h))/2/h > ans = > > 0.00000000000000000D+00 > > > --> imag(cos(x0+%i*h))/h > ans = > > -7.07106781186547462D-01 > > > --> -sin(x0) > ans = > > -7.07106781186547462D-01 > > You can see the pathological approximation with central difference > formula and the perfect (up to relative machine precision) > approximation of complex-step formula. > > However, the following is a pity: > > > --> cos(x0+%i*h) > ans = > > 7.07106781186547573D-01 > > We cannot see the imaginary part although seeing the latter is > fundamental in the complex-step technique. We have to force the > display like this, and frankly I don't like having to do that with my > students: > > --> imag(cos(x0+%i*h)) > ans = > > -1.22663473334669916D-18 > > I hope that you will find that this example is a good rationale to > change the default display of Scilab. To feed the discussion, here is > how Matlab displays things, without having to change the default > settings: > > > >> h=eps/128, x0=pi/4 > h = > 1.7347e-18 > x0 = > 0.7854 > > >> (cos(x0+h)-cos(x0-h))/2/h > ans = > 0 > > >> cos(x0+i*h) > ans = > 0.7071 - 0.0000i > > >> imag(cos(x0+i*h))/h > ans = > -0.7071 > > >> -sin(x0) > ans = > -0.7071 > > _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Le 12/09/2019 à 11:55, Antoine ELIAS a écrit : > Hello Stéphane, > > In Scilab 6.0.2 without format("e", 24) > > --> h = %eps/128, x0=%pi/4 > h = > 1.735D-18 > > x0 = > 0.7853982 > > --> (cos(x0+h)-cos(x0-h))/2/h > ans = > 0. > > --> cos(x0+%i*h) > ans = > 0.7071068 > > --> imag(cos(x0+%i*h))/h > ans = > -0.7071068 > > --> -sin(x0) > ans = > -0.7071068 > > It seems to be close of Matlab's outputs, no ? No, Scilab display is singularly different: --> cos(x0+%i*h) ans = 0.7071068 the above has an imaginary part, which is quite small, but essential in the computation. Matlab is quite explicit here: >> cos(x0+i*h) ans = 0.7071 - 0.0000i > I probably not understand your problem ... > > Antoine > Le 12/09/2019 à 10:26, Stéphane Mottelet a écrit : >> Hello all, >> >> The subject has been already discussed a lot but I would like it to >> be discussed again because I now have a real rationale to promote a >> change in the way complex numbers with small imaginary part are >> displayed. >> >> I don't know if some of you were aware of the clever technique of >> complex-step derivative approximation, but until yesterday I was not >> (see e.g. >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mdolab.engin.umich.edu/sites/default/files/Martins2003CSD.pdf). >> Roughly speaking, using the extension of a real function x->f(x) to >> the complex plane allows to compute an approximation of the >> derivative f'(x0) at a real x0 without using a substraction, like in >> the central difference formula (f(x0+h)-f(x0-h))/2/h which is subject >> to substractive cancelation when h is small. In Scilab most operators >> and elementary functions are already complex-aware so this is easy to >> illustrate the technique. For example let us approximate the >> derivative of x->cos(x) at x=%pi/4, first with the central difference >> formula, then with the complex step technique: >> >> --> format("e",24) >> >> --> h=%eps/128, x0=%pi/4 >> h = >> >> 1.73472347597680709D-18 >> >> x0 = >> >> 7.85398163397448279D-01 >> >> >> --> (cos(x0+h)-cos(x0-h))/2/h >> ans = >> >> 0.00000000000000000D+00 >> >> >> --> imag(cos(x0+%i*h))/h >> ans = >> >> -7.07106781186547462D-01 >> >> >> --> -sin(x0) >> ans = >> >> -7.07106781186547462D-01 >> >> You can see the pathological approximation with central difference >> formula and the perfect (up to relative machine precision) >> approximation of complex-step formula. >> >> However, the following is a pity: >> >> >> --> cos(x0+%i*h) >> ans = >> >> 7.07106781186547573D-01 >> >> We cannot see the imaginary part although seeing the latter is >> fundamental in the complex-step technique. We have to force the >> display like this, and frankly I don't like having to do that with my >> students: >> >> --> imag(cos(x0+%i*h)) >> ans = >> >> -1.22663473334669916D-18 >> >> I hope that you will find that this example is a good rationale to >> change the default display of Scilab. To feed the discussion, here is >> how Matlab displays things, without having to change the default >> settings: >> >> >> >> h=eps/128, x0=pi/4 >> h = >> 1.7347e-18 >> x0 = >> 0.7854 >> >> >> (cos(x0+h)-cos(x0-h))/2/h >> ans = >> 0 >> >> >> cos(x0+i*h) >> ans = >> 0.7071 - 0.0000i >> >> >> imag(cos(x0+i*h))/h >> ans = >> -0.7071 >> >> >> -sin(x0) >> ans = >> -0.7071 >> >> > > _______________________________________________ > users mailing list > [hidden email] > 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 [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Christophe Dang Ngoc Chan |
In reply to this post by mottelet
Hello,
> De la part de Stéphane Mottelet > Envoyé : jeudi 12 septembre 2019 10:26 > > I now have a real rationale to promote a change in > the way complex numbers with small imaginary part are displayed. I agree with you. I would add another advantage: the user is not always aware that the result of a function is a complex; the typical case is the use of roots() when the expected result is real. It sometimes causes problems as some other function do not accept complex numbers as patrameters. Regards -- Christophe Dang Ngoc Chan Mechanical calculation engineer General This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Le 12/09/2019 à 14:19, Dang Ngoc Chan, Christophe a écrit : > Hello, > >> De la part de Stéphane Mottelet >> Envoyé : jeudi 12 septembre 2019 10:26 >> >> I now have a real rationale to promote a change in >> the way complex numbers with small imaginary part are displayed. > I agree with you. > > I would add another advantage: > the user is not always aware that the result of a function is a complex; > the typical case is the use of roots() when the expected result is real. > It sometimes causes problems as some other function > do not accept complex numbers as patrameters. You are right. This basic rationale (compared to the over-sophisticated I proposed...) has been invoked many times and should have been enough to change things. There is already a proposal here: https://codereview.scilab.org/#/c/20981/ > > Regards > > -- > Christophe Dang Ngoc Chan > Mechanical calculation engineer > > General > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. > _______________________________________________ > users mailing list > [hidden email] > 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 [hidden email] http://lists.scilab.org/mailman/listinfo/users |
In reply to this post by mottelet
I prefer the display after applying
https://codereview.scilab.org/#/c/20981/: --> x0=%pi/4;h=%eps/2 h = 1.110D-16 --> cos(x0+%i*h) ans = 0.7071068 - 7.850D-17i However, we could discuss if the arbitrary switch to "e" mode is desirable or not, but since Scilab 6.0 we have got used to this display mixing "v" and "e" mode... BTW, this patch also fixes the more general problem of ambiguous display of quantities like (below is the display after the patch) --> 1+%eps ans = 1.0000000 Currently Scilab makes users believe that a complex/non real number is real by hiding small non-zero real parts, and makes users believe that a non-integer number is integer by hiding zeros in the fractional part. Each year I have to warn my students, and I am really getting upset about this. The aforementionned patch also fixes that. S. Le 12/09/2019 à 11:59, Stéphane Mottelet a écrit : > > Le 12/09/2019 à 11:55, Antoine ELIAS a écrit : >> Hello Stéphane, >> >> In Scilab 6.0.2 without format("e", 24) >> >> --> h = %eps/128, x0=%pi/4 >> h = >> 1.735D-18 >> >> x0 = >> 0.7853982 >> >> --> (cos(x0+h)-cos(x0-h))/2/h >> ans = >> 0. >> >> --> cos(x0+%i*h) >> ans = >> 0.7071068 >> >> --> imag(cos(x0+%i*h))/h >> ans = >> -0.7071068 >> >> --> -sin(x0) >> ans = >> -0.7071068 >> >> It seems to be close of Matlab's outputs, no ? > > No, Scilab display is singularly different: > > --> cos(x0+%i*h) > ans = > 0.7071068 > > the above has an imaginary part, which is quite small, but essential > in the computation. Matlab is quite explicit here: > > >> cos(x0+i*h) > ans = > 0.7071 - 0.0000i > > >> I probably not understand your problem ... >> >> Antoine >> Le 12/09/2019 à 10:26, Stéphane Mottelet a écrit : >>> Hello all, >>> >>> The subject has been already discussed a lot but I would like it to >>> be discussed again because I now have a real rationale to promote a >>> change in the way complex numbers with small imaginary part are >>> displayed. >>> >>> I don't know if some of you were aware of the clever technique of >>> complex-step derivative approximation, but until yesterday I was not >>> (see e.g. >>> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mdolab.engin.umich.edu/sites/default/files/Martins2003CSD.pdf). >>> Roughly speaking, using the extension of a real function x->f(x) to >>> the complex plane allows to compute an approximation of the >>> derivative f'(x0) at a real x0 without using a substraction, like in >>> the central difference formula (f(x0+h)-f(x0-h))/2/h which is >>> subject to substractive cancelation when h is small. In Scilab most >>> operators and elementary functions are already complex-aware so this >>> is easy to illustrate the technique. For example let us approximate >>> the derivative of x->cos(x) at x=%pi/4, first with the central >>> difference formula, then with the complex step technique: >>> >>> --> format("e",24) >>> >>> --> h=%eps/128, x0=%pi/4 >>> h = >>> >>> 1.73472347597680709D-18 >>> >>> x0 = >>> >>> 7.85398163397448279D-01 >>> >>> >>> --> (cos(x0+h)-cos(x0-h))/2/h >>> ans = >>> >>> 0.00000000000000000D+00 >>> >>> >>> --> imag(cos(x0+%i*h))/h >>> ans = >>> >>> -7.07106781186547462D-01 >>> >>> >>> --> -sin(x0) >>> ans = >>> >>> -7.07106781186547462D-01 >>> >>> You can see the pathological approximation with central difference >>> formula and the perfect (up to relative machine precision) >>> approximation of complex-step formula. >>> >>> However, the following is a pity: >>> >>> >>> --> cos(x0+%i*h) >>> ans = >>> >>> 7.07106781186547573D-01 >>> >>> We cannot see the imaginary part although seeing the latter is >>> fundamental in the complex-step technique. We have to force the >>> display like this, and frankly I don't like having to do that with >>> my students: >>> >>> --> imag(cos(x0+%i*h)) >>> ans = >>> >>> -1.22663473334669916D-18 >>> >>> I hope that you will find that this example is a good rationale to >>> change the default display of Scilab. To feed the discussion, here >>> is how Matlab displays things, without having to change the default >>> settings: >>> >>> >>> >> h=eps/128, x0=pi/4 >>> h = >>> 1.7347e-18 >>> x0 = >>> 0.7854 >>> >>> >> (cos(x0+h)-cos(x0-h))/2/h >>> ans = >>> 0 >>> >>> >> cos(x0+i*h) >>> ans = >>> 0.7071 - 0.0000i >>> >>> >> imag(cos(x0+i*h))/h >>> ans = >>> -0.7071 >>> >>> >> -sin(x0) >>> ans = >>> -0.7071 >>> >>> >> >> _______________________________________________ >> users mailing list >> [hidden email] >> 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 _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
If Windows users want to test the patch, I have prepared a Windows build
of patched Scilab at the folowing URL : http://www.utc.fr/~mottelet/scilab/download/master/scilab-branch-master-6cdd3ce0d62c632cd428b71440b0371a7731dbae_x64.exe S. Le 12/09/2019 à 18:55, Stéphane Mottelet a écrit : > I prefer the display after applying > https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/#/c/20981/: > > --> x0=%pi/4;h=%eps/2 > h = > > 1.110D-16 > > --> cos(x0+%i*h) > ans = > > 0.7071068 - 7.850D-17i > > However, we could discuss if the arbitrary switch to "e" mode is > desirable or not, but since Scilab 6.0 we have got used to this > display mixing "v" and "e" mode... > > BTW, this patch also fixes the more general problem of ambiguous > display of quantities like (below is the display after the patch) > > --> 1+%eps > ans = > > 1.0000000 > > Currently Scilab makes users believe that a complex/non real number is > real by hiding small non-zero real parts, and makes users believe that > a non-integer number is integer by hiding zeros in the fractional > part. Each year I have to warn my students, and I am really getting > upset about this. The aforementionned patch also fixes that. > > S. > > > Le 12/09/2019 à 11:59, Stéphane Mottelet a écrit : >> >> Le 12/09/2019 à 11:55, Antoine ELIAS a écrit : >>> Hello Stéphane, >>> >>> In Scilab 6.0.2 without format("e", 24) >>> >>> --> h = %eps/128, x0=%pi/4 >>> h = >>> 1.735D-18 >>> >>> x0 = >>> 0.7853982 >>> >>> --> (cos(x0+h)-cos(x0-h))/2/h >>> ans = >>> 0. >>> >>> --> cos(x0+%i*h) >>> ans = >>> 0.7071068 >>> >>> --> imag(cos(x0+%i*h))/h >>> ans = >>> -0.7071068 >>> >>> --> -sin(x0) >>> ans = >>> -0.7071068 >>> >>> It seems to be close of Matlab's outputs, no ? >> >> No, Scilab display is singularly different: >> >> --> cos(x0+%i*h) >> ans = >> 0.7071068 >> >> the above has an imaginary part, which is quite small, but essential >> in the computation. Matlab is quite explicit here: >> >> >> cos(x0+i*h) >> ans = >> 0.7071 - 0.0000i >> >> >>> I probably not understand your problem ... >>> >>> Antoine >>> Le 12/09/2019 à 10:26, Stéphane Mottelet a écrit : >>>> Hello all, >>>> >>>> The subject has been already discussed a lot but I would like it to >>>> be discussed again because I now have a real rationale to promote a >>>> change in the way complex numbers with small imaginary part are >>>> displayed. >>>> >>>> I don't know if some of you were aware of the clever technique of >>>> complex-step derivative approximation, but until yesterday I was >>>> not (see e.g. >>>> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mdolab.engin.umich.edu/sites/default/files/Martins2003CSD.pdf). >>>> Roughly speaking, using the extension of a real function x->f(x) to >>>> the complex plane allows to compute an approximation of the >>>> derivative f'(x0) at a real x0 without using a substraction, like >>>> in the central difference formula (f(x0+h)-f(x0-h))/2/h which is >>>> subject to substractive cancelation when h is small. In Scilab most >>>> operators and elementary functions are already complex-aware so >>>> this is easy to illustrate the technique. For example let us >>>> approximate the derivative of x->cos(x) at x=%pi/4, first with the >>>> central difference formula, then with the complex step technique: >>>> >>>> --> format("e",24) >>>> >>>> --> h=%eps/128, x0=%pi/4 >>>> h = >>>> >>>> 1.73472347597680709D-18 >>>> >>>> x0 = >>>> >>>> 7.85398163397448279D-01 >>>> >>>> >>>> --> (cos(x0+h)-cos(x0-h))/2/h >>>> ans = >>>> >>>> 0.00000000000000000D+00 >>>> >>>> >>>> --> imag(cos(x0+%i*h))/h >>>> ans = >>>> >>>> -7.07106781186547462D-01 >>>> >>>> >>>> --> -sin(x0) >>>> ans = >>>> >>>> -7.07106781186547462D-01 >>>> >>>> You can see the pathological approximation with central difference >>>> formula and the perfect (up to relative machine precision) >>>> approximation of complex-step formula. >>>> >>>> However, the following is a pity: >>>> >>>> >>>> --> cos(x0+%i*h) >>>> ans = >>>> >>>> 7.07106781186547573D-01 >>>> >>>> We cannot see the imaginary part although seeing the latter is >>>> fundamental in the complex-step technique. We have to force the >>>> display like this, and frankly I don't like having to do that with >>>> my students: >>>> >>>> --> imag(cos(x0+%i*h)) >>>> ans = >>>> >>>> -1.22663473334669916D-18 >>>> >>>> I hope that you will find that this example is a good rationale to >>>> change the default display of Scilab. To feed the discussion, here >>>> is how Matlab displays things, without having to change the default >>>> settings: >>>> >>>> >>>> >> h=eps/128, x0=pi/4 >>>> h = >>>> 1.7347e-18 >>>> x0 = >>>> 0.7854 >>>> >>>> >> (cos(x0+h)-cos(x0-h))/2/h >>>> ans = >>>> 0 >>>> >>>> >> cos(x0+i*h) >>>> ans = >>>> 0.7071 - 0.0000i >>>> >>>> >> imag(cos(x0+i*h))/h >>>> ans = >>>> -0.7071 >>>> >>>> >> -sin(x0) >>>> ans = >>>> -0.7071 >>>> >>>> >>> >>> _______________________________________________ >>> users mailing list >>> [hidden email] >>> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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 _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Samuel GOUGEON |
In reply to this post by mottelet
Hello,
To me, as
already claimed there, it's clear that, for a
complex-encoded number, not displaying its null imaginary part is
a bug, and the proposed patch is clearly welcome as well.
Another regression very close to this
one, but with real numbers display, would deserve the same care :
Scilab 5:
-->[1e30 1e-30]
ans = 1.000D+30 1.000D-30 Scilab 6: --> [1e30 1e-30]
ans = 1.000D+30 0. So, very small numbers are reduced to
strict 0...
This is a bad implementation of the
variable format mode. The Scilab 5 one was correct, at least on
this point.
Best regards Le 12/09/2019 à 10:26, Stéphane
Mottelet a écrit :
Hello all,
_______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Le 13/09/2019 à 12:45, Samuel Gougeon a
écrit :
The patch also fixes this.
-- 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 [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Samuel GOUGEON |
In reply to this post by mottelet
Le 12/09/2019 à 18:55, Stéphane
Mottelet a écrit :
I prefer the display after applying https://codereview.scilab.org/#/c/20981/:
... and IMO it's very suitable. The only rule should be that, for a given format's width, the more the number of significant displayed figures the better. When the exponent format is used, it takes 4 or 5 digits (D+12, D+123). As a consequence, in v mode, small (absolute) values should be displayed in normal mode down to 4 non-significant 0 (e.g. 0.000012), and switched to "e" mode beyond. In v mode, forcing the display of 0.0123456 in "e" mode on the
(bad) reason that some other huge or tiny numbers in the matrix
are displayed in this mode, would print 1.234D-02, and so make
invisible 2 significant figures. Regards Samuel
_______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Le 13/09/2019 à 13:07, Samuel Gougeon a
écrit :
I agree Samuel.
-- 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 [hidden email] http://lists.scilab.org/mailman/listinfo/users |
However, as I already said it elsewhere, some glitches such as
the following one do occur (see the display of whole x) --> x=1:0.1:2 ans = 1.6 --> x(7)-1.6 ans = --> x(8)-1.7 I think that we do agree about the fact that the actual Scilab
display --> x=1:0.1:2 --> x(7) 1.6 --> x(7)-1.6 --> x(8)-1.7 is pretty but not correct/homogeneous/honest. The display that is obtained with the patch (first lines of this email) is correct+honest but not homogeneous. A pretty + mathematically correct display would be:
--> x=1:0.1:2 --> x(7) --> x(8)
ans = i.e. when the matrix to display is not a scalar, add always
trailing zeros for homogeneity, BUT when it is a scalar, add
trailing zeros only when the actual stored value is different from
the displayed value. The first thing that you can see is that the default format(10)
would be very verbose, but this is tunable. A value of 7 would be
ok, but quite low for format("e"). S. Le 13/09/2019 à 13:37, Stéphane
Mottelet a écrit :
-- 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 [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Christophe Dang Ngoc Chan |
Hello,
> De : Stéphane Mottelet > Envoyé : vendredi 13 septembre 2019 14:23 > > I think that we do agree about the fact that the actual Scilab display > [...] > --> x(8) > ans = > > 1.7 > --> x(8)-1.7 > ans = > > 2.220D-16 > is pretty but not correct/homogeneous/honest I don't agree about this. The decimal number can only rarely be represented exactly in binary according to IEEE 754. This means that there should always be trailing zeros to highlight the fact that there is a 10^-16 discrepancy between the stored value and the displayed value? I don't find this convenient. The fact that some people are not aware of this discrepancy can be a problem but it is the general problem of underflow or subtractive cancellation or round-off error etc. The problem is not less important than ignoring a number is complex with a zero imaginary part, but I'm not sure it can be handled in the same way. -- Christophe Dang Ngoc Chan Mechanical calculation engineer General This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Le 13/09/2019 à 15:13, Dang Ngoc Chan, Christophe a écrit : > Hello, > >> De : Stéphane Mottelet >> Envoyé : vendredi 13 septembre 2019 14:23 >> >> I think that we do agree about the fact that the actual Scilab display >> [...] >> --> x(8) >> ans = >> >> 1.7 >> --> x(8)-1.7 >> ans = >> >> 2.220D-16 >> is pretty but not correct/homogeneous/honest Maybe I was not clear enough. 1.7 cannot be stored exactly in IEEE754 encoding so it should always be displayed with trailing zeros. So --> x(8)-1.7 ans = 2.220D-16 is OK and should always be displayed like this, but the previous display --> x(8) ans = 1.7 is not OK. What is not correct/homogeneous/honest is the fact that we have this both displays in the current version of Scilab. > I don't agree about this. > The decimal number can only rarely be represented exactly in binary according to IEEE 754. > > This means that there should always be trailing zeros to highlight the fact that there is a 10^-16 discrepancy between the stored value and the displayed value? > I don't find this convenient. > > The fact that some people are not aware of this discrepancy can be a problem but it is the general problem of underflow or subtractive cancellation or round-off error etc. > > The problem is not less important than ignoring a number is complex with a zero imaginary part, but I'm not sure it can be handled in the same way. > > -- > Christophe Dang Ngoc Chan > Mechanical calculation engineer > > General > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. > _______________________________________________ > users mailing list > [hidden email] > 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 [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Christophe Dang Ngoc Chan |
Hello,
> De : Stéphane Mottelet > Envoyé : vendredi 13 septembre 2019 15:22 > > 1.7 cannot be stored exactly in IEEE754 Yes, but there is an "infinite" amount of decimal numbers that cannot be stored exactly in IEEE754. -- Christophe Dang Ngoc Chan Mechanical calculation engineer General This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Le 13/09/2019 à 15:28, Dang Ngoc Chan, Christophe a écrit : > Hello, > >> De : Stéphane Mottelet >> Envoyé : vendredi 13 septembre 2019 15:22 >> >> 1.7 cannot be stored exactly in IEEE754 > Yes, but there is an "infinite" amount of decimal numbers > that cannot be stored exactly in IEEE754. I know... so what ? Upon reflection I don't think that systematically adding trailing zeros (even when a number is stored exactly) is a good idea. What we could aim at, in order to keep a compact display, is to remove all trailing zeros when displaying non-scalar matrices, and display them when displaying a scalar alone. Even this small step (together with the display of small real real parts, small imaginary parts, zero imaginary parts) would be an improvement for Scilab users. S. > > -- > Christophe Dang Ngoc Chan > Mechanical calculation engineer > > General > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. > _______________________________________________ > users mailing list > [hidden email] > 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 [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Samuel GOUGEON |
In reply to this post by mottelet
Le 13/09/2019 à 14:22, Stéphane
Mottelet a écrit :
I agree with Christophe. This output is OK for me. Aestheticism
must be encouraged provided that it does not truncate or downgrade
the information.
_______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Le 13/09/2019 à 16:52, Samuel Gougeon a
écrit :
bitstring allows to see that only 1, 1.5 and 2 are exactly encoded --> bitstring(1:0.1:2)'
-- 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 [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Samuel GOUGEON |
Le 13/09/2019 à 16:59, Stéphane Mottelet a écrit :
> > > Le 13/09/2019 à 16:52, Samuel Gougeon a écrit : >> Le 13/09/2019 à 14:22, Stéphane Mottelet a écrit : >>> >>> However, as I already said it elsewhere, some glitches such as the >>> following one do occur (see the display of whole x) >>> >>> --> x=1:0.1:2 >>> x = >>> 1. 1.1 1.2 1.3 1.4 1.5 1.6 1.7000000 1.8 1.9 2. >>> >> >> I agree with Christophe. This output is OK for me. Aestheticism must >> be encouraged provided that it does not truncate or downgrade the >> information. >> >> About padding every number: Not OK. This would kill one of the assets >> of the "v" format: its compacity. >> >> About the fact that 1.7 can't be exactly encoded: It is very >> surprising for a so limited decimal number. But OK. I am also quite >> surprised that, in this series, only 1.7 can't be exactly encoded. >> > bitstring allows to see that only 1, 1.5 and 2 are exactly encoded > So, question: Why 1.1 1.2 1.3 1.4 1.6 1.8 and 1.9 are displayed without trailing 0, while 1.7 is? The argument/explanation according to which 1.7 can't be exactly encoded does not tell all... _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Le 13/09/2019 à 17:13, Samuel Gougeon a écrit : > Le 13/09/2019 à 16:59, Stéphane Mottelet a écrit : >> >> >> Le 13/09/2019 à 16:52, Samuel Gougeon a écrit : >>> Le 13/09/2019 à 14:22, Stéphane Mottelet a écrit : >>>> >>>> However, as I already said it elsewhere, some glitches such as the >>>> following one do occur (see the display of whole x) >>>> >>>> --> x=1:0.1:2 >>>> x = >>>> 1. 1.1 1.2 1.3 1.4 1.5 1.6 1.7000000 1.8 1.9 2. >>>> >>> >>> I agree with Christophe. This output is OK for me. Aestheticism must >>> be encouraged provided that it does not truncate or downgrade the >>> information. >>> >>> About padding every number: Not OK. This would kill one of the >>> assets of the "v" format: its compacity. >>> >>> About the fact that 1.7 can't be exactly encoded: It is very >>> surprising for a so limited decimal number. But OK. I am also quite >>> surprised that, in this series, only 1.7 can't be exactly encoded. >>> >> bitstring allows to see that only 1, 1.5 and 2 are exactly encoded >> > > So, question: Why 1.1 1.2 1.3 1.4 1.6 1.8 and 1.9 are displayed > without trailing 0, while 1.7 is? > The argument/explanation according to which 1.7 can't be exactly > encoded does not tell all... By using format(24) in current Scilab version you will have the explanation : --> (1:0.1:2)' ans = 1. 1.100000000000000088818 1.199999999999999955591 1.300000000000000044409 1.399999999999999911182 1.5 1.600000000000000088818 1.700000000000000177636 1.8 1.9 2. You have (1.700000000000000177636-1.7) >= %eps but for the others the difference is lower > > > _______________________________________________ > users mailing list > [hidden email] > 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 [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Free forum by Nabble | Edit this page |