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

[Stéphane Mottelet]

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