# [Scilab-users] display of complex/not real numbers, again

35 messages
12
Open this post in threaded view
|

## [Scilab-users] display of complex/not real numbers, again

 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
Open this post in threaded view
|

## Re: display of complex/not real numbers, again

 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
Open this post in threaded view
|

## Re: display of complex/not real numbers, again

 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
Open this post in threaded view
|

## Re: {EXT} display of complex/not real numbers, again

 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
Open this post in threaded view
|

## Re: {EXT} display of complex/not real numbers, again

 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
Open this post in threaded view
|

## Re: display of complex/not real numbers, again

Open this post in threaded view
|

## Re: display of complex/not real numbers, again

Open this post in threaded view
|

## Re: display of complex/not real numbers, again

 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 Samuel 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
Open this post in threaded view
|

## Re: display of complex/not real numbers, again

 Le 13/09/2019 à 12:45, Samuel Gougeon a écrit : 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. The patch also fixes this. 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 Samuel 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] 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
Open this post in threaded view
|

## Re: display of complex/not real numbers, again

 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/: --> 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... ... 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. I do not see any reason that would impose the display mode to be homogeneous over all elements of a matrix, possibly canceling the display of significant figures in the given format's width. Regards Samuel _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: display of complex/not real numbers, again

 Le 13/09/2019 à 13:07, Samuel Gougeon a écrit : Le 12/09/2019 à 18:55, Stéphane Mottelet a écrit : 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... ... 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. I do not see any reason that would impose the display mode to be homogeneous over all elements of a matrix, possibly canceling the display of significant figures in the given format's width. I agree Samuel. Regards Samuel ```_______________________________________________ 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
Open this post in threaded view
|

## Re: display of complex/not real numbers, again

 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. --> x(7)  ans  =    1.6 --> x(7)-1.6  ans  =    0. --> x(8)  ans  =    1.7000000 --> x(8)-1.7  ans  =    2.220D-16 I think that we do agree about the fact that the actual Scilab display --> x=1:0.1:2  x  =    1.   1.1   1.2   1.3   1.4   1.5   1.6   1.7  1.8   1.9   2. --> x(7)  ans  =    1.6 --> x(7)-1.6  ans  =    0. --> x(8)  ans  =    1.7 --> x(8)-1.7  ans  =    2.220D-16 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  =    1.0000000   1.1000000   1.2000000   1.3000000   1.4000000   1.0000005   1.6000000   1.7000000   1.8000000   1.9000000   2.0000000 --> x(7)  ans  =    1.6 --> x(8)  ans  =    1.7000000 --> x(8)-1.7  ans  =    2.220D-16 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 : Le 13/09/2019 à 13:07, Samuel Gougeon a écrit : Le 12/09/2019 à 18:55, Stéphane Mottelet a écrit : 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... ... 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. I do not see any reason that would impose the display mode to be homogeneous over all elements of a matrix, possibly canceling the display of significant figures in the given format's width. I agree Samuel. Regards Samuel ```_______________________________________________ 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] 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
Open this post in threaded view
|

## Re: {EXT} Re: display of complex/not real numbers, again

 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
Open this post in threaded view
|

## Re: {EXT} Re: display of complex/not real numbers, again

 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
Open this post in threaded view
|

## Re: {EXT} Re: display of complex/not real numbers, again

 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
Open this post in threaded view
|

## Re: {EXT} Re: display of complex/not real numbers, again

 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
Open this post in threaded view
|

## Re: display of complex/not real numbers, again

Open this post in threaded view
|

## Re: display of complex/not real numbers, again

 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 --> bitstring(1:0.1:2)'  ans  = !0011111111110000000000000000000000000000000000000000000000000000  ! !                                                                  ! !0011111111110001100110011001100110011001100110011001100110011010  ! !                                                                  ! !0011111111110011001100110011001100110011001100110011001100110011  ! !                                                                  ! !0011111111110100110011001100110011001100110011001100110011001101  ! !                                                                  ! !0011111111110110011001100110011001100110011001100110011001100110  ! !                                                                  ! !0011111111111000000000000000000000000000000000000000000000000000  ! !                                                                  ! !0011111111111001100110011001100110011001100110011001100110011010  ! !                                                                  ! !0011111111111011001100110011001100110011001100110011001100110100  ! !                                                                  ! !0011111111111100110011001100110011001100110011001100110011001101  ! !                                                                  ! !0011111111111110011001100110011001100110011001100110011001100110  ! !                                                                  ! !0100000000000000000000000000000000000000000000000000000000000000  ! So, the discussion holds on the criterion according to which trailing zeros must be displayed or not. I am wondering about the following, clearly without definitive opinion. Just a thought: After format(10), 1.7000000 is displayed if the NEXT figure is not 0, and 1.7 is displayed otherwise. In other words, this would no longer refer to %eps but to the format's length. The issue with this proposal is that we don't have the current format in mind. If all numbers are displayed in a compact form, we don't see the display accuracy.. The choice to refer either to %eps or to format() could be proposed through the preferences. Instead, the discussion could also be about the IEEE rounding mode. In some occasion, the IEEE rounding mode below %eps has visible effects on results (there is something about this in Bugzilla on mailing lists...). Now, i guess that testing with a hardcoded equivalent of nearfloat() would be too time-consuming. ```_______________________________________________ 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
Open this post in threaded view
|

## Re: display of complex/not real numbers, again

 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