Note that in
> > quantile(c("1","2","3"),p=.5)
> Error in (1 - h) * qs[i] :
> argument non numérique pour un opérateur binaire
the default quantile type (7) does not work for non-numerics.
Quantile types 1 and 3 work as expected:
> quantile(c("1","2","3"),p=.5, type=1)
50%
"2"
> quantile(c(
na(x)))
>>> return(x[FALSE][NA]) :
>>> l'argument n'est pas interprétable comme une valeur logique
>>> De plus : Warning message:
>>> In if (na.rm) x <- x[!is.na(x)] else if (any(is.na(x)))
>>> return(x[FALSE][NA]) :
>>> la conditi
>> return(x[FALSE][NA]) :
>> l'argument n'est pas interprétable comme une valeur logique
>> De plus : Warning message:
>> In if (na.rm) x <- x[!is.na(x)] else if (any(is.na(x))) return(x[FALSE][NA])
>> :
>> la condition a une longueur > 1 et seu
;
> Why not a test on arguments like?
> if (!is.numeric(x))
> stop("need numeric data")
>
>
> -Message d'origine-
> De : Marc Schwartz
> Envoyé : jeudi 9 janvier 2020 14:19
> À : Lipatz Jean-Luc
> Cc : R-Devel
> Objet : R
> On Jan 9, 2020, at 7:40 AM, Lipatz Jean-Luc wrote:
>
> Hello,
>
> Is there a reason for the following behaviour?
>> mean(c("1","2","3"))
> [1] NA
> Warning message:
> In mean.default(c("1", "2", "3")) :
> l'argument n'est ni numérique, ni logique : renvoi de NA
>
> But:
>> var(c("1","2","3
Hello,
Is there a reason for the following behaviour?
> mean(c("1","2","3"))
[1] NA
Warning message:
In mean.default(c("1", "2", "3")) :
l'argument n'est ni numérique, ni logique : renvoi de NA
But:
> var(c("1","2","3"))
[1] 1
And also:
> median(c("1","2","3"))
[1] "2"
But:
> quantile(c("1","
Serguei,
The R 3.5.0 release includes the fundamental ALTREP framework but does not
include many 'hooks' within R's source code to make use of methods on the
ALTREP custom vector classes. I have implemented a fair number, including
for mean() to use the custom Sum method when available, in the ALT
Hi,
By looking at a doc about ALTREP
https://svn.r-project.org/R/branches/ALTREP/ALTREP.html (by the way
congratulations for that and for R-3.5.0 in general), I was a little bit
surprised by the following example:
> x <- 1:1e10
> system.time(print(mean(x)))
[1] 5e+09
user system elapsed
On 03/31/2017 10:14 PM, Prof Brian Ripley wrote:
From ?NA
Numerical computations using ‘NA’ will normally result in ‘NA’: a
possible exception is where ‘NaN’ is also involved, in which case
either might result.
and ?NaN
Computations involving ‘NaN’ will return ‘NaN’ or perh
Although help("is.nan") says:
"Computations involving NaN will return NaN or perhaps NA: ..."
it might not be obvious that this is also why one may get:
> mean(c(-Inf, +Inf, NA))
[1] NaN
> mean(c(-Inf, NA, +Inf))
[1] NA
This is because internally the intermediate sum +Inf + -Inf is NaN in
t
On Fri, Mar 31, 2017 at 10:14 PM, Prof Brian Ripley
wrote:
> From ?NA
>
> Numerical computations using ‘NA’ will normally result in ‘NA’: a
> possible exception is where ‘NaN’ is also involved, in which case
> either might result.
>
> and ?NaN
>
> Computations involving ‘NaN’ w
From ?NA
Numerical computations using ‘NA’ will normally result in ‘NA’: a
possible exception is where ‘NaN’ is also involved, in which case
either might result.
and ?NaN
Computations involving ‘NaN’ will return ‘NaN’ or perhaps ‘NA’:
which of those two is not guarantee
In R 3.3.3, I observe the following on Ubuntu 16.04 (when building
from source as well as for the sudo apt r-base build):
> x <- c(NA, NaN)
> mean(x)
[1] NA
> mean(rev(x))
[1] NaN
> rowMeans(matrix(x, nrow = 1, ncol = 2))
[1] NA
> rowMeans(matrix(rev(x), nrow = 1, ncol = 2))
[1] NaN
> .rowMeans(
On Tue, 16 Mar 2010, William Dunlap wrote:
Both of the following should return NA,
but do not in "R version 2.11.0 Under
development (unstable) (2010-03-07 r51225)"
on 32-bit Windows:
Nor in any version of R in the last several years (e.g. 2.1.0)
> mean(c(1,10,100,NA), trim=.1)
Error in so
Both of the following should return NA,
but do not in "R version 2.11.0 Under
development (unstable) (2010-03-07 r51225)"
on 32-bit Windows:
> mean(c(1,10,100,NA), trim=.1)
Error in sort.int(x, partial = unique(c(lo, hi))) :
index 4 outside bounds
> mean(c(1,10,100,NA), trim=.26)
[1]
zheng...@mail.nih.gov wrote:
Full_Name:
Version: 2.9.0
OS: windows, linux
Submission from: (NULL) (128.231.21.125)
In NEWS, it says "median.default() was altered in 2.8.1 to use sum() rather
than mean(), although it was still documented to use mean().
This caused problems for P
Full_Name:
Version: 2.9.0
OS: windows, linux
Submission from: (NULL) (128.231.21.125)
In NEWS, it says "median.default() was altered in 2.8.1 to use sum() rather
than mean(), although it was still documented to use mean().
This caused problems for POSIXt objects, for which mean()
Healthcare
[EMAIL PROTECTED]
(801) 408-8111
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Thursday, February 28, 2008 2:35 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [Rd] mean (
Full_Name: Paul PONCET
Version: 2.6.0
OS: Windows 2000
Submission from: (NULL) (83.137.240.218)
Function 'mean.default' calls function 'stats::median' if 'trim >= 0.5'. In that
case the call should be 'stats::median(x, na.rm = na.rm)' instead of
'stats::median(x, na.rm = FALSE)'.
___
There is a simple solution to this kind of problem - for my
non-day-job-related software stuff, I usually subscribe under
my sourceforge address. Sourceforge's is simple re-direction service
so I actually cannot post from it; but I like incoming e-mails to go
through sourceforge for a double spam f
Hi Jari,
(and interested readers)
> "JO" == Jari Oksanen <[EMAIL PROTECTED]>
> on Wed, 07 Nov 2007 12:21:10 +0200 writes:
[..]
[...some very good stuff...]
[..]
JO> Cheers, Jari Oksanen
JO> PS. Please Mr Moderator, don't
G'day Gabor,
On Thu, 25 Jan 2007 09:53:49 -0500
"Gabor Grothendieck" <[EMAIL PROTECTED]> wrote:
> The help page for mean does not say what happens when one
> applies mean to a matrix.
Well, not directly. :-)
But the help page of mean says that one of the arguments is:
x: An R object.
Good point. Perhaps what is needed is a Note clarifying all this in ?mean
(unless the software itself is reworked as Martin has discussed).
Regarding var(x), one could use sd(x)^2.
On 1/25/07, Berwin A Turlach <[EMAIL PROTECTED]> wrote:
> G'day Gabor,
>
> On Thu, 25 Jan 2007 09:53:49 -0500
> "Ga
> "Gabor" == Gabor Grothendieck <[EMAIL PROTECTED]>
> on Thu, 25 Jan 2007 09:53:49 -0500 writes:
Gabor> The help page for mean does not say what happens when one
Gabor> applies mean to a matrix.
Gabor> mean and sd work in an inconsistent way on a matrix
Gabor> so that
The help page for mean does not say what happens when one
applies mean to a matrix.
mean and sd work in an inconsistent way on a matrix
so that should at least be documented.
Also there should be a See Also to colMeans since that
provides the missing column-wise analog to sd.
___
On Wed, 2006-10-04 at 21:57 -0500, Marc Schwartz wrote:
> On Wed, 2006-10-04 at 20:22 -0500, Marc Schwartz wrote:
> > On Thu, 2006-10-05 at 03:10 +0200, [EMAIL PROTECTED] wrote:
> > > Full_Name: Brad Christoffersen
> > > Version: 2.3.1
> > > OS: Windows XP
> > > Submission from: (NULL) (128.196.193
On Wed, 2006-10-04 at 20:22 -0500, Marc Schwartz wrote:
> On Thu, 2006-10-05 at 03:10 +0200, [EMAIL PROTECTED] wrote:
> > Full_Name: Brad Christoffersen
> > Version: 2.3.1
> > OS: Windows XP
> > Submission from: (NULL) (128.196.193.132)
> >
> >
> > Why is the difference between two numbers so dif
On Thu, 2006-10-05 at 03:10 +0200, [EMAIL PROTECTED] wrote:
> Full_Name: Brad Christoffersen
> Version: 2.3.1
> OS: Windows XP
> Submission from: (NULL) (128.196.193.132)
>
>
> Why is the difference between two numbers so different from the "mean relative
> difference" output from the all.equal()
Full_Name: Brad Christoffersen
Version: 2.3.1
OS: Windows XP
Submission from: (NULL) (128.196.193.132)
Why is the difference between two numbers so different from the "mean relative
difference" output from the all.equal() function? Is this an artifact of the
way R stores numerics? I could not f
That happened in 2.3.0 only, and we do ask people not to report on
obselete versions of R.
>From the NEWS for 2.3.1
o mean() on an integer (or logical) vector was treating NAs as
actual values (unless na.rm = TRUE).
and the actual value is the largest negative integer, usually -21
On 26 July 2006 at 04:17, [EMAIL PROTECTED] wrote:
| Full_Name: Benjamin Tyner
| Version: 2.3.0
| OS: linux-gnu (debian)
| Submission from: (NULL) (71.98.75.54)
|
|
| > mean(NA)
| returns -2147483648 on my system, which is -(1+.Machine$integer.max)
There is quite possibly something wrong with
Full_Name: Benjamin Tyner
Version: 2.3.0
OS: linux-gnu (debian)
Submission from: (NULL) (71.98.75.54)
> mean(NA)
returns -2147483648 on my system, which is -(1+.Machine$integer.max)
> sessionInfo()
Version 2.3.0 (2006-04-24)
i686-pc-linux-gnu
attached base packages:
[1] "methods" "stats"
[EMAIL PROTECTED] writes:
> Full_Name: John Peters
> Version: 2.3.0
> OS: Windows 2000, xp
> Submission from: (NULL) (220.233.20.203)
>
>
> In R2.3.0 on Windows 2000 and xp
>
> > mean(c(1i))
> [1] 0+2i
> > mean(c(1i,1i))
> [1] 0+3i
> > mean(c(1i,1i,1i))
> [1] 0+4i
>
> OK in R2.2.1
Yes. This c
Full_Name: John Peters
Version: 2.3.0
OS: Windows 2000, xp
Submission from: (NULL) (220.233.20.203)
In R2.3.0 on Windows 2000 and xp
> mean(c(1i))
[1] 0+2i
> mean(c(1i,1i))
[1] 0+3i
> mean(c(1i,1i,1i))
[1] 0+4i
OK in R2.2.1
__
R-devel@r-project.org m
34 matches
Mail list logo
