Le 13/11/2019 à 13:01, Samuel Gougeon a écrit :
Le 13/11/2019 à 12:32, Stéphane Mottelet a écrit :
Le 13/11/2019 à 11:58, Samuel Gougeon a écrit :
Dear all,
Le 13/11/2019 à 11:16, Stéphane Mottelet a écrit :
Le 13/11/2019 à 11:09, Dang Ngoc Chan, Christophe a écrit :
Hello,
De : De la part de Jean-Philippe Grivet
Envoyé : mercredi 13 novembre 2019 10:50
--> z = [1,2,3*%i]
z =
1. 2. 3.i
--> isreal(z(1))
ans =
F
What did I miss ? Rhank you for your help.
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/help.scilab.org/docs/6.0.2/en_US/brackets.html
"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:
[...]
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)"
This non-intuitive behavior will be fixed as soon as the patch
https://codereview.scilab.org/#/c/21090/
will be merged !
I hope no. I would strongy disagree with it.
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.
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.
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.
Stéphane's proposal would make isreal(1+0*%i) returning %T,
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.
I did read the duplicate report and the commit when you pushed them.
But again, their aim is IMO to badly answer to a bad usage but to a
good question.
With your current proposal, we would have:
--> z = complex(1,0);
--> isreal(z) // => %F
--> isreal(z(1)) // => %T
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.
By the way, this would differ from the documented Matlab behavior
(while Octave differs from it).
As Matlab, Octave does not propose a tolerance as second argument.
It's their weakness.
I am not sorry to say that, with it, Scilab is more clever than both.
Nothing puzzling here. "z" denotes the original vector as a well
defined *reference*, while z(1) denotes a temporary value (yielded by an
extraction). This is subtle, but clever, sorry to say that.
Regards
Samuel
_______________________________________________
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
--
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
http://www.utc.fr/~mottelet
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
