A small comment about new variables in data frames

[justinmcgrath]

Some examples give this code for creating new variables in data frame:
mtcars$hwratio <- mtcars$hp / mtcars$wt.

The corresponding Tidy version is this:
mtcars %>% mutate(hwratio=hp/wt) -> mtcars.

Maybe it's not a "beginner" topic, but I think the typical base R way is this:
mtcars <- within(mtcars, hwratio <- hp/wt).

There's really no difference between that and the Tidy version, since as far as I can tell, mutate and within do the same thing. Tidy insists the %>% operator though. Without that, it's nearly identical (mtcars <- mutate(mtcars, hwaatio=hp/wt)), and one wonders why you would add a slew of dependencies simply to rename "within" to "mutate".

[dusadrian]

I've always wondered why does within() return a copy of the object, instead of modifying the object.
My natural expectation, when I specify something should happen "within", it to actually happen, and not bother with overwriting the object.

This should / could have been enough, IMO:

within(mtcars, hwratio <- hp/wt)

EDIT: I've actually put together a quick function in the development version of package admisc, and it seems to work:

mt <- mtcars
inside(mt, hwratio <- hp/wt)

dim(mtcars) # 32 11

dim(mt) # 32 12

[botanybay]

Within the tidyverse, I would go for the shorthand:

mtcars %<>% mutate(hwratio=hp/wt)

However, there is no reason to do so, because a very simple assignment in base R does the trick neatly.

However, a pipe over multiple lines may be something where I would go for a "tidy" version. I can add a single line or out-comment one, and still have linearly legible code. 🤷

[BroVic]

I think, strictly speaking, tidy proponents don't even favour the %<>% pipe assignment. Is this operator even exported by the tidyverse packages? I don't recall it being so...

[justinmcgrath]

I've always wondered why does within() return a copy of the object, instead of modifying the object. My natural expectation, when I specify something should happen "within", it to actually happen, and not bother with overwriting the object.

This should / could have been enough, IMO:

within(mtcars, hwratio <- hp/wt)

EDIT: I've actually put together a quick function in the development version of package admisc, and it seems to work:

mt <- mtcars
inside(mt, hwratio <- hp/wt)

dim(mtcars) # 32 11

dim(mt) # 32 12

One of the easiest ways to make a program difficult to understand is to modify an object without using an assignment operator. That is deliberately difficult in R.

[dusadrian]

I agree, but really, what is the purpose of creating a new variable without overwriting the object?
If I am not grossly mistaken, overwriting the object always happens and hence it should be superfluous.

These are all equivalent, in my mind:

mtcars$hwratio <- mtcars$hp / mtcars$wt

# two assignment operators are definitely more difficult to understand for beginners
mtcars <- with(mtcars, hwratio <- hp/wt) 

# perhaps this is more comprehensive
mtcars$hwratio <- with(mtcars, hp/wt)

# or even better
inside(mtcars, hwratio <- hp/wt)

Note the later does have an assignment operator that signals (or should signal) creating a new variable.

Anyways, if such a function is clearly documented, users should be aware and decide accordingly.
I for one will definitely use it from now on, it saves unnecessary typing and it's the simplest of all above.

[BroVic]

transform(mtcars, hwratio = hp/wt)?

[dusadrian]

Oh my...
Thank you @BroVic, good to see there actually is something in base R that confirms my intuition.
EDIT: actually, this doesn't do anything different from within(). It does not modify the object the way inside() does, but returns a copy of the (modified) object.

[BroVic]

No it doesn't modify-in-place. I was just referring to the tidyverse discourse. 👍

I think the semantics in R does not provide an advantage to such modifications since, internally, every data frame is copied once it's modified.

[matloff]

I really don't think use of within() is standard base R. I've never seen an R book or tutorial use it. And I certainly would not recommend teaching it, for exactly the same reason. Sorry for the long delay in replying.

[dusadrian]

I really don't think use of within() is standard base R. I've never seen an R book or tutorial use it. And I certainly would not recommend teaching it, for exactly the same reason. Sorry for the long delay in replying.

This is a base R function. If that is not standard, then I am afraid I don't understand what the purpose of the discussion is...
(and, to agree to disagree, I would definitely recommend teaching it)

[matloff]

My own view -- different people have different views -- is that in teaching R learners who lack prior coding background, one should keep it as simple as possible. Abstractions that are second nature to experienced coders are not easy for such learners to understand, let alone use. So to me, just because a construct is part of base-R does not mean it is appropriate for these learners.

…

On Tue, Feb 25, 2025 at 6:27 AM Adrian Dușa ***@***.***> wrote: I really don't think use of within() is standard base R. I've never seen an R book or tutorial use it. And I certainly would not recommend teaching it, for exactly the same reason. Sorry for the long delay in replying. This is a base R function. If that is not standard, then I am afraid I don't understand what the purpose of the discussion is... (and, to agree to disagree, I would definitely recommend teaching it) — Reply to this email directly, view it on GitHub <#42 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZ34ZL2GRWI2WHTXH3NGST2RR4T5AVCNFSM6AAAAABX2ZFP7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBSGE3DGMJUGA> . You are receiving this because you commented.Message ID: ***@***.***> [image: dusadrian]*dusadrian* left a comment (matloff/TidyverseSkeptic#42) <#42 (comment)> I really don't think use of within() is standard base R. I've never seen an R book or tutorial use it. And I certainly would not recommend teaching it, for exactly the same reason. Sorry for the long delay in replying. This is a base R function. If that is not standard, then I am afraid I don't understand what the purpose of the discussion is... (and, to agree to disagree, I would definitely recommend teaching it) — Reply to this email directly, view it on GitHub <#42 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZ34ZL2GRWI2WHTXH3NGST2RR4T5AVCNFSM6AAAAABX2ZFP7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBSGE3DGMJUGA> . You are receiving this because you commented.Message ID: ***@***.***>

[dusadrian]

Completely agree, with only one observation: beginners don't do coding, but scripting.
For scripting purposes, they need the simplest possible code that they can adapt to their needs, ideally just changing the dataset name and the variables.
If teaching how to code is the issue, then it is not about complex R functions to use, but rather a matter of teaching standard/proper R code instead of blindly jumping to tidyverse.

[matloff]

Hard to distinguish between scripting and coding, though. Some R users may never run something consisting of more than 5 or 10 lines, but to me it's coding. I don't mean to harp on this, but I really believe the main issue is degrees of abstraction that an R user is capable of at any given time. The more examples they see, even if as you say just substituting new names, the deeper that capability becomes.