<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <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>
  </body>
</html>