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

[Stéphane Mottelet]

Le 13/09/2019 à 17:32, Samuel Gougeon a écrit :
> Le 13/09/2019 à 17:20, Stéphane Mottelet a écrit :
>>
>> Le 13/09/2019 à 17:13, Samuel Gougeon a écrit :
>>> Le 13/09/2019 à 16:59, Stéphane Mottelet a écrit :
>>>>
>>>>
>>>> Le 13/09/2019 à 16:52, Samuel Gougeon a écrit :
>>>>> Le 13/09/2019 à 14:22, Stéphane Mottelet a écrit :
>>>>>>
>>>>>> However, as I already said it elsewhere, some glitches such as 
>>>>>> the following  one do occur (see the display of whole x)
>>>>>>
>>>>>> --> 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.
>>>>>>
>>>>>
>>>>> I agree with Christophe. This output is OK for me. Aestheticism 
>>>>> must be encouraged provided that it does not truncate or downgrade 
>>>>> the information.
>>>>>
>>>>> About padding every number: Not OK. This would kill one of the 
>>>>> assets of the "v" format: its compacity.
>>>>>
>>>>> About the fact that 1.7 can't be exactly encoded: It is very 
>>>>> surprising for a so limited decimal number. But OK. I am also 
>>>>> quite surprised that, in this series, only 1.7 can't be exactly 
>>>>> encoded.
>>>>>
>>>> bitstring allows to see that only 1, 1.5 and 2 are exactly encoded
>>>>
>>>
>>> So, question: Why 1.1 1.2 1.3 1.4 1.6 1.8 and 1.9 are displayed 
>>> without trailing 0, while 1.7 is?
>>> The argument/explanation according to which 1.7 can't be exactly 
>>> encoded does not tell all...
>>
>> By using format(24) in current Scilab version you will have the 
>> explanation :
>>
>> --> (1:0.1:2)'
>>  ans  =
>>
>>    1.
>>    1.100000000000000088818
>>    1.199999999999999955591
>>    1.300000000000000044409
>>    1.399999999999999911182
>>    1.5
>>    1.600000000000000088818
>>    1.700000000000000177636
>>    1.8
>>    1.9
>>    2.
>>
>> You have (1.700000000000000177636-1.7) >= %eps but for the others the 
>> difference is lower
>
>
> This is an excellent piece of news. This means that the 1.700000000 
> "glitch" is meaningful,
yes
> and the 0-removing algo is OK. Doesn't it?
also yes
>
> The only issue is that (1.700000000000000177636-1.7) should not be >= 
> %eps.
> But this issue is not related to the display.

yeah, we actually got :

--> x=(1:0.1:2); bitstring(x(8)), bitstring(1.7)
  ans  =

  0011111111111011001100110011001100110011001100110011001100110100

  ans  =

  0011111111111011001100110011001100110011001100110011001100110011

the one bit difference  is due to the way implicit vectors are computed.

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