Stéphane,

--> 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.


However I get this:

  > 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.

But it is true that x(7) - 1.7 yields 2.220D-16. Here there are two problems, an arithmetic one and a display one. Formatting to a sufficiently large number of digits the arithmetic problem (or limitation, probably unsurmountable, originated in the incompatibility of binary and decimal systems) is evident:

  > format(20)

  > x=1:0.1:2
 x  =

         column 1 to 6

   1.   1.10000000000000009   1.19999999999999996 1.30000000000000004   1.39999999999999991   1.5

         column 7 to 11

   1.60000000000000009   1.70000000000000018   1.8 1.89999999999999991   2.


Why this triggers showing several zeros I don't understand, probably a bug, but it can be seen that it happens when the numeric error affects te 16th decimal digit.

Regards,

Federico Miyara






--> 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
users@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@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@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
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Reply via email to