On Mon, 2010-08-23 at 03:22 +0100, ted.hard...@manchester.ac.uk wrote:
snip /
[3] I have tried to argue for a moderate and flexible spirit in
what is advised in the Posting Guide. I am very uncomfortable
about proposals as prescriptive and rigid as yours seem to be.
Users,
Original Message
Subject:Re: [Rd] segfault in embedded r after call to repldlldo1
Date: Mon, 23 Aug 2010 12:46:07 +0200
From: Carl Martin Grewe gr...@zib.de
To: Simon Urbanek simon.urba...@r-project.org
On 08/20/2010 06:48 PM, Simon Urbanek wrote:
On Aug
Dear R development Team: I really know very little, so you may ignore
this post. I have found that my students often make the mistake of
mixing up comparisons and assignments with negative numbers:
if (x-3) do_something;
I parenthesize, but every once in a while, I forget and commit this
On Aug 15, 2010, at 8:38 PM, Ben Bolker wrote:
With the approach of R 2.12.0:
with mild apologies for re-opening this perennial issue:
is there any hope, if appropriate patches are submitted, of adding a
drop.levels argument (with default equal to FALSE to preserve backward
Thanks for the suggestion. I'll try to have a look later in the week
unless someone else gets there sooner.
luke
On Mon, 23 Aug 2010, Radford Neal wrote:
Regarding my suggesting speed improvement to evalList, Martin Morgan
has commented by email to me that at one point an object is left
I tried this several years ago thinking that is should make a
noticable difference but did not find the result warranted the change.
Compilers and architectures change, and vary, so maybe it is worth
revisiting at least on some architecture/compiler combinations.
luke
On Mon, 23 Aug 2010,
On 2010-08-23, at 6:15 AM, Barry Rowlingson wrote:
On Sun, Aug 22, 2010 at 4:33 PM, ivo welch ivo.we...@gmail.com wrote:
I have found that my students often make the mistake of
mixing up comparisons and assignments with negative numbers:
if (x-3) do_something;
If you tell your students
On Aug 22, 2010, at 4:47 AM, Rory Winston wrote:
Hi all
I had written a gdb macro to dump the string representation of an SEXPREC
type when I realised everything I needed was in inspect.c already in the
typename() function. However, the typename function doesnt handle the RAWSXP
type, so
Looking for more ways to speed up R, I've found that large
improvements are possible in the speed of sum and prod for long
real vectors.
Here is a little test with R version 2.11.1 on an Intel Linux system
a - seq(0,1,length=1000)
system.time({for (i in 1:100) b - sum(a)})
user
On Mon, Aug 23, 2010 at 6:06 PM, Davor Cubranic cubra...@stat.ubc.ca wrote:
The students are trying to *compare* to a negative number, and trip on R's
parsing of -. They could use '=' for assignment all they want (which I
thought is being discouraged as a code style these days, BTW), and
Hi, I'm just following your messages the overhead that the code for
dealing with possible NA/NaN values brings. When I was setting up
part of the matrixStats package, I've also though about this. I was
thinking of having an additional logical argument 'hasNA'/'has.na'
where you as a user can
Hi Simon
Thanks a lot - thats fantastic.
Many thanks for the quick response!
Cheers
-- Rory
On Tue, Aug 24, 2010 at 3:12 AM, Simon Urbanek
simon.urba...@r-project.orgwrote:
On Aug 22, 2010, at 4:47 AM, Rory Winston wrote:
Hi all
I had written a gdb macro to dump the string
Regarding my previous message on speeding up matrix multiplies, I've
realized that the size of the result matrix is not really the right
criterion for deciding to do the computation without using the Fortran
routine. A better criterion would be based on the ratio of the time
for the matrix
Henrik,
On Aug 23, 2010, at 5:33 PM, Henrik Bengtsson wrote:
Hi, I'm just following your messages the overhead that the code for
dealing with possible NA/NaN values brings. When I was setting up
part of the matrixStats package, I've also though about this. I was
thinking of having an
On Aug 23, 2010, at 7:39 PM, Radford Neal wrote:
Regarding my previous message on speeding up matrix multiplies, I've
realized that the size of the result matrix is not really the right
criterion for deciding to do the computation without using the Fortran
routine. A better criterion would
It seems as if the original point has been buried a bit here. So I'd just like
to briefly agree with what Ted Harding said about guidelines, and then return
to RTFM etc.
The price paid for writing the best bit of software in the world, is that
people want to use it. Some of those people will
On Aug 23, 2010, at 7:39 PM, Radford Neal wrote:
In particular, all matrix x vector and vector x matrix products will
in this version be done in the matprod routine, not the Fortran routine.
And this is the right thing to do, since the time for the ISNAN check
before calling the Fortan
On Mon, Aug 23, 2010 at 10:39 PM, Radford Neal radf...@cs.toronto.edu wrote:
On Aug 23, 2010, at 7:39 PM, Radford Neal wrote:
In particular, all matrix x vector and vector x matrix products will
in this version be done in the matprod routine, not the Fortran routine.
And this is the right
18 matches
Mail list logo
