A bug understanding F relative to FALSE?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

A bug understanding F relative to FALSE?

IAGO GINÉ VÁZQUEZ
Hi all,

Is the next behaviour suitable?

identical(F,FALSE)

## [1] TRUE

utils::getParseData(parse(text = "c(F,FALSE)", keep.so=rce = TRUE))

##    line1 col1 line2 col2 id parent                token terminal  text
## 14     1    1     1   10 14      0                 expr    FALSE
## 1      1    1     1    1  1      3 SYMBOL_FUNCTION_CALL     TRUE     c
## 3      1    1     1    1  3     14                 expr    FALSE
## 2      1    2     1    2  2     14                  '('     TRUE     (
## 4      1    3     1    3  4      6               SYMBOL     TRUE     F
## 6      1    3     1    3  6     14                 expr    FALSE
## 5      1    4     1    4  5     14                  ','     TRUE     ,
## 9      1    5     1    9  9     10            NUM_CONST     TRUE FALSE
## 10     1    5     1    9 10     14                 expr    FALSE
## 11     1   10     1   10 11     14                  ')'     TRUE     )

I would expect that token for F is the same as token for FALSE.


Thank you!

Iago


        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: A bug understanding F relative to FALSE?

John Mount
From help(F): TRUE and FALSE are reserved <http://127.0.0.1:39090/help/library/base/help/reserved> words denoting logical constants in the Rlanguage, whereas T and F are global variables whose initial values set to these.

> On Jan 15, 2020, at 6:13 AM, IAGO GINÉ VÁZQUEZ <[hidden email]> wrote:
>
> Hi all,
>
> Is the next behaviour suitable?
>
> identical(F,FALSE)
>
> ## [1] TRUE
>
> utils::getParseData(parse(text = "c(F,FALSE)", keep.so=rce = TRUE))
>
> ##    line1 col1 line2 col2 id parent                token terminal  text
> ## 14     1    1     1   10 14      0                 expr    FALSE
> ## 1      1    1     1    1  1      3 SYMBOL_FUNCTION_CALL     TRUE     c
> ## 3      1    1     1    1  3     14                 expr    FALSE
> ## 2      1    2     1    2  2     14                  '('     TRUE     (
> ## 4      1    3     1    3  4      6               SYMBOL     TRUE     F
> ## 6      1    3     1    3  6     14                 expr    FALSE
> ## 5      1    4     1    4  5     14                  ','     TRUE     ,
> ## 9      1    5     1    9  9     10            NUM_CONST     TRUE FALSE
> ## 10     1    5     1    9 10     14                 expr    FALSE
> ## 11     1   10     1   10 11     14                  ')'     TRUE     )
>
> I would expect that token for F is the same as token for FALSE.
>
>
> Thank you!
>
> Iago
>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

---------------
John Mount
http://www.win-vector.com/ <http://www.win-vector.com/>
Our book: Practical Data Science with R
http://practicaldatascience.com <http://practicaldatascience.com/>






        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: A bug understanding F relative to FALSE?

Iñaki Ucar
In reply to this post by IAGO GINÉ VÁZQUEZ
On Wed, 15 Jan 2020 at 15:14, IAGO GINÉ VÁZQUEZ <[hidden email]> wrote:

>
> Hi all,
>
> Is the next behaviour suitable?
>
> identical(F,FALSE)
>
> ## [1] TRUE
>
> utils::getParseData(parse(text = "c(F,FALSE)", keep.so=rce = TRUE))
>
> ##    line1 col1 line2 col2 id parent                token terminal  text
> ## 14     1    1     1   10 14      0                 expr    FALSE
> ## 1      1    1     1    1  1      3 SYMBOL_FUNCTION_CALL     TRUE     c
> ## 3      1    1     1    1  3     14                 expr    FALSE
> ## 2      1    2     1    2  2     14                  '('     TRUE     (
> ## 4      1    3     1    3  4      6               SYMBOL     TRUE     F
> ## 6      1    3     1    3  6     14                 expr    FALSE
> ## 5      1    4     1    4  5     14                  ','     TRUE     ,
> ## 9      1    5     1    9  9     10            NUM_CONST     TRUE FALSE
> ## 10     1    5     1    9 10     14                 expr    FALSE
> ## 11     1   10     1   10 11     14                  ')'     TRUE     )
>
> I would expect that token for F is the same as token for FALSE.

From the manual:

‘TRUE’ and ‘FALSE’ are reserved words denoting logical constants
    in the R language, whereas ‘T’ and ‘F’ are global variables whose
    initial values set to these.

Iñaki

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: A bug understanding F relative to FALSE?

