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

[Stéphane Mottelet]

Le 13/11/2019 à 13:01, Samuel Gougeon a écrit :
> 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.
>
Nothing puzzling here. "z" denotes the original vector as a  well 
defined *reference*, while z(1) denotes a temporary value (yielded by an 
extraction). This is subtle, but clever, sorry to say that.

>
> Regards
> Samuel
>
>
>
> _______________________________________________
> users mailing list
> users at 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

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