Thank you for trying 2.6.0 RC.
The example is far from minimal: most semi-transparent polygon fills were
failing due to a typo prior to r43003. Your example now works (several
times faster than under Cairo).
As you will see from the below, sending HTML makes your postings
unnecessarily hard t
Full_Name: Anjali Shitole
Version: R 2.5.1
OS:
Submission from: (NULL) (202.141.157.91)
I want to compute coefficient of variation for each subset of data.
Each subset is heterogeneous means number of rows in each subset are
different.These all subsets are in one dataset situated one by one.
i h
I read in a thread in r-help today that the windows device in 2.6 supports
transparency, so I tried an example and had some issues. The density plots
should be filled with transparent color in the following example (similar to
the points), however the color is "fully" transparent. This works i
Petr Savicky wrote:
> Thank you very much for all the explanations. In particular for pointing
> out that nrow is not a .Primitive unlike dim, which is the
> reason for the difference in their behavior. (I rised the question
> of possible bug due to this difference, not just being unsatisfied
> wit
R version 2.5.1 (2007-06-27)
I' running some simple R jobs via the Sun Grid Engine on our Linux cluster
in preparation for some bigger ones.
I checked R's capabilities on the cluster nodes (after failing to create a
png file) and am getting the following warning message:
[Run on a cluster node
Thank you very much for all the explanations. In particular for pointing
out that nrow is not a .Primitive unlike dim, which is the
reason for the difference in their behavior. (I rised the question
of possible bug due to this difference, not just being unsatisfied
with nrow). Also, thanks for:
On
As others already mentioned, in your example you are first creating an
integer matrix and the coercing it to a double matrix by assigning
(double) 1 to element [1,1]. However, even when correcting for this
mistake, there is an extra copy created when using matrix().
Try this in a fresh vanilla R
You seem to be assuming that the argument 'by' to the "data frame" method
of aggregate() is a call to list() with arguments which are names (and
evaluate to factors).
When aggregate.data.frame comes to be called, the 'by' argument is a
promise to the actual argument. In your example the actual
You can do this too:
aggregate(iris[-5], iris["Species"], mean)
or this:
with(iris, aggregate(iris[-5], data.frame(Species), mean))
or this:
attach(iris)
aggregate(iris[-5], data.frame(Species), mean)
The point is that you already don't have to write x = x. The only
reason you are writing it
Understood, but my point is that the naming I suggest should be the
default. One should not be 'punished' for being explicit in calling
aggregate.
On 27-Sep-07, at 1:06 PM, Gabor Grothendieck wrote:
> You can do this:
>
> aggregate(iris[-5], iris[5], mean)
>
>
> On 9/27/07, Mike Lawrence <[E
You can do this:
aggregate(iris[-5], iris[5], mean)
On 9/27/07, Mike Lawrence <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> A suggestion derived from discussions amongst a number of R users in
> my research group: set the default column names produced by aggregate
> () equal to the names of the objec
Hi all,
A suggestion derived from discussions amongst a number of R users in
my research group: set the default column names produced by aggregate
() equal to the names of the objects in the list passed to the 'by'
object.
ex. it is annoying to type
with(
my.data
,aggregate(
1) You implicitly coerced 'a' to be numeric and thereby (almost) doubled
its size: did you intend to? Does that explain your confusion?
2) I expected NAMED on 'a' to be incremented by nrow(a): here is my
understanding.
When you called nrow(a) you created another reference to 'a' in the
evalu
Petr Savicky wrote:
> On Wed, Sep 26, 2007 at 10:52:28AM -0700, Byron Ellis wrote:
>
>> For the most part, doing anything to an R object result in it's
>> duplication. You generally have to do a lot of work to NOT copy an R
>> object.
>>
>
> Thank you for your response. Unfortunately, you a
Simon Urbanek r-project.org> writes:
>
> Joe,
>
> which version of R and RJDBC are you using? The behavior you describe
> should have been fixed in RJDBC 0.1-4. Please try the latest version
> from rforge
> install.packages("RJDBC",,"http://rforge.net/";)
> and please let me know if that so
You or Peter stated that promises are internal so clearly they
should be evaluated going in or out of lists. Otherwise you get
the current situation.
If you had just wasted as much time as I have trying to debug
a program with promises you would immediately understand why
it was necessary
to be a
On Thu, 27 Sep 2007, Gabor Grothendieck wrote:
> Thanks for the explanation.
>
> For lists either: (a) promises should be evaluated as they
> enter the list or (b) promises evaluated as they exit the
> list (i.e. as they are compared, inspected, etc.).
What makes you conclude that this is what "s
In my previous email, I sent the example:
> a <- matrix(as.integer(1),nrow=14100,ncol=14100) # 774m
> a[1,1] <- 0 # 3.0g
> gc() # 1.5g
This is misleading. The correct version is
a <- matrix(as.integer(1),nrow=14100,ncol=14100) # 774m
a[1,1] <- as.integer(0) # 1.5g
gc() # 774m
So, t
On Wed, Sep 26, 2007 at 10:52:28AM -0700, Byron Ellis wrote:
> For the most part, doing anything to an R object result in it's
> duplication. You generally have to do a lot of work to NOT copy an R
> object.
Thank you for your response. Unfortunately, you are right. For example,
the allocated memo
Joe,
which version of R and RJDBC are you using? The behavior you describe
should have been fixed in RJDBC 0.1-4. Please try the latest version
from rforge
install.packages("RJDBC",,"http://rforge.net/";)
and please let me know if that solves your problem.
Cheers,
Simon
On Sep 26, 2007, at
Thanks for the explanation.
For lists either: (a) promises should be evaluated as they
enter the list or (b) promises evaluated as they exit the
list (i.e. as they are compared, inspected, etc.). I gather
the intent was (a) but it does not happen that way due to
a bug in R. Originally I thought
On Wed, 26 Sep 2007, Gabor Grothendieck wrote:
> I thought that perhaps the behavior in the previous post,
> while inconsistent with the documentation, was not all that
> harmful but I think its related to the following which is a potentially
> serious bug.
The previous discussion already establi
22 matches
Mail list logo
