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

[Samuel Gougeon]

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.

Regards
Samuel


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