You asked
> (or ultimately the dimension of the generated plot in pixels) without
> know which of png(), jpeg() or bitmap() was used?
That is determined by arguments 'width' and 'height' in the call to the
device, and for the first two it is in pixels and for the third it is in
inches. Interna
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
On UNIX one can use #! notation. It would be nice to be able to do something
similar on Windows.
This could be done by giving Rscript the capability of skipping over
the first few
lines. For example, there might be a --skip=n argument or perhaps Rscript would
skip over any consecutive leading li
Hi,
I am trying to infer the dimension of an opened bitmap (png, jpeg,
bitmap device...) from par() parmeters. From the help on par(), I
found that:
> dim <- c(400, 200)
> png("foo.png", width=dim[1], height=dim[2])
> dim2 <- par("din") * par("cra") / par("cin")
> dev.off()
> dim2
[1] 399. 1
On Windows XP with
R version 2.5.0 Under development (unstable) (2007-01-22 r40548)
I always get a message about grdevices when I run Rscript, e.g.
C:\> rscript NUL
During startup - Warning messages:
1: there is no package called 'grdevices' in: library(package, lib.loc = lib.loc
, character.only
> "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
With:
R version 2.4.1 Patched (2007-01-22 r40548)
"rep" is missing from methods:::.BasicFunsList, causing
methods:::genericForPrimitive("rep") to fail, which in turn causes
setMethod("rep", ...) to fail. (setGeneric("rep") of course fails as it
should, saying that rep is a primitive and metho
Full_Name: Thomas Friedrichsmeier
Version: 2.4.1
OS: Linux
Submission from: (NULL) (84.61.205.78)
Frontends wishing to emulate an R console typically want to print the value of
an evaluation, if and only if R_Visible is TRUE. R_Visible has never been part
of the public API (at least not as far as
Full_Name: Thomas Friedrichsmeier
Version: 2.4.1
OS: Linux
Submission from: (NULL) (84.61.205.78)
Currently, the C-API provides for parsing vectors (R_ParseVector()), but there
does not seem to be a way to get at the detailed parse error message from C.
Only a status code is returned, no error me
Ashish Kulkarni wrote:
> Hin-Tak Leung wrote:
>> It might be interesting to know get some details on your hardware.
>>
>
> It's a P4 2.66GHz with a standard Intel motherboard having 1GB RAM.
>
That figures - I am on an opteron 2.2GHz on x86_64 linux with the
same amount memory, and running R in
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 1/25/2007 6:32 AM, Ashish Kulkarni wrote:
> Hello,
>
> R version 2.4.1 (2006-12-18)
> i386-pc-mingw32
>
> Calling serialize() with a NULL connection serializes it to a raw vector.
> However, when the object to be serialized is large, it takes a very long time:
>
>> system.time( serialize(ma
There was an error in the buffer allocation code that caused realloc
to be called far more often than needed; on systems where realloc is
slow this will cause problems. Will be fixed shortly in R-devel and
R-patched.
Best,
luke
On Thu, 25 Jan 2007, Ashish Kulkarni wrote:
> Hin-Tak Leung wrote:
Ashish Kulkarni wrote:
> Hin-Tak Leung wrote:
>
>> It might be interesting to know get some details on your hardware.
>>
>>
>
> It's a P4 2.66GHz with a standard Intel motherboard having 1GB RAM.
>
>
>> On my box, linux native seems to be a little slower than
>> your quick.serialize time
I think many would object to automatic check at every start-up. For the
issue at hand, perhaps a check inside bug.report() would go a long way?
Just an idea...
Andy
From: Barry Rowlingson
>
> Since many posts to R-devel/help invoke this response:
>
> Prof Brian Ripley wrote:
> > Please, use t
Hin-Tak Leung wrote:
>
> It might be interesting to know get some details on your hardware.
>
It's a P4 2.66GHz with a standard Intel motherboard having 1GB RAM.
> On my box, linux native seems to be a little slower than
> your quick.serialize times:
>
> > system.time( serialize(matrix(0, 100
Vladimir Eremeev wrote:
>
> That is, R correctly calls C wrapper,
> ...
> its arguments have correct values
>
That was not the case.
I forgot as.integer() in the .C call and one of the arguments was 0 instead
of 1.
Since that, indices in the array were calculated incorrectly, and the
program
Ashish Kulkarni wrote:
> Hello,
>
> R version 2.4.1 (2006-12-18)
> i386-pc-mingw32
>
> Calling serialize() with a NULL connection serializes it to a raw vector.
> However, when the object to be serialized is large, it takes a very long time:
>
>> system.time( serialize(matrix(0, 1000, 1000), N
Hello,
R version 2.4.1 (2006-12-18)
i386-pc-mingw32
Calling serialize() with a NULL connection serializes it to a raw vector.
However, when the object to be serialized is large, it takes a very long time:
> system.time( serialize(matrix(0, 1000, 1000), NULL) )
[1] 38.25 40.73 81.54NANA
[EMAIL PROTECTED] wrote:
> There is nothing here to reproduce.
> It clearly depends on your .RData, which is not available to us.
> Unless you can make it available, we cannot help.
>
Well, it's insufficient as a bug report, but the "no package called
'lattice'" bit suggests an installation issu
20 matches
Mail list logo