Joris FA Meys
In reply to this post by IAGO GINÉ VÁZQUEZ
As others have pointed out, this is expected behaviour. Let me get on that
hill I'll die on: it is absolutely not suitable. It is way beyond time to
remove T and F as unprotected kind-of-synonyms for TRUE and FALSE, given
the amount of times I had to point out that:

T <- t(matrix(0:3,nrow=2))
isTRUE(T)

was the reason the code didn't do what it's supposed to do. (Also don't use
T as short for "Transpose of my matrix", but that's another hill.)

As we've become more strict on the use of T and F in packages, maybe 4.0.0
is a good milestone to finally drop this relic from the past? One can
dream...

Kind regards
Joris

On Wed, Jan 15, 2020 at 3:14 PM IAGO GINÉ VÁZQUEZ <[hidden email]> wrote:

> Hi all,
>
> Is the next behaviour suitable?
>
> identical(F,FALSE)
>
> ## [1] TRUE
>
> utils::getParseData(parse(text = "c(F,FALSE)", keep.so=rce = TRUE))
>
> ##    line1 col1 line2 col2 id parent                token terminal  text
> ## 14     1    1     1   10 14      0                 expr    FALSE
> ## 1      1    1     1    1  1      3 SYMBOL_FUNCTION_CALL     TRUE     c
> ## 3      1    1     1    1  3     14                 expr    FALSE
> ## 2      1    2     1    2  2     14                  '('     TRUE     (
> ## 4      1    3     1    3  4      6               SYMBOL     TRUE     F
> ## 6      1    3     1    3  6     14                 expr    FALSE
> ## 5      1    4     1    4  5     14                  ','     TRUE     ,
> ## 9      1    5     1    9  9     10            NUM_CONST     TRUE FALSE
> ## 10     1    5     1    9 10     14                 expr    FALSE
> ## 11     1   10     1   10 11     14                  ')'     TRUE     )
>
> I would expect that token for F is the same as token for FALSE.
>
>
> Thank you!
>
> Iago
>
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


--
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: A bug understanding F relative to FALSE?

Jan Gorecki
I agree it is not good to have those symbols used in packages, but I
found to use those quite often in my developement workflow, which is
something like:

    $ R -q
    > cc(F)

where `cc` is my function to rebuild application to recent state. I
use it really often. Having to type FALSE every time makes this
workflow relatively longer.
IMO it would be best to warn about T/F symbols during package check,
but not necessarily removing them globally.

On Fri, Jan 17, 2020 at 4:01 PM Joris Meys <[hidden email]> wrote:

>
> As others have pointed out, this is expected behaviour. Let me get on that
> hill I'll die on: it is absolutely not suitable. It is way beyond time to
> remove T and F as unprotected kind-of-synonyms for TRUE and FALSE, given
> the amount of times I had to point out that:
>
> T <- t(matrix(0:3,nrow=2))
> isTRUE(T)
>
> was the reason the code didn't do what it's supposed to do. (Also don't use
> T as short for "Transpose of my matrix", but that's another hill.)
>
> As we've become more strict on the use of T and F in packages, maybe 4.0.0
> is a good milestone to finally drop this relic from the past? One can
> dream...
>
> Kind regards
> Joris
>
> On Wed, Jan 15, 2020 at 3:14 PM IAGO GINÉ VÁZQUEZ <[hidden email]> wrote:
>
> > Hi all,
> >
> > Is the next behaviour suitable?
> >
> > identical(F,FALSE)
> >
> > ## [1] TRUE
> >
> > utils::getParseData(parse(text = "c(F,FALSE)", keep.so=rce = TRUE))
> >
> > ##    line1 col1 line2 col2 id parent                token terminal  text
> > ## 14     1    1     1   10 14      0                 expr    FALSE
> > ## 1      1    1     1    1  1      3 SYMBOL_FUNCTION_CALL     TRUE     c
> > ## 3      1    1     1    1  3     14                 expr    FALSE
> > ## 2      1    2     1    2  2     14                  '('     TRUE     (
> > ## 4      1    3     1    3  4      6               SYMBOL     TRUE     F
> > ## 6      1    3     1    3  6     14                 expr    FALSE
> > ## 5      1    4     1    4  5     14                  ','     TRUE     ,
> > ## 9      1    5     1    9  9     10            NUM_CONST     TRUE FALSE
> > ## 10     1    5     1    9 10     14                 expr    FALSE
> > ## 11     1   10     1   10 11     14                  ')'     TRUE     )
> >
> > I would expect that token for F is the same as token for FALSE.
> >
> >
> > Thank you!
> >
> > Iago
> >
> >
> >         [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
> <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
> -------------------------------
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel