Re: [Rd] Documentation of addmargins

 : SOEIRO Thomas; R Development List Objet : RE: Documentation of addmargins EMAIL EXTERNE - TRAITER AVEC PRÉCAUTION LIENS ET FICHIERS Thomas SOEIRO wrote: > Dear list, > There is a minor typo in addmargins (section Details): > - If the functions used to form margins are not commutative t

[Rd] Documentation of addmargins

Dear list, There is a minor typo in addmargins (section Details): - If the functions used to form margins are not commutative the result depends on the order in which margins are computed. Annotation of margins is done via naming the FUN list. + If the functions used to form margins are not

[Rd] Add ... to Reduce?

Dear list, Currently, it is needed to use anonymous functions to pass additional parameters to f in Reduce. The following patch adds ... to pass additional arguments directly and seems to work in simple cases (see example below). However, since this was not available (even though it is common

[Rd] documentation of asplit

Dear list, The documentation of `asplit` currently says (section Details): "apply *always* simplifies common length results, so attempting to split via apply(x, MARGIN, identity) does not work (as it simply gives x)." This may be updated (e.g., by simply removing "always") since `apply`

[Rd] Potential bugs in table dnn

rpbreaks[3]) > > # > > # 1:3 > > # 1:2 0 > > # Warning messages: > > # 1: In xtfrm.data.frame(x) : cannot xtfrm data frames > > # 2: In xtfrm.data.frame(x) : cannot xtfrm data frames > > > > Best regards, > > > > Thomas > >

[Rd] Potential improvements of ave?

level, though it is part > > of the official C API. I don't know of any plans for this to change, but I > > suppose it could. Plus for functions in R itself, we could even use it > > without exposing it more widely. A number of functions, including sort > > itself,

[Rd] Potential bugs in table dnn

t; > -Message d'origine- > > De : Martin Maechler [mailto:maechler using stat.math.ethz.ch] > > Envoyé : jeudi 14 octobre 2021 11:44 > > À : SOEIRO Thomas > > Cc : R Development List > > Objet : Re: [Rd] Potential bugs in table dnn > > > > EMA

Re: [Rd] Potential bugs in table dnn

# Warning messages: # 1: In xtfrm.data.frame(x) : cannot xtfrm data frames # 2: In xtfrm.data.frame(x) : cannot xtfrm data frames Best regards, Thomas > -Message d'origine- > De : Martin Maechler [mailto:maech...@stat.math.ethz.ch] > Envoyé : jeudi 14 octobre 2021 11:44 >

Re: [Rd] Potential bugs in table dnn

Inline comments below in the previous message I'm not 100% sure if the current behavior is intended or not. If not, here is a patch (which I can submit on R Bugzilla if appropriate): diff -u orig/table.R mod/table.R --- orig/table.R2021-10-13 10:04:28.560912800 +0200 +++ mod/table.R

[Rd] Potential bugs in table dnn

Dear list, table does not set dnn for dataframes of length 1: table(warpbreaks[2:3]) # has dnn # tension # wool L M H #A 9 9 9 #B 9 9 9 table(warpbreaks[2]) # has no dnn # # A B # 27 27 This is because of if (length(dnn) != length(args)) (line 53 in

Re: [Rd] trunc.Date and round.Date + documentation of DateTimeClasses

septembre 2021 15:27 À : SOEIRO Thomas Cc : r-devel@r-project.org; Dirk Eddelbuettel Objet : Re: [Rd] trunc.Date and round.Date + documentation of DateTimeClasses EMAIL EXTERNE - TRAITER AVEC PRÉCAUTION LIENS ET FICHIERS Excuse the exceptional top-reply: Note that a very related issue has been raised

Re: [Rd] trunc.Date and round.Date + documentation of DateTimeClasses

c.Date manage fractional days with round(x - 0.499).) -Message d'origine- De : SOEIRO Thomas Envoyé : mercredi 29 septembre 2021 17:00 À : 'r-devel@r-project.org' Objet : trunc.Date and round.Date + documentation of DateTimeClasses Dear All, 1) trunc.Date and round.Date: Currently,

[Rd] trunc.Date and round.Date + documentation of DateTimeClasses

Dear All, 1) trunc.Date and round.Date: Currently, the help page for trunc.Date and round.Date says "The methods for class "Date" are of little use except to remove fractional days". However, e.g., trunc.POSIXt(Sys.Date(), "years") and round.POSIXt(Sys.Date(), "years") work because the

Re: [Rd] sep hard coded in write.ftable

There is a small typo in the NEWS file: write.table -> write.ftable -Message d'origine- De : SOEIRO Thomas Envoyé : jeudi 2 septembre 2021 13:10 À : 'Martin Maechler' Cc : r-devel@r-project.org Objet : RE: [Rd] sep hard coded in write.ftable Dear Martin, Thank you very much for y

Re: [Rd] sep hard coded in write.ftable

Dear Martin, Thank you very much for your prompt feedback! Best regards, Thomas -Message d'origine- De : Martin Maechler [mailto:maech...@stat.math.ethz.ch] Envoyé : jeudi 2 septembre 2021 11:30 À : SOEIRO Thomas Cc : r-devel@r-project.org Objet : Re: [Rd] sep hard coded

[Rd] sep hard coded in write.ftable

Dear all, (This is a follow up of a previous suggestion for ftable that was added in R 4.1.0: https://stat.ethz.ch/pipermail/r-devel/2020-May/079451.html) The sep argument is hard coded in write.ftable: write.ftable <- function(x, file = "", quote = TRUE, append = FALSE,

[Rd] Potential improvements of ave? (Act 2)

Dear list,   This is a follow-up with another potential improvements of ave.   In the doc, x is documented as to be "a numeric", but this is not mandatory.   DF <- data.frame(x = letters, group = rep(1:2, each = 13)) ave(DF$x, DF$group, FUN = function(i) "a") #  [1] "a" "a" "a" "a" "a" "a" "a"

[Rd] reshape documentation

vignette also seems an excellent idea. These changes will probably helps numerous users. Best, Thomas On Wed, Mar 17, 2021 at 7:55 PM Michael Dewey wrote: > > Comments in line > > On 13/03/2021 09:50, SOEIRO Thomas wrote: > > Dear list, > > > > I have some quest

Re: [Rd] Potential improvements of ave?

hink about it? (i.e is it relevant for a patch?) Thanks, Thomas > > De : Abby Spurdle > Envoyé : lundi 15 mars 2021 10:22 > À : SOEIRO Thomas > Cc : r-devel@r-project.org > Objet : Re: [Rd] Potential improvements of ave? > > H

Re: [Rd] Potential improvements of ave?

De : Abby Spurdle Envoyé : lundi 15 mars 2021 10:22 À : SOEIRO Thomas Cc : r-devel@r-project.org Objet : Re: [Rd] Potential improvements of ave? EMAIL EXTERNE - TRAITER AVEC PRÉCAUTION LIENS ET FICHIERS Hi Thomas, These are some great suggestions. But I can't help but feel there's

Re: [Rd] Potential improvements of ave?

in my previous message). ________ De : SOEIRO Thomas Envoyé : vendredi 12 mars 2021 23:59 À : r-devel@r-project.org Objet : Potential improvements of ave? Dear all, I have two questions/suggestions about ave, but I am not sure if it's relevant for bug reports. 1) I

[Rd] reshape documentation

Dear list, I have some questions/suggestions about reshape. 1) I think a good amount of the popularity of base::reshape alternative is due to the complexity of reshape documentation. It is quite hard (at least it is for me) to figure out what argument is needed for respectively "long to wide"

[Rd] Potential improvements of ave?

Dear all, I have two questions/suggestions about ave, but I am not sure if it's relevant for bug reports. 1) I have performance issues with ave in a case where I didn't expect it. The following code runs as expected: set.seed(1) df1 <- data.frame(id1 = sample(1:1e2, 5e2, TRUE),

[Rd] Patch proposal for bug 17770 - xtabs does not act as documented for na.action = na.pass

Dear all, (This issue was previously reported on Bugzilla (https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17770) and discussed on Stack Overflow (https://stackoverflow.com/q/61240049).) The documentation of xtabs says: "na.action: When it is na.pass and formula has a left hand side (with

Re: [Rd] justify hard coded in format.ftable

able to move back and forth between various base class representations > seems like something that would be natural to provide. > > Thanks. > > On Thu, May 14, 2020 at 5:32 AM Martin Maechler > wrote: >> >>>>>>> SOEIRO Thomas >>>>>>&g

Re: [Rd] justify hard coded in format.ftable

I suspected it was partly due to the fact that ftable doesn't get much interest/isn't much used... So thank you very much for answering, and for your time! >> Dear all, >> I haven't received any feedback so far on my proposal to make "justify" >> argument available in stats:::format.ftable >>

Re: [Rd] justify hard coded in format.ftable

Dear all, I haven't received any feedback so far on my proposal to make "justify" argument available in stats:::format.ftable Is this list the appropriate place for this kind of proposal? I hope this follow-up to my message won't be taken as rude. Of course it's not meant to be, but I'm not

[Rd] justify hard coded in format.ftable

Dear all, justify argument is hard coded in format.ftable: cbind(apply(LABS, 2L, format, justify = "left"), apply(DATA, 2L, format, justify = "right")) It would be useful to have the possibility to modify the argument between c("left", "right", "centre", "none") as in format.default.