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

[Samuel Gougeon]

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, 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]
>
Humm, actually, making isreal(z, 0) working element-wise WOULD BE 
back-compatible, since any if/while vectorial condition already applies 
and() on the condition, as presently isreal() applies and() to its 
element-wise primary internal result.

--> if [%T %F] then
   >     disp("OR is applied")
   > end
-->    // (nothing printed)

I am right? So, i do not see any possible issue about this suggestion. 
Do you?

Regards
Samuel

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