Rolf Turner
2017-May-20 10:45 UTC
[R] [FORGED] Re: [FORGED] Logical Operators' inconsistent Behavior
On 20/05/17 22:42, Duncan Murdoch wrote:> On 20/05/2017 6:39 AM, Rolf Turner wrote: >> On 20/05/17 22:18, Duncan Murdoch wrote: >>> On 20/05/2017 5:53 AM, Martin Maechler wrote: >>>>>>>>> Ramnik Bansal <ramnik.bansal at gmail.com> >>>>>>>>> on Sat, 20 May 2017 08:52:55 +0530 writes: >>>> >>>> > Taking this question further. >>>> > If I use a complex number or a numeric as an operand in logical >>>> > operations, to me it APPEARS that these two types are first >>>> coerced to >>>> > LOGICAL internally and then THIS logical output is further used >>>> as the >>>> > operand. >>>> >>>> > For eg. >>>> >> x <- 4+5i; c(x & F, x & T, x | F, x | T) >>>> > [1] FALSE TRUE TRUE TRUE >>>> >>>> > This output is consistent with >>>> >> x <- 4+5i; c(as.logical(x) & F, as.logical(x) & T, >>>> as.logical(x) | F, as.logical(x) | T) >>>> > [1] FALSE TRUE TRUE TRUE >>>> >>>> > This consistency makes me draw an on-the-surface conclusion >>>> that in >>>> > the case of logical operations if the operand is not of type >>>> 'logical' >>>> > it is first coerced into 'logical'. >>>> >>>> That conclusion is wrong as you show below. >>>> Rather, as the error message says, >>>> logical >>>> "operations are possible only for numeric, logical or complex >>>> types" >>>> >>>> Again: >>>> >>>> 1) Logical/Arithmetic operations "work" with "numeric-like" types, >>>> namely >>>> numeric, logical or complex, (and numeric = {integer, double}) >>>> >>>> ==> all other types give an error (the one you've cited twice) >>>> >>>> 2) For "numeric-like" types and *logical* operations (&, |, !; plus && >>>> and ||) >>>> the equivalent of as.logical() is applied before performing the Op. >>>> >>>> Seems pretty consistent ... >>>> and also according to the principle of "least surprise" (for me at >>>> least). >>>> >>> >>> The surprise is that as.logical("TRUE") returns TRUE, whereas automatic >>> coercion doesn't apply to character strings. I don't think we should >>> change this, but it is an inconsistency. (We could perhaps mention it >>> in the ?logical help page.) >> >> >> Actually it *is* mentioned. From ?logical: >> >>> Character strings c("T", "TRUE", "True", "true") are regarded as >>> true, c("F", "FALSE", "False", "false") as false, and all others as NA. >> > > I meant that the negative part should be mentioned: this only works > with an explicit as.logical(), not with implicit coercion.Ah, I see. I missed the point. cheers, Rolf -- Technical Editor ANZJS Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276
Ramnik Bansal
2017-May-21 02:03 UTC
[R] [FORGED] Re: [FORGED] Logical Operators' inconsistent Behavior
In the case of logical operations performed with an operand being a character type, the error is: "operations are possible only for numeric, logical or complex types" Now the display of this error message seems to be the OUTCOME of the fact that implicit coercion is NOT BEING APPLIED INTERNALLY to character operands in the case of logical operations but is applied to all other "numeric" type operands. This error message is NOT the CAUSE. Well, why not: F & "abc" return a FALSE because if F & NA can return FALSE, the logic being that once an operand is FALSE in case of AND operation then the output should be False, IRRESPECTIVE of the second operand. In that case how does it matter if the second operand is "abc" or 4+5i or NA? The output is deterministically FALSE anyways. Effectively the point that I want to make is: Treat the character operand as NA ( except "F", "FALSE", "T", "TRUE" etc which can be treated as FALSE/TRUE) and then apply the logical operations. Or in short "Apply implicit coercion on character types as well in case of logical operations." On Sat, May 20, 2017 at 4:15 PM, Rolf Turner <r.turner at auckland.ac.nz> wrote:> On 20/05/17 22:42, Duncan Murdoch wrote: >> >> On 20/05/2017 6:39 AM, Rolf Turner wrote: >>> >>> On 20/05/17 22:18, Duncan Murdoch wrote: >>>> >>>> On 20/05/2017 5:53 AM, Martin Maechler wrote: >>>>>>>>>> >>>>>>>>>> Ramnik Bansal <ramnik.bansal at gmail.com> >>>>>>>>>> on Sat, 20 May 2017 08:52:55 +0530 writes: >>>>> >>>>> >>>>> > Taking this question further. >>>>> > If I use a complex number or a numeric as an operand in logical >>>>> > operations, to me it APPEARS that these two types are first >>>>> coerced to >>>>> > LOGICAL internally and then THIS logical output is further used >>>>> as the >>>>> > operand. >>>>> >>>>> > For eg. >>>>> >> x <- 4+5i; c(x & F, x & T, x | F, x | T) >>>>> > [1] FALSE TRUE TRUE TRUE >>>>> >>>>> > This output is consistent with >>>>> >> x <- 4+5i; c(as.logical(x) & F, as.logical(x) & T, >>>>> as.logical(x) | F, as.logical(x) | T) >>>>> > [1] FALSE TRUE TRUE TRUE >>>>> >>>>> > This consistency makes me draw an on-the-surface conclusion >>>>> that in >>>>> > the case of logical operations if the operand is not of type >>>>> 'logical' >>>>> > it is first coerced into 'logical'. >>>>> >>>>> That conclusion is wrong as you show below. >>>>> Rather, as the error message says, >>>>> logical >>>>> "operations are possible only for numeric, logical or complex >>>>> types" >>>>> >>>>> Again: >>>>> >>>>> 1) Logical/Arithmetic operations "work" with "numeric-like" types, >>>>> namely >>>>> numeric, logical or complex, (and numeric = {integer, double}) >>>>> >>>>> ==> all other types give an error (the one you've cited twice) >>>>> >>>>> 2) For "numeric-like" types and *logical* operations (&, |, !; plus && >>>>> and ||) >>>>> the equivalent of as.logical() is applied before performing the Op. >>>>> >>>>> Seems pretty consistent ... >>>>> and also according to the principle of "least surprise" (for me at >>>>> least). >>>>> >>>> >>>> The surprise is that as.logical("TRUE") returns TRUE, whereas automatic >>>> coercion doesn't apply to character strings. I don't think we should >>>> change this, but it is an inconsistency. (We could perhaps mention it >>>> in the ?logical help page.) >>> >>> >>> >>> Actually it *is* mentioned. From ?logical: >>> >>>> Character strings c("T", "TRUE", "True", "true") are regarded as >>>> true, c("F", "FALSE", "False", "false") as false, and all others as NA. >>> >>> >> >> I meant that the negative part should be mentioned: this only works >> with an explicit as.logical(), not with implicit coercion. > > > Ah, I see. I missed the point. > > > cheers, > > Rolf > > -- > Technical Editor ANZJS > Department of Statistics > University of Auckland > Phone: +64-9-373-7599 ext. 88276
Duncan Murdoch
2017-May-21 12:56 UTC
[R] [FORGED] Re: [FORGED] Logical Operators' inconsistent Behavior
On 20/05/2017 10:03 PM, Ramnik Bansal wrote:> In the case of logical operations performed with an operand being a > character type, the error is: > "operations are possible only for numeric, logical or complex types" > > Now the display of this error message seems to be the OUTCOME of the > fact that implicit coercion is NOT BEING APPLIED INTERNALLY to > character operands in the case of logical operations but is applied to > all other "numeric" type operands. This error message is NOT the > CAUSE. > > Well, why not: > > F & "abc" return a FALSE because if F & NA can return FALSE, the > logic being that once an operand is FALSE in case of AND operation > then the output should be False, IRRESPECTIVE of the second operand. > In that case how does it matter if the second operand is "abc" or > 4+5i or NA? The output is deterministically FALSE anyways. > > Effectively the point that I want to make is: Treat the character > operand as NA ( except "F", "FALSE", "T", "TRUE" etc which can be > treated as FALSE/TRUE) and then apply the logical operations. Or in > short "Apply implicit coercion on character types as well in case of > logical operations."For consistency with that point of view, we'd also want 1 + "1" to equal 2, as it does in some languages. And maybe "1" + "1" should equal 2. R doesn't do things like that. It tries for consistency in the primitive operations: you don't get auto-conversion of strings to logical/numeric values. This forces some inconsistencies between the primitive operations and explicit coercions like as.logical(), but we think that's a good thing. Duncan Murdoch> > > > > On Sat, May 20, 2017 at 4:15 PM, Rolf Turner <r.turner at auckland.ac.nz> wrote: >> On 20/05/17 22:42, Duncan Murdoch wrote: >>> >>> On 20/05/2017 6:39 AM, Rolf Turner wrote: >>>> >>>> On 20/05/17 22:18, Duncan Murdoch wrote: >>>>> >>>>> On 20/05/2017 5:53 AM, Martin Maechler wrote: >>>>>>>>>>> >>>>>>>>>>> Ramnik Bansal <ramnik.bansal at gmail.com> >>>>>>>>>>> on Sat, 20 May 2017 08:52:55 +0530 writes: >>>>>> >>>>>> >>>>>> > Taking this question further. >>>>>> > If I use a complex number or a numeric as an operand in logical >>>>>> > operations, to me it APPEARS that these two types are first >>>>>> coerced to >>>>>> > LOGICAL internally and then THIS logical output is further used >>>>>> as the >>>>>> > operand. >>>>>> >>>>>> > For eg. >>>>>> >> x <- 4+5i; c(x & F, x & T, x | F, x | T) >>>>>> > [1] FALSE TRUE TRUE TRUE >>>>>> >>>>>> > This output is consistent with >>>>>> >> x <- 4+5i; c(as.logical(x) & F, as.logical(x) & T, >>>>>> as.logical(x) | F, as.logical(x) | T) >>>>>> > [1] FALSE TRUE TRUE TRUE >>>>>> >>>>>> > This consistency makes me draw an on-the-surface conclusion >>>>>> that in >>>>>> > the case of logical operations if the operand is not of type >>>>>> 'logical' >>>>>> > it is first coerced into 'logical'. >>>>>> >>>>>> That conclusion is wrong as you show below. >>>>>> Rather, as the error message says, >>>>>> logical >>>>>> "operations are possible only for numeric, logical or complex >>>>>> types" >>>>>> >>>>>> Again: >>>>>> >>>>>> 1) Logical/Arithmetic operations "work" with "numeric-like" types, >>>>>> namely >>>>>> numeric, logical or complex, (and numeric = {integer, double}) >>>>>> >>>>>> ==> all other types give an error (the one you've cited twice) >>>>>> >>>>>> 2) For "numeric-like" types and *logical* operations (&, |, !; plus && >>>>>> and ||) >>>>>> the equivalent of as.logical() is applied before performing the Op. >>>>>> >>>>>> Seems pretty consistent ... >>>>>> and also according to the principle of "least surprise" (for me at >>>>>> least). >>>>>> >>>>> >>>>> The surprise is that as.logical("TRUE") returns TRUE, whereas automatic >>>>> coercion doesn't apply to character strings. I don't think we should >>>>> change this, but it is an inconsistency. (We could perhaps mention it >>>>> in the ?logical help page.) >>>> >>>> >>>> >>>> Actually it *is* mentioned. From ?logical: >>>> >>>>> Character strings c("T", "TRUE", "True", "true") are regarded as >>>>> true, c("F", "FALSE", "False", "false") as false, and all others as NA. >>>> >>>> >>> >>> I meant that the negative part should be mentioned: this only works >>> with an explicit as.logical(), not with implicit coercion. >> >> >> Ah, I see. I missed the point. >> >> >> cheers, >> >> Rolf >> >> -- >> Technical Editor ANZJS >> Department of Statistics >> University of Auckland >> Phone: +64-9-373-7599 ext. 88276