[Scilab-users] Confusion about types (typeof vs. Variabe Browser)

[Federico Miyara]

Stéphane,

I'm not sure whether you are proposing to modify types, type names or 
just how they are presented in the variable browser.

I think, from the user's perspective, that the type names appearing in 
the variable browser (in the Type column) should be strictly the same as 
reported by the function typeof. Otherwise it can and will cause 
confusion and the sensation of lack of consistency.

I also think types should reflect three things:

1) The way a variable is stored in memory, including the headers and the 
data with the basic format corresponding to each case.

2) The set of possible values or elements compatible with the type.

3) The functions and operators that can be applied to a given type of 
data (without overloading) and the way they work.

According to this, a complex number would have definitely a different 
type from a real number since the way it is stored is different. By the 
way, calling non-complex numbers type "real" wouldn't be completely 
accurate, since they are really a subset of rationals with a 
power-of-ttwo denominator; however it would be acceptable because they 
are meant to approximate real numbers.

Finally, I don't consider it recommendable that the same word be used 
both for a /format /and a /type name/, such as if "constant" were 
replaced by "double".

In the case of integers, are all integers the same type?  Is int16 the 
same type as int32?

I tend to think the answer is no, since they have very different storage 
representations, cover different sets of numbers and even operations 
behave differently. If so, the type should be called integer8, integer16 
and so on (so the type would be integer8 and the basic format would be 
int16 --no ambiguity). If, on the contrary, they are the same, then the 
only type name should be "integer" and the basic format should be 
informed in a different column.

Regards,

Federico Miyara





On 10/12/2019 06:47, Stéphane Mottelet wrote:
>
> After thinking about it and after looking to other softwares, my 
> proposition would be to concentrate on the set theoritic name + use 
> parenthesis for details of storage
>
> typeof(x)=="constant" && isreal(x)==%t && issparse(x)=%f : Real
>
> typeof(x)=="constant" && isreal(x)==%f && issparse(x)=%f : Complex
>
> typeof(x)=="constant" && isreal(x)==%t && issparse(x)=%t : Real (sparse)
>
> typeof(x)=="constant" && isreal(x)==%f && issparse(x)=%t : Complex 
> (sparse)
>
> typeof(x)=="boolean" && issparse(x)=%f : Boolean
>
> typeof(x)=="boolean" && issparse(x)=%t : Boolean (sparse)
>
> For integers, since their use is rather specific to more advanced 
> users, i suggest to display the storage type to differentiate them
>
> type(x)==8 && inttype(x)==1 : Integer (int8)
>
> type(x)==8 && inttype(x)==11 : Integer (uint8)
>
> and so on...
>
> However, I don't understand why we should consider Scilab users as 
> less aware (or less concerned by) of the reality of storage types. 
> When you consider the big audience of Matlab and see that developpers 
> didn't waste time like we do here. They just use "double", litteral 
> integer types (int8,...). Moreover they didn't even have to make 
> translations....
>
> S.
>
> Le 09/12/2019 à 09:44, Stéphane Mottelet a écrit :
>>
>> Hello all,
>>
>> Le 06/12/2019 à 23:37, Samuel Gougeon a écrit :
>>> Le 06/12/2019 à 23:23, Federico Miyara a écrit :
>>>>
>>>> .../...
>>>> By the way, if constant were changed to double (or to number or 
>>>> num.ber --I don't get the dot...
>>>
>>> As in 3.14, contrarily to 123
>>>
>>
>> If "double" is not to be used for reasons that I still don't 
>> understand, why don't we use "Real" instead of "Number" for x such 
>> that typeof(x)==constant and isreal(x)==%t ? This would be consistent 
>> with "complex" when typeof(x)==constant and isreal(x)==f. Moreover, 
>> this would be even set-theory compliant, i.e. use the name of the 
>> smallest set corresponding to storage type.
>>
>>
>>>
>>>> --), then as this might cause some backward compatibility, consider 
>>>> taking the oportunity also to replace "ce" by "cell", and "st" by 
>>>> "struct", 
>>>
>>> Definitely, or even with their possible translation in locales, as 
>>> for other main native types.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20191211/d62f3ab3/attachment.htm>