Displaying 20 results from an estimated 20000 matches similar to: "logicals in data frames -- as.data.frame() should allow them"
2003 Oct 30
0
dist() objects with NA's don't print them (PR#4866)
The print.dist() method in the mva package currently prints the
triangular distance matrices with the ``trick'' of setting the
(diagonal and) upper triangular part to NA, and then uses
print(mat, na = "") to print that matrix.
This is very much undesired if there are true NAs.
Reproducible example code:
(x <- cbind(c(1,NA,2,3), c(NA,2,NA,1)))
(d <- dist(x)) ## does not
2003 Sep 26
2
Spam-Filter @stat.math.ethz.ch: was dead for about 15 hours
As many of you have probably realized, the spam filtering
at @stat.math.ethz.ch has been dead for since yesterday (09-25)
~16:50 till today ~08:30.
The sudden death may have been caused by unrelated installation
of some perl modules (spamassassin *is* running on perl) by our
IT staff.
We are very sorry for this event.
On the bright side: You have been able to get a glimpse of what
you are
2004 Apr 06
0
Accuracy Bug (PR#1228), (PR#6743)
>>>>> "daheiser" == daheiser <daheiser@gvn.net>
>>>>> on Tue, 6 Apr 2004 04:24:35 +0200 (CEST) writes:
daheiser> It is an error in the algorithm.
"it" being the behavior reported in bug report PR#1228 ---
[too bad you didn't use the whole string "PR#1228" in your subject;
if you had, no new report would have
2003 Sep 11
1
rank(*) with NAs -- new option "keep" desired
In some contexts, I find the current behavior of rank() very
`suboptimal'.
We have the argument na.last = {TRUE | FALSE | NA }
where the first two cases treating NAs (almost) as if they were
== +Inf or == -Inf whereas the 3rd case just drops NAs.
For the typical ``Rank Transformation'' that is recommended in
EDA in several contexts, I would however want something else,
namely keep
2004 Mar 25
0
R/ESS/Bioc* mailing lists: 2 hour time out -- 6 hours from now
This is (hopefully) a "once in ten years" event,
happening today, from 17--19 CET
(= 16--18 UTC = 11--13 US Eastern == 8--10 US Pacific Time)
The main `vault' (security, air condition,..) where our mail
server hypatia is located will undergo a major `network
re-connection' event that will affect a considerable part of ETH
-- including all the mailing lists
2003 Dec 13
0
chisq.test() and r2dtable() freezing on certain inputs (PR#5701)
>>>>> "MM" == Martin Maechler <maechler@stat.math.ethz.ch>
>>>>> on Thu, 11 Dec 2003 18:29:05 +0100 (CET) writes:
>>>>> "Torsten" == Torsten Hothorn <torsten@hothorn.de>
>>>>> on Thu, 11 Dec 2003 18:03:07 +0100 (CET) writes:
Torsten> On Thu, 11 Dec 2003, Jeffrey Chang wrote:
2003 Nov 24
0
R Mailing lists: "Sender:" now sometimes VERPs
{BCC'ed to three Core groups}
Following the recommendation of the mailman developers,
I have activated occasional "VERP"ing for our mailing lists.
(and will turn it off again, after about a day or so).
Here is the mailman "comment-docu" on this :
# These variables control the format and frequency of VERP-like delivery for
# better bounce detection. VERP is Variable
2002 Aug 05
0
Re: [S] Multinomial
>>>>> "Jacob" == Jacob van Wyk <jlvw at rau.ac.za> writes:
Jacob> Could anybody please help: I simply want to generate
Jacob> random samples from a multinomial distribution with
Jacob> fixed n and given probability vector p.
Jacob> How can I do this?
I've recently written the following {for the R package "normix"}.
The
2002 Oct 01
0
Delayed (and doubled) R-help mails
During the last 24 hours or so,
quite a few e-mails have been delayed for the R-help (and in one
case the R-announce) mailing lists.
The double posting of "New version of ipred package" to
R-announce is my fault, not the posters.
I apologize for all inconveniences.
The reason is a mail server upgrade and reconfiguration.
This should all be past now and the delayed mail hopefully soon
2004 Jan 03
0
error "evaluation nested too deeply" {was "Heatmap"}
I'm diverting this to the more appropriate mailing list, R-help,
since heatmap() is standard R function.
>>>>> "Johan" == Johan Lindberg <johanl at kiev.biotech.kth.se>
>>>>> on Fri, 02 Jan 2004 10:04:14 +0100 writes:
Johan> I am trying to plot a matrix of m-values in a heatmap
Johan> with "average linkage". The rows
2002 Sep 09
0
Re: [S] First max of a vector
>>>>> "MikeM" == Michael M Meyer <mikem at salter-point.com>
>>>>> on Sat, 07 Sep 2002 18:40:01 -0700 writes:
MikeM> which(x==max(x)) will return the indices fo all
MikeM> elements that are equal to the max. So the first max
MikeM> would be which(x==max(x))[1] (At least this works in
MikeM> R, I assume it does in
2002 Mar 22
0
Rdconv -> HTML bug {was ... `las' on `par' help...} (PR#1257)
>>>>> "Achim" == Achim Zeileis <zeileis@ci.tuwien.ac.at> writes:
Achim> Just a small documentation bug: something went wrong
Achim> for the description of the graphical parameter `las'
Achim> on the HTML version of the `par' help page: `las' is
Achim> missing and instead a line from the description is
Achim> used.
2002 Apr 22
1
predict.*bSpline() bugs extrapolating for deriv >= 1 (PR#1473)
I've already fixed the bugs, but as with the last one, this is
not critical enough to allow breaking current R-devel's code
freeze. I hope I will have corrected it for 1.5.1..
## Here is code reproducing the problems;
## I use try(.) whenever I know the current versions of R would
## give an error:
library(splines)
x <- c(1:3,5:6)
y <- c(3:1,5:6)
(isP <- interpSpline(x,y))#
2002 May 14
0
RE: cut.dendrogram (PR#1552)
>>>>> "MikG" == M GRUM <M.GRUM@CGIAR.ORG> writes:
MikG> I'm resending this bug report with a new example. As
MikG> seen below, cut.dendrogram gives an error message for
MikG> some heights, but not for others and with some
MikG> datasets adn not others. I can't see why.
MikG> Last time I unwittingly sent my message with
2002 Jul 26
0
predict() still not yet "safe".. (PR#1840)
Executive Summary: This only concerns predict() at new points
when the formula contained things like poly() or ns() {in the RHS}.
Because I hadn't have time to fix this yet, I submit it.
[R version 1.5.1 and at least 1.4.1, probably all versions at all:]
For these, R 1.5.x does not differ from 1.4.1 : Inspite of R
1.5.0's "NEWS" entry and the ?Safepredict help page,
2002 Nov 18
0
Apology for not enough protection of new R-devel
Dear R-devel subscribers,
I'm feeling quite sheepish at the moment:
When I had activated the change from majordomo to mailman this
morning, I accidentally didn't activate the spam(+some virus)
detection part. I've only activated it half an hour ago.
Indeed there were twos message of the following kind sent from
R-devel -- I did never seem them personally, because we *do*
filtering
2003 Jan 08
0
integer coercion when indexing and subsetting (PR#2430)
At the end of his bug report, Philippe says
PhGr> ..... Moreover, the subset operation [] uses as.integer() and
PhGr> consequently, can suffer from the same syndrome. A WARNING section in
PhGr> Extract.Rd would be welcome too.
[BTW: Thank you Philippe! ]
Currently, "Extract.Rd" does not say anything on the kind of
indices `i' that can be used in things like
2003 Oct 15
0
qqnorm(*, datax=TRUE, xlab,ylab) -- S+ compatibility problem
Just found because an old (written for S+) function of mine did
label plots wrongly with R.
Example --- inspired from example(qqnorm) ---
data(precip)
qqnorm(precip, ylab = "Precipitation [in/yr] ...")
qqnorm(precip, ylab = "Precipitation [in/yr] ...", datax = TRUE)
this is all "fine" -- `datax' is a switch that just switches the
axes but keeps the
2003 Oct 18
0
cor(*, use = "pair") bug in R 1.8.0 (PR#4646)
As reported on R-help by Ming-Chung Li,
the cor() function has a new bug in R 1.8.0 when used with
matrix arguments (to give the Cor-Matrix) and the non-default
use = "pairwise.complete.obs"
argument (which can be abbreviated, e.g. to use = "pair").
A quite minimal example is
> x <- cbind(1:3, c(0,4,5))
> cor(x)[1,2]
[1] 0.9449112
>
2004 Mar 08
0
as.dist() too tolerant
The current documentation for as.dist() contains
>> Usage:
>>
>> as.dist(m, diag = FALSE, upper = FALSE)
>>
>>
>> Arguments:
>>
>> m: A matrix of distances to be converted to a '"dist"' object
>> (only the lower triangle is used, the rest is ignored).
and indeed, as.dist(m) currently takes almost