similar to: Extracting specific arguments from "..."

Thanks Jorgen. I thought your approach to getting the argument expressions was clever, but somewhat convoluted. I think the usual simple way is to use match.call() (or sys.call() )to get the unevaluated argument expressions; e.g. ... f <- function(...){ match.call() } > f(a = 'red', b = sin(zzz)) f(a = "red", b = sin(zzz)) The return value is an object of class call

Bert and other on this Chain, The original question asked by Bert Gunter, highlights one of my long standing wishes. Perhaps my wish has already been fulfilled (if it has, please let me know where I can look of fulfill my wish), if it hasn't perhaps someone can grant me my wish. I have tried to understand how to write a function (beyond a basic function), get values of the parameters, and

It is a pretty tricky topic, but IMO Advanced R [1] steps you through it systematically... you just have to be prepared to follow along in R with the examples as you read it. In particular, the chapter on Functions goes through this. The subtleties of how base R gives you control over these topics is what lead to the tidyverse creating new packages to build such function interfaces. Manipulating

Jeff: Would you care to offer an example of: "String literals are surprisingly simple alternatives that don't bite you in the butt nearly so often as NSE does." "No" is a perfectly acceptable answer. I would generally agree with you about NSE, but my original query was motivated by something simple. I like to use lattice graphics when I fool around with graphing data, as

Colleagues, My interest is not in writing ad hoc functions (which I might use once to analyze my data), but rather what I will call a system function that might be part of a package. The lm function is a paradigm of what I call a system function. The lm function begins by processing the arguments passed to the function (represented in the function as parameters, see code below.) Much of this

There's an ancient (2003) document on the CRAN "developers' page" https://developer.r-project.org/model-fitting-functions.html that is sort of (but not exactly) what you're looking for ... On 2025-01-07 5:03 p.m., Sorkin, John wrote: > Colleagues, > > My interest is not in writing ad hoc functions (which I might use once to analyze my data), but rather what I

Ben, As always, thank you. You are correct, it is something like what I want, but not exactly. Perhaps someday someone will write a more complete guide. Thank you, John John David Sorkin M.D., Ph.D. Professor of Medicine, University of Maryland School of Medicine; Associate Director for Biostatistics and Informatics, Baltimore VA Medical Center Geriatrics Research, Education, and Clinical

Interesting discussion. A few things occurred to me. Apologies to Iris Simmons: I mixed up his answer with Bert's question. Bert raises questions about promises, and I think they are related to John Sorkin's question. A big difference between R and most other languages is that function arguments are computed lazily. match.call & substitute tell us what expressions will be evaluated

Yes, that will halve the number of multiplications. If you?re looking for such optimisations then you can also consider ifelse(G=='male', 65L, 58L). That will definitely use less time & memory if WC is integer, but the trade-offs are more complicated if WC is floating point. Regards, Jorgen Harmse. From: avi.e.gross at gmail.com <avi.e.gross at gmail.com> Date: Friday,

Just a minor point in the suggested solution: df$LAP <- with(df, ifelse(G=='male', (WC-65)*TG, (WC-58)*TG)) since WC and TG are not conditional, would this be a slight improvement? df$LAP <- with(df, TG*(WC - ifelse(G=='male', 65, 58))) -----Original Message----- From: R-help <r-help-bounces at r-project.org> On Behalf Of Jorgen Harmse via R-help Sent: Friday,

I'd propose an alternative that I think is superior: rely on the semantics of ... to do the work for you: f1 <- function(...){ one <- list(...)[['a']] two <- ...elt(match('a', ...names())) c(one, two, three(...)) } three <- function(a, ...) { a } f1(a = 1, b = 2, c = 3) #> [1] 1 1 1 On Sun, Jan 5, 2025 at 12:00?PM Bert Gunter <bgunter.4567 at

Duncan Murdoch answered your question, but I have another. Are you going to do some computation with the rounded numbers, or are they just for display? (One thing I like about Excel is that I can change the display format of a cell without changing answers that depend on that cell.) In the latter case, why stash them in a variable? For more control of the display, consider sprintf (or a wrapper

Hi again, The unz connection is non-blocking by default. I checked do_unz which calls R_newunz which calls init_con and the only place in any of those functions that sets 'blocking' is init_con which sets it to FALSE: https://github.com/wch/r-source/blob/0c26529e807a9b1dd65f7324958c17bf72e1de1a/src/main/connections.c#L713 I'll open an issue on R-bugzilla and see if they're

I might have factored the gender. I'm not sure it would in any way be quicker. But might be to some extent easier to develop variations of. And is sort of what factors should be doing... # make dummy data gender <- c("Male", "Female", "Male", "Female") WC <- c(70,60,75,65) TG <- c(0.9, 1.1, 1.2, 1.0) myDf <- data.frame( gender, WC, TG ) #

>?If you would like to try your hand at developing a patch and make a > case for it at R-devel or the Bugzilla, the resources at > <https://contributor.r-project.org/> can be helpful. I am attempting to get admitted onto the Bugzilla at the moment for the data frame cases, fingers crossed! Best Regards,Mark Webster [[alternative HTML version deleted]]

df$LAP <- with(df, ifelse(G=='male', (WC-65)*TG, (WC-58)*TG)) That will do both calculations and merge the two vectors appropriately. It will use extra memory, but it should be much faster than a 'for' loop. Regards, Jorgen Harmse. ------------------------------ Message: 8 Date: Fri, 3 Nov 2023 11:10:49 +1030 From: "Md. Kamruzzaman" <mkzaman.m at gmail.com>

But note: > zip("hello.zip", "hello.txt") updating: hello.txt (stored 0%) > readChar(unz("hello.zip","hello.txt"),100) [1] "hello" I leave it to you and other wiser heads to figure out. Cheers, Bert On Thu, Oct 24, 2024 at 8:57?AM Iris Simmons <ikwsimmo at gmail.com> wrote: > Hi Mikko, > > > I tried running a few

Consider: f1 <- function(...){ one <- list(...)[['a']] two <- ...elt(match('a', ...names())) c(one, two) } ## Here "..." is an argument list with "a" somewhere in it, but in an unknown position. > f1(b=5, a = 2, c=7) [1] 2 2 Which is better for extracting a specific named argument, one<- or two<- ? Or a third alternative that is

Or just dim(x) <- NULL. (as matrices in base R are just vectors with a dim attribute stored in column major order) ergo: > x [1] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 > x<- 1:20 ## a vector > is.matrix(x) [1] FALSE > dim(x) <- c(5,4) > is.matrix(x) [1] TRUE > attributes(x) $dim [1] 5 4 > ## in painful and unnecessary detail as dim() should

I appreciate the compliment from Ivan and still share the puzzlement at the empty return. What is the policy for changing something that is wrong? There is a trade-off between breaking old code that worked around a problem and breaking new code written by people who make reasonable assumptions. Mathematically, it seems obvious to me that duplicated.matrix(A) should do something like this: v