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

[Stéphane Mottelet]

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 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/168d6e1a/attachment.htm>