[Scilab-users] {EXT} Re: display of complex/not real numbers, again

[Federico Miyara]

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.

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 at lists.scilab.org
>> https://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://www.avast.com/antivirus