<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<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>
<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, </p>
</blockquote>
<p>No. Please take time to read the details of the commit. In the
patch decomplexification occurs only <b>at extraction time</b>.
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>
<p>I am sorry to say that, but Scilab should not provide basic
functions with the same name as Matlab ones but different behavior
for the same input, and impose a different API <br>
</p>
<blockquote type="cite"
cite="mid:d68cf312-e74f-5819-74d5-383f619d593d@free.fr">
<p>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 </p>
</blockquote>
This would be even worse, see my rematk above<br>
<blockquote type="cite"
cite="mid:d68cf312-e74f-5819-74d5-383f619d593d@free.fr">
<p>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="https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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="https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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>
<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="https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users">https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
<a class="moz-txt-link-freetext" href="http://www.utc.fr/~mottelet">http://www.utc.fr/~mottelet</a>
</pre>
</body>
</html>