Le 17/09/2019 à 15:33, Stéphane Mottelet a écrit :

Le 17/09/2019 à 15:20, Federico Miyara a écrit :

Dear all,

I think that saying that

1.70000000000000018

should be represented as

1.7000000

and that representing it as

1.7

instead is dishonest seems a bit too much for me.

What about

1.71234564999999999?

With the available decimal places you would represent it as

1.7123456

Wouldn't you?

However, there is no clue that the number is inaccurate by the next (8th) decimal digit, whereas 1.7 is inaccurate by the 16th decimal digit. So the clue would be given only if there are any places available after the last non-zero digit. If the trailing zeros serve the purpose of calling attention to the fact that the result is inaccurate then the same opportunity should be given to numbers such as 1.71234564999999999, which is clearly impossible with the available decimal places.

I think no trailing zeros should be added except in rare cases when formatting for a table (outside Scilab), or when, as in experimental physics, the number of exact digits is important, but in such case 1.7000000 would be as dishonest as 1.7, being 1.700000000000000 the only "honest" choice, again, impossible with 7 decimal places. At best, this could be acceptable as a non-default formatting option.

For me, the only change should be to prevent that 1.60000000000000009 be represented as 1.6 while 1.70000000000000018 is represented as 1.7000000.

Let me give the following rationale. When parsing with msscanf we get

--> msscanf("1.60000000000000009","%lf")==1.6
 ans  =

  T

but

--> msscanf("1.70000000000000018","%lf")==1.7
 ans  =

  F

The actual display algorithm does not use msscanf but a cross-platform code (msscanf give different results on Windows and Linux/OSX), but this was just a way to explain why the display of 1.7
I meant x(8) when x=1:0.1:2, i.e. 1.70000000000000018
could (not should) be different.

S.


Regards,

Federico Miyara



On 13/09/2019 10:21, Stéphane Mottelet wrote:

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
users@lists.scilab.org
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




---
El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.avast.com/antivirus

_______________________________________________
users mailing list
users@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

_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Reply via email to