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@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@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@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users