News for hackers. Stuff that matters.

A comment on Parsing R code: Freedom of expression is not always a good idea (2012).

Re:Parsing R code: Freedom of expression is not always a goo... by nomilk on Tuesday June 14, 2022 @08:29AM (#31738270)
I'm constantly discovering oddities about the R language. Since I use it interactively, it's extremely rare that such oddities cause any problems. Here's an example I found yesterday (lines 1, 2, 3, and 4 make sense, 5 is interesting, and 6 is perplexing!):

1 == TRUE # TRUE

as.logical(1) # TRUE

0 == FALSE # TRUE

as.logical(0) # FALSE

2 == TRUE # FALSE

as.logical(2) # TRUE

[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by wodenokoto on Tuesday June 14, 2022 @08:36AM (#31738389)
I think it it makes sense.

TRUE and FALSE are 1 and 0, while `as.logical` will transform your value to the "closest" of those two.

If you are used to Pythons truthiness, that is what `as.logical` is similar to.

[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by abirch on Tuesday June 14, 2022 @11:05AM (#31740572)
Truthy values go through most C type languages. Python included. bool(2) is True
[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by qsort on Tuesday June 14, 2022 @11:08AM (#31740616)
Python goes even further beyond.

  >>> True + True
  2

  >>> True * 13 + (1 - False) * 17
  30
[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by kgwgk on Tuesday June 14, 2022 @01:08PM (#31742529)
What you show there is that int(True) is one and int(False) is zero.

(The same happens in R, for what it's worth. as.integer(TRUE) is one and as.integer(FALSE) is zero and the operations you wrote work just he same.)

[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by tech2 on Tuesday June 14, 2022 @12:46PM (#31742113)
That's history coming back to bite it though. There was a period where the symbols True and False existed in Python but the bool class did not. True was _literally_ 1, and False was 0. Because of this, for backward compat, bool is a subclass of int.
[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by nomilk on Tuesday June 14, 2022 @11:10AM (#31740633)
TIL. Also in python bool("a") is True, whereas in R as.logical("a") is NA.
[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by marcosdumay on Tuesday June 14, 2022 @12:48PM (#31742163)
It makes sense if you know C or any architecture's assembly.

But it is an issue, and high level languages shouldn't just replicate it. In a high-level language `1 == TRUE` should be either an error or false.

[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by ellisv on Tuesday June 14, 2022 @08:41AM (#31738452)
If you like these oddities, then check out The R Inferno [1]. It’s from 2011, but still holds up since the language hasn’t changed that much.

[1] https://www.burns-stat.com/pages/Tutor/R_inferno.pdf

[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by pxeger1 on Tuesday June 14, 2022 @11:33AM (#31741000)
My favourite odd R snippet is this, which prints the numbers 0 to 100 without using any digits in the code:

    F:volcano
(from https://codegolf.stackexchange.com/a/219617)
[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by waffleiron on Tuesday June 14, 2022 @09:29AM (#31739142)
As someone who actually likes R I think this makes sense. Line 5 is checking for equality, whereas in R as.* functions actually convert types or structures. The documentation on as.logical is also pretty clear on what would happen.

https://www.rdocumentation.org/packages/raster/versions/3.5-...

> Change values of a Raster* object to logical or integer values. With as.logical, zero becomes FALSE, all other values become TRUE. With as.integer values are truncated.

[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by jghn on Tuesday June 14, 2022 @10:47AM (#31740309)
Yeah. There's a difference between "This language isn't being internally consistent" and "Due to my experience using language X, I find this confusing". As you say, this is well documented behavior, albeit perhaps unexpected to a novice R user.
[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by davidktr on Tuesday June 14, 2022 @10:26AM (#31740021)
Seems perfectly fine to me? It's R, for interactive data analysis and statistics. I love it, but would not use it for anything else.
[ Parent | on HN ]
Re:Parsing R code: Freedom of expression is not always a goo... by kgwgk on Tuesday June 14, 2022 @11:52AM (#31741228)
as.logical(2) being TRUE is perplexing only if you interpreted

2 == TRUE

as

as.logical(2)==TRUE

rather than as

2==as.integer(TRUE)

[Edit: "If the two arguments are atomic vectors of different types, one is coerced to the type of the other, the (decreasing) order of precedence being character, complex, numeric, integer, logical and raw."]

[ Parent | on HN ]