<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Courier New"><br>
Samuel,<br>
<br>
Thanks for your lengthy insight. I'll just take up the challenge
at the end:<br>
</font><br>
<font face="Courier New">
<blockquote type="cite"><font face="Courier New">I do not see
reasons to make GUIs labels exactly matching the technical
typeofs.<br>
But, please convince us.</font></blockquote>
<br>
I think the interface should be as transparent and informative as
possible. It should confirm facts, not obscure them. <br>
<br>
It should never create a cognitive dissonance in the user. If I
have learned that a type is called "constant", which is confirmed
by the outcome of applying typeof, I'll find it strange, to say
the least, to see that the type appears as "double" in the
variable Browser. At a minimum, I'll lose time trying to find out
what's going on; I'll probably ask on this list, causing others,
probably yourself, to lose their time answering, and so on.<br>
<br>
Finally, there can be certainly no objection to use consistently a
unique term for a single concept across the program. The only
problem is that someone would have to change the string (or text
:)) in the apropriate code, but it wouldn't be much of a burden
and, as you said, there would be no backward compatibility
problems. <br>
<br>
By the way, if constant were changed to double (or to number or
num.ber --I don't get the dot...--), then as this might cause some
backward compatibility, consider taking the oportunity also to
replace "ce" by "cell", and "st" by "struct", which are the
offical type names, <br>
<br>
Regards,<br>
<br>
Federico Miyara<br>
<br>
<br>
</font><br>
<br>
<div class="moz-cite-prefix">On 05/12/2019 19:23, Samuel Gougeon
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4ace8522-8ce8-3ab7-85dd-4e5c719b73f9@free.fr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Le 29/11/2019 à 06:57, Federico
Miyara a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<br>
<font face="Courier New">Dear all,<br>
<br>
I'm trying to elucidate some details regarding types. The most
basic type, corresponding to real or complex decimal numbers
(or vectors, matrices and hypermatrices with this kind of
components) is called "constant" by the function typeof (and
so listed in the documentation). <br>
<br>
However, the variable browser lists them as "double".<br>
</font></blockquote>
<p><br>
</p>
<p>Both are sucking legacy (i hope there is no copyright on this
expression). But if we should sort awful things, a variable of
"constant" is clearly the worst, in my not humble opinion.</p>
<p>"double" is awful as well because personally, as a user in
2019, i strictly don't care about that, 40 years ago, there was
a dominating "single precision" encoding, and then came the
"double precision" encoding, and everybody was really happy, you
know. Still today, we should remember this great event. OK, OK,
OK. We are still very happy, indeed.<br>
In Scilab, there is no single precision encoding. May be we
should propose implementing it, to look like our so loved
eternal and discrete and exclusive inspirator.<br>
<br>
For any normal newby, before being twisted-minded by historical
and external habits, a "double" is a number, or even better, for
interfaces where short and explicit keywords are welcome, a
num.ber</p>
<p>And for the same fresh user, what does a string mean? A rope, a
chain.<br>
Now, when comprehensive normal -- so very creative -- persons
ask why we don't name a byte a string of bits, you know which
answer they receive? None. Very strange world, isn't it? Very.<br>
Yet, "Text" is a word even shorter than "String". It tells
exactly what this stuff is actually.<br>
In Scilab, a text is NOT a characters string: the basic block is
the text, not the character. And part() helps.<br>
But anyway, which user really cares about how texts are encoded?
Is it really the matter?<br>
<br>
</p>
<blockquote type="cite"
cite="mid:1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar"><font
face="Courier New"> <br>
This is somewhat confusing. </font></blockquote>
<p><br>
</p>
<p>Oo yes. Sometimes we pay to get confused. With Scilab, it's
free. Get, try, and love it. Or report.<br>
<br>
</p>
<blockquote type="cite"
cite="mid:1dd34215-f9b7-e0da-8aa3-0ffd53f46ab2@fceia.unr.edu.ar"><font
face="Courier New">It seems that "double" refers to the way
each individual component is encoded while constant may refer
to the fact that any array containing doubles is o type
constant. <br>
<br>
In the case of integers, for instance we have int64 as
reported by typeof, but in the Variable Browser it is listed a
bit more in full as "Integer 64". While this is also slightly
inconsistent, it is not to complain very much about.<br>
<br>
In the case of rationals, typeof returns "rational" while the
Variable Browser callsit "r (Tlist)"<br>
<br>
Cell array type is called "ce" by typeof but "Cell" in the
Variabe Browser<br>
<br>
User-defined types in tlists and mlists are designed by the
user-defined type name by typeof, while the variable browser
adds "(Tlist)" or "(Mlist)"<br>
<br>
Functions, libraries and impliit lists such as $ are not
listed in the variable bowser but are correctly reported by
typeof<br>
</font></blockquote>
<p><br>
</p>
<p>We can add them in the list, through the <i>Filter</i> menu.<br>
</p>
<p>Anyway, beside the "constant" typeof, i personally do not care
too much about technical typeof names.<br>
Obviously, it is always highly preferable to choose carefully
reserved keywords when creating them.<br>
Some typeof improvements have been done for Scilab 6. And indeed
we could wonder why this "constant" typeof has not been changed.<br>
Too frequently used in existing codes? Probably.</p>
<p>But the situation in GUIs is quite different.
Back-compatibility issues are somewhat less acute than in the
code.<br>
In the variables browser and editor,</p>
<ul>
<li>an array of decimal real numbers could be tagged "num.ber"</li>
<li>an array of complex numbers : "complex", despite it is the
same "constant" typeof. It's not the topic.<br>
</li>
<li>a sparse array of complex numbers : "sparse complex"</li>
<li>an array of characters string : "text"</li>
<li>an array of int64 integers : "int64". It is definitely
clear, and shorter than "Integer 64" or "64 bits integers",
that tell nothing more or better than "int64"<br>
</li>
<li>an array of rationals: "rational", indeed.</li>
<li>etc</li>
</ul>
<p>I do not see reasons to make GUIs labels exactly matching the
technical typeofs.<br>
But, please convince us.<br>
</p>
<p>Cheers<br>
Samuel<br>
<br>
</p>
<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>