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, while
isreal([1+0*%i, 0]) would still return %F.
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.
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
--> isreal([1+0*%i, 0, %i], 0) // => [%T %T %F]
This has been somewhat discussed in thebug 14552
<http://bugzilla.scilab.org/show_bug.cgi?id=14452> report. The way to
somewhat bypass this discussion through the duplicate reported bug 14197
<http://bugzilla.scilab.org/show_bug.cgi?id=16197> does not cancel the
first.
Best regards
Samuel
PS: Thank you Stéphane for having re-posted the initial hijacking
question in this new thread.
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users