<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 à 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/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://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>
<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>
</blockquote>
<p>Humm, actually, making isreal(z, 0) working element-wise WOULD BE
back-compatible, since any if/while vectorial condition already
applies and() on the condition, as presently isreal() applies
and() to its element-wise primary internal result.<br>
</p>
<p> --> if [%T %F] then<br>
> disp("OR is applied")<br>
> end<br>
--> // (nothing printed)</p>
I am right? So, i do not see any possible issue about this
suggestion. Do you?<br>
<p>Regards<br>
Samuel<br>
<br>
</p>
</body>
</html>