Hello Frederico
Le 11/12/2019 à 15:25, Federico Miyara a écrit :
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.
As far as my previous message is concerned, I was just making a proposal
for names 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.
So do I. But other users do not agree with that, that's why I am trying
to find a sensible compromise...
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".
What do you mean by "format" ?
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.
That was my attempt, by using parenthesis.
S.
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
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
