<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 à 13:01, Samuel Gougeon a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:9778098b-ca59-0b15-5012-370f8dc01e6e@free.fr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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/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/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>
</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>
</p>
</blockquote>
<p>Nothing puzzling here. "z" denotes the original vector as a well
defined <b>reference</b>, while z(1) denotes a temporary value
(yielded by an extraction). This is subtle, but clever, sorry to
say that.<br>
</p>
<blockquote type="cite"
cite="mid:9778098b-ca59-0b15-5012-370f8dc01e6e@free.fr">
<p> <br>
Regards<br>
Samuel</p>
<br>
<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>