[Scilab-users] {EXT} strange behaviof of function isreal

[Samuel Gougeon]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20191113/967ed753/attachment.htm>