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

[Stéphane Mottelet]

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 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/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/www.avast.com/antivirus 
>
>
> _______________________________________________
> users mailing list
> users at 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