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 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
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
This would be even worse, see my rematk above
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
<https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=14452>
report. The way to somewhat bypass this discussion through the
duplicate reported bug 14197
<https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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
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
