[Scilab-users] display of complex/not real numbers, again
Stéphane Mottelet
stephane.mottelet at utc.fr
Fri Sep 13 17:57:23 CEST 2019
Le 13/09/2019 à 17:38, Stéphane Mottelet a écrit :
>
> 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.
sorry it is more than one bit, the last 3 bits differ
>
>>
>>
>> _______________________________________________
>> 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
More information about the users
mailing list