search for: discourages

tl;dr: Why are named arguments discouraged in `[.data.frame`, `[<-.data.frame` and `[[.data.frame`? (because this question is of the kind 'why is R designed like this?', I though R-devel would be more appropriate than R-help) ############################# Background: Now and then students presents there fancy functions like this:

They can get bitten in the last two lines of this example, where the 'x' argument is not first: > d <- data.frame(C1=c(r1=11,r2=21,r3=31), C2=c(12,22,32)) > d[1,1:2] C1 C2 r1 11 12 > `[`(d,j=1:2,i=1) C1 C2 r1 11 12 Warning message: In `[.data.frame`(d, j = 1:2, i = 1) : named arguments other than 'drop' are discouraged > `[`(j=1:2,d,i=1) Error in (1:2)[d, i =

Thanks Bill and Michael for taking the time to share your knowledge! As a further background to my question, here are two examples that I forgot to include in my original post (reminded by Michael's answer). I swapped the i and j arguments in `[.data.frame` and `[<-.data.frame`. With warnings, but else without (?) problem. Using Bill's data: `[.data.frame`(x = d, i = 1, j = 2) # [1]

Indeed: Using 'weights' is not meant to indicate that the same observation is repeated 'n' times. As I showed, this gives erroneous results. Hence I suggested that it is discouraged rather than encouraged in the Details section of lm in the Reference manual. Arie ---Original Message----- On Sat, 7 Oct 2017, wolfgang.viechtbauer at maastrichtuniversity.nl wrote: Using

Well, the situation with `[.data.frame` (and [<-) is complicated by the fact that the data.frame-method is not a primitive, but the generic IS. I'm not sure about dispatch for primitive-generics, but I bet it's done on the first argument (as with S3). Which means `[`(j=1:2,d,i=1) has nothing to do with `[.data.frame`, as some internal code equivalent to something like `[.integer` is

Ah, I think you are referring to this part from ?lm: "(including the case that there are w_i observations equal to y_i and the data have been summarized)" I see; indeed, I don't think this is what 'weights' should be used for (the other part before that is correct). Sorry, I misunderstood the point you were trying to make. Best, Wolfgang -----Original Message----- From:

Yes. Thank you; I should have quoted it. I suggest to remove this text or to add the word "not" at the beginning. Arie On Sun, Oct 8, 2017 at 4:38 PM, Viechtbauer Wolfgang (SP) <wolfgang.viechtbauer at maastrichtuniversity.nl> wrote: > Ah, I think you are referring to this part from ?lm: > > "(including the case that there are w_i observations equal to y_i and

AFAIR, it is a little more subtle than that. If you have replication weights, then the estimates are right, it is "just" that the SE from summary.lm() are wrong. Somehow, the text should reflect this. It is of some importance when you put glm() into the mix, because you can in fact get correct results from things like y <- c(0,1) w <- c(49,51) glm(y~1, weights=w,

In the Details section of lm (linear models) in the Reference manual, it is suggested to use the weights= option for summarized data. This must be discouraged rather than encouraged. The motivation for this is as follows. With summarized data the standard errors get smaller with increasing numbers of observations. However, the standard errors in lm do not get smaller when for instance all weights

i started on the nt domains for unix project on the basis of paul ashton's enthusiastic and "this can't be too hard" attitude, back in august 97. since then, with the encouragement of a number of people over the last three years, and with the discouragement of others, the nt domains protocols are now pretty well understood. due to that constant discouragement, i no longer find

My local R-devel version now has (in ?lm) Non-?NULL? ?weights? can be used to indicate that different observations have different variances (with the values in ?weights? being inversely proportional to the variances); or equivalently, when the elements of ?weights? are positive integers w_i, that each response y_i is the mean of w_i unit-weight observations

> On Jan 14, 2016, at 11:22 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Jan 14, 2016, at 9:38 AM, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >>> On Jan 14, 2016, at 5:18 AM, Dan Liew <dan at su-root.co.uk> wrote: >>> >>> On 14 January 2016 at 11:24, David Jones via llvm-dev

Since the three posters agree (only) that there is a bug, I propose to file it as a bug, which is the least we can do now. There is more to it: the only other case of a change in the Reference Manual which I know of, is also about the weights option! This is in coxph. The Reference Manual version 3.0.0 (2013) says about coxph: " ... If weights is a vector of integers, then the estimated

> I was under the impression that in-source-tree builds were an unsupported > configuration. It's certainly strongly discouraged. I'm not fond of the > idea of making it easier, especially when there's a maintenance cost to > doing so. > Strongly discouraged, and yes, this. -eric -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Thursday, 18 June 2020 06:11:18 CEST Andrew Bartlett via samba-technical wrote: > On Thu, 2020-06-18 at 04:46 +0100, S?rgio Basto via samba wrote: > > On Thu, 2020-06-18 at 14:43 +1200, Andrew Bartlett via samba wrote: > > > If we could get an even more modern version then we can consider > > > removing even more duplicate in-house cryptography. > > > >

On Thu, 2020-06-18 at 04:46 +0100, S?rgio Basto via samba wrote: > On Thu, 2020-06-18 at 14:43 +1200, Andrew Bartlett via samba wrote: > > If we could get an even more modern version then we can consider > > removing even more duplicate in-house cryptography. > > Thank you , glad to help . > > You mean do compat-gnutls36 packages ? IIRC, already when I tried to >

OK. We have now three suggestions to repair the text: - remove the text - add "not" at the beginning of the text - add at the end of the text a warning; something like: "Note that in this case the standard estimates of the parameters are in general not correct, and hence also the t values and the p value. Also the number of degrees of freedom is not correct. (The parameter

On Thu, Jan 17, 2013 at 1:30 PM, Eli Bendersky <eliben at google.com> wrote: > This is unfortunate. Last month I tweaked TestingGuide.rst to > discourage grep in favor of FileCheck. It now says: > > "The recommended way to examine output to figure out if the test > passes it using the FileCheck tool. The usage of grep in RUN lines is > discouraged." > >

On Thu, Jan 17, 2013 at 10:20 AM, Jim Grosbach <grosbach at apple.com> wrote: > > On Jan 17, 2013, at 9:57 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: > >> On Thu, Jan 17, 2013 at 7:51 PM, Sean Silva <silvas at purdue.edu> wrote: >>> On Thu, Jan 17, 2013 at 8:36 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >>>> We have to

FWIW from https://www.kernel.org/doc/Documentation/SubmittingPatches After you have submitted your change, be patient and wait. If Linus likes your change and applies it, it will appear in the next version of the kernel that he releases. However, if your change doesn't appear in the next version of the kernel, there could be any number of reasons. It's YOUR job to narrow down those