Full_Name: David Sterling
Version: 2.4.0
OS: OS X
Submission from: (NULL) (64.81.102.199)
lillie.test() dies without grace producing the error message: 'Error in if
(pvalue > 0.1) { : missing value where TRUE/FALSE needed' when passed a vector
of identical values.
Examples:
> lillie.test(c(0,0,0
[EMAIL PROTECTED] wrote:
> Full_Name: David Sterling
> Version: 2.4.0
For bug reports please try the most recent version of R (which currently
is either R-2.5.1 or R-devel if you are really enthusiastic).
But please never send a bug report for a contributed (non-base) package
to R-bugs, but alwa
Dear developers,
Duncan and me have just finished the update of the 'inline' package,
which latest version (0.3.2) is now on CRAN. In addition to the previous
update that featured saving and loading cfunction objects with
recompiling the code, the current release supports recompiling the code
in
Why does the error get generated here? Is it a bug? It seems that
f and "{" are the same but when used in sapply f works but { does not.
Is its use in lapply really "an incorrect context"?
> f <- function(x, y) y
> f(1, 2)
[1] 2
> "{"(1, 2)
[1] 2
> lapply("y", function(x, y) y, 1:4) # ok
[[1]]
[
Hi,
for diagnostic purposes, I would like to get information about
the BLAS / LAPACK linked against R from within an R-session.
An obvious application could be safety-checks for packages like
Matrix and quantreg at load / attach - time.
Also you could be more precise on the "framework" in which
Hi,
During a recent CRAN upload procedure, I was reminded of the following
regarding R-devel:
o R CMD check now warns on non-ASCII .Rd files without an
\encoding field, rather than just on ones that are definitely
not from an ISO-8859 encoding. This agrees with the
On Mon, 9 Jul 2007, Sebastian P. Luque wrote:
> Hi,
>
> During a recent CRAN upload procedure, I was reminded of the following
> regarding R-devel:
>
>
>o R CMD check now warns on non-ASCII .Rd files without an
>\encoding field, rather than just on ones that are definitely
>n
Gabor Grothendieck wrote:
> Why does the error get generated here? Is it a bug? It seems that
> f and "{" are the same but when used in sapply f works but { does not.
> Is its use in lapply really "an incorrect context"?
>
>
>> f <- function(x, y) y
>> f(1, 2)
>>
> [1] 2
>
>> "{"(1, 2)
On Mon, 9 Jul 2007 14:23:17 +0100 (BST),
Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
[...]
> \encoding(UTF-8}, yes.
Oops, yes (shift key pressed longer than needed).
> However, I would be worried about anything which 'needs' UTF-8 encoding,
> since it is going to be far from portable. If all
Announcing...
Planet R - a weblog aggregator for statistical computing
Q: What is it?
A: An aggregator for weblog posts about statistical computing topics,
focused primarily around the R community.
Q2: Where is it?
A2: For now, at http://planetr.stderr.org
Q3: What's it good for?
A3: Ho
Ben Bolker zoo.ufl.edu> writes:
> What would R-core think of the following 'enhanced'
> sweep?
(now posted at
http://wiki.r-project.org/rwiki/doku.php?id=rdoc:base:sweep
)
It always warns if dim(x)[MARGIN] is
> not a multiple of length(STATS) {it's very hard indeed
> for me to think of a s
Just one additional observation. { does work with mapply:
> f <- function(x, y) y
> mapply(f, letters, 1:26)
a b c d e f g h i j k l m n o p q r s t u v w x y z
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
> mapply("{", letters, 1:26) # s
Hi
This is a question prompted by the mac version of R, but as I see it,
it should have broader interest.
These days the CRAN Mac binary per default compiles every package for
two architectures. First i386 and then ppc. In between the two
compilation runs, any object files in pkgname/src is
AFAIK all platforms by default work the same: they use dynamic libraries
for BLAS and LAPACK, and these may well be symbolic links. I know of no
way to ask a BLAS dynamic library what version it is.
On Mon, 9 Jul 2007, Peter Ruckdeschel wrote:
> Hi,
>
> for diagnostic purposes, I would like to
14 matches
Mail list logo
