[Scilab-users] display of complex/not real numbers, again

[Federico Miyara]

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 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
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> users mailing list
> users at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20190917/ea951228/attachment.htm>