<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 13/11/2019 à 12:32, Stéphane

      Mottelet a écrit :<br>

    </div>

    <blockquote type="cite"

      cite="mid:b1796734-ac24-4e9d-686d-262d99662195@utc.fr">

      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

      <p><br>

      </p>

      <div class="moz-cite-prefix">Le 13/11/2019 à 11:58, Samuel Gougeon

        a écrit :<br>

      </div>

      <blockquote type="cite"

        cite="mid:d68cf312-e74f-5819-74d5-383f619d593d@free.fr">

        <meta http-equiv="Content-Type" content="text/html;

          charset=UTF-8">

        <div class="moz-cite-prefix">Dear all,<br>

        </div>

        <div class="moz-cite-prefix"><br>

        </div>

        <div class="moz-cite-prefix">Le 13/11/2019 à 11:16, Stéphane

          Mottelet a écrit :<br>

        </div>

        <blockquote type="cite"

          cite="mid:39e33a27-124f-45df-7b67-8f450522b3f8@utc.fr">Le

          13/11/2019 à 11:09, Dang Ngoc Chan, Christophe a écrit : <br>

          <br>

          <blockquote type="cite">Hello, <br>

            <br>

            <blockquote type="cite">De : De la part de Jean-Philippe

              Grivet <br>

              Envoyé : mercredi 13 novembre 2019 10:50 <br>

              <br>

              --> z = [1,2,3*%i] <br>

                 z  = <br>

                   1.   2.   3.i <br>

              --> isreal(z(1)) <br>

                 ans  = <br>

                  F <br>

              What did I miss ? Rhank you for your help. <br>

            </blockquote>

            <a class="moz-txt-link-freetext"

href="https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/help.scilab.org/docs/6.0.2/en_US/brackets.html"

              moz-do-not-send="true">https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/help.scilab.org/docs/6.0.2/en_US/brackets.html</a>

            <br>

            <br>

            "In some limits, brackets may be applied on a set of data

            having different but compatible types. In this case, some

            data are converted into the dominating type available in the

            set. The main conversion rules are the following: <br>

            [...] <br>

            3. The result becomes complex-encoded as soon as a

            complex-encoded component -- value, polynomial, or rational

            -- is met in the list (even with a null imaginary part)" <br>

          </blockquote>

          <br>

          This non-intuitive behavior will be fixed as soon as the patch

          <br>

          <br>

          <a class="moz-txt-link-freetext"

href="https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/#/c/21090/"

            moz-do-not-send="true">https://codereview.scilab.org/#/c/21090/</a>

          <br>

          <br>

          will be merged ! <br>

        </blockquote>

        <p><br>

        </p>

        <p>I hope no. I would strongy disagree with it.</p>

The proper syntax for this test is isreal(z(1), 0).

          Without its second argument, isreal(z(1)) tests the encoding,

          not the realness. This is already documented.  Still improving

          the isreal() documentation page is planned for Scilab 6.1.0.<br>

          <br>

          To me, the only issue with the current isreal() implementation

          is that when it is used with its second argument, it should

          work element-wise.<br>

          Presently, it is not the case. Thus, isreal(z,0) would answer

          [%T %T %F], while presently it returns the single %F as

          and([%T %T %F]). This is the only point.<br>

          <br>

          Stéphane's proposal would make isreal(1+0*%i) returning %T, </p>

      </blockquote>

      <p>No. Please take time to read the details of the commit. In the

patch decomplexification occurs only at extraction time.

        Of course, the modified help page (still to be pushed) should be

        part of the commit to take into account the new behavior. <br>

      </p>

    </blockquote>

    <p>I did read the duplicate  report and the commit when you pushed

      them.<br>

      But again, their aim is IMO to badly answer to a bad usage but to

      a good question.<br>

      With your current proposal, we would have:</p>

    <p><tt>--> z = complex(1,0);</tt><tt><br>

      </tt><tt>--> isreal(z)    // => %F</tt><tt><br>

      </tt><tt>--> isreal(z(1)) // => %T</tt></p>

    <p>How could this appear not puzzling to us? What an unjustified

      price just to not use the tolerance argument cleverly proposed by

      Scilab, unlike Matlab and Octave.<br>

      By the way, this would differ from the documented Matlab behavior

      (while Octave differs from it).<br>

      As Matlab, Octave does not propose a tolerance as second argument.

      It's their weakness.<br>

      <br>

      I am not sorry to say that, with it, Scilab is more clever than

      both.<br>

      <br>

      Regards<br>

      Samuel</p>

    <br>

  </body>

</html>