<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<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/help.scilab.org/docs/6.0.2/en_US/brackets.html">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://codereview.scilab.org/#/c/21090/">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>
<p>The proper syntax for this test is <b>isreal(z(1), 0)</b>.
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, while
isreal([1+0*%i, 0]) would still return %F.<br>
To me, this would be a far too specific case, would be still more
puzzling than the current behavior, and in addition would break
isreal()'s consistency. Much worse than today, today's issue
rather being a documentation one, and isreal() and-wise behavior.<br>
</p>
<p>In the way improving isreal() in a not back-compatible way, the
only consistent way that i see is to make isreal(z,tol) working
element-wise. Then, we would have<br>
--> isreal([1+0*%i, 0, %i], 0) // => [%T %T %F] <br>
</p>
This has been somewhat discussed in the<a moz-do-not-send="true"
href="http://bugzilla.scilab.org/show_bug.cgi?id=14452"> bug 14552</a>
report. The way to somewhat bypass this discussion through the
duplicate reported <a moz-do-not-send="true"
href="http://bugzilla.scilab.org/show_bug.cgi?id=16197">bug 14197</a>
does not cancel the first.<br>
<p>Best regards<br>
Samuel<br>
<br>
PS: Thank you Stéphane for having re-posted the initial hijacking
question in this new thread.</p>
</body>
</html>