<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<font face="Courier New">Stéphane,<br>
<br>
I'm not sure whether you are proposing to modify </font><font
face="Courier New">types, </font><font face="Courier New">type
names or just how they are presented in the variable browser.<br>
<br>
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.<br>
<br>
I also think types should reflect three things:<br>
<br>
1) The way a variable is stored in memory, including the headers
and the data with the basic format corresponding to each case.<br>
<br>
2) The set of possible values or elements compatible with the
type.<br>
<br>
3) The functions and operators that can be applied to a given type
of data (without overloading) and the way they work.<br>
<br>
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.<br>
<br>
Finally, I don't consider it recommendable that the same word be
used both for a <i>format </i>and a <i>type name</i>, such as
if "constant" were replaced by "double". <br>
<br>
In the case of integers, are all integers the same type? Is int16
the same type as int32?<br>
<br>
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.<br>
<br>
Regards,<br>
<br>
Federico Miyara <br>
</font><br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 10/12/2019 06:47, Stéphane Mottelet
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d59770db-0aab-88fb-3118-c800dac6fb42@utc.fr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>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<br>
</p>
<p>typeof(x)=="constant" && isreal(x)==%t &&
issparse(x)=%f : Real</p>
<p>typeof(x)=="constant" && isreal(x)==%f &&
issparse(x)=%f : Complex</p>
<p>typeof(x)=="constant" && isreal(x)==%t &&
issparse(x)=%t : Real (sparse)<br>
</p>
<p>typeof(x)=="constant" && isreal(x)==%f &&
issparse(x)=%t : Complex (sparse)</p>
<p>typeof(x)=="boolean" && issparse(x)=%f : Boolean</p>
<p>typeof(x)=="boolean" && issparse(x)=%t : Boolean
(sparse)</p>
<p>For integers, since their use is rather specific to more
advanced users, i suggest to display the storage type to
differentiate them<br>
</p>
<p>type(x)==8 && inttype(x)==1 : Integer (int8)</p>
<p>type(x)==8 && inttype(x)==11 : Integer (uint8)</p>
<p>and so on...</p>
<p>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....<br>
</p>
<p>S.<br>
</p>
<p> </p>
<div class="moz-cite-prefix">Le 09/12/2019 à 09:44, Stéphane
Mottelet a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:f09917f5-20fc-6fe1-9902-8adac53cf03c@utc.fr">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Hello all,<br>
</p>
<div class="moz-cite-prefix">Le 06/12/2019 à 23:37, Samuel
Gougeon a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:b2d3c45e-06a0-56ee-74b2-7bd247eb17f1@free.fr">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div class="moz-cite-prefix">Le 06/12/2019 à 23:23, Federico
Miyara a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:9be08b32-cd75-dcd7-2105-038d84fc798a@fceia.unr.edu.ar">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<font face="Courier New"><br>
.../...</font><font face="Courier New"><br>
By the way, if constant were changed to double (or to
number or num.ber --I don't get the dot...</font></blockquote>
<p>As in 3.14, contrarily to 123<br>
</p>
</blockquote>
<p><br>
</p>
<p>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. </p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:b2d3c45e-06a0-56ee-74b2-7bd247eb17f1@free.fr">
<p> </p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:9be08b32-cd75-dcd7-2105-038d84fc798a@fceia.unr.edu.ar"><font
face="Courier New">--), then as this might cause some
backward compatibility, consider taking the oportunity
also to replace "ce" by "cell", and "st" by "struct", </font></blockquote>
<p>Definitely, or even with their possible translation in
locales, as for other main native types.</p>
<p><br>
</p>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:users@lists.scilab.org" moz-do-not-send="true">users@lists.scilab.org</a>
<a class="moz-txt-link-freetext" href="https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users" moz-do-not-send="true">https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
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
<a class="moz-txt-link-freetext" href="https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.utc.fr/~mottelet" moz-do-not-send="true">http://www.utc.fr/~mottelet</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:users@lists.scilab.org" moz-do-not-send="true">users@lists.scilab.org</a>
<a class="moz-txt-link-freetext" href="https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users" moz-do-not-send="true">https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
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
<a class="moz-txt-link-freetext" href="http://www.utc.fr/~mottelet" moz-do-not-send="true">http://www.utc.fr/~mottelet</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:users@lists.scilab.org">users@lists.scilab.org</a>
<a class="moz-txt-link-freetext" href="http://lists.scilab.org/mailman/listinfo/users">http://lists.scilab.org/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
</body>
</html>