Re: {EXT} strange behaviof of function isreal

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]

Best regards
Samuel

PS: Thank you Stéphane for having re-posted the initial hijacking question in this new thread.

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

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 the bug 14552 report. The way to somewhat bypass this discussion through the duplicate reported  bug 14197 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
[hidden email]
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

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)

Regards
Samuel

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

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
[hidden email]
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