On Tue, Aug 24, 2010 at 5:17 AM, wrote:
> - Also, "?glm" does come over as pretty rude,
>
Personally I've always seen the '?fun' answers as appropriate and
straight to the point. There's no need to type a nice sounding phrase
à la française just to express 'see the ?glm reference'. A
'requiremen
On Mon, Aug 23, 2010 at 10:39 PM, Radford Neal 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 thing to do
> 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
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 be
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 wou
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 ad
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 multipl
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
wrote:
>
> 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
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 spec
I've looked at the code for matrix multiplies in R, and found that it
can speeded up quite a bit, for multiplies that are really vector dot
products, and for other multiplies in which the result matrix is small.
Here's my test program:
u <- seq(0,1,length=1000)
v <- seq(0,2,length=1000)
A2 <- ma
I tell to my students that it is very important (not only for
legibility) to place spaces between operands. They have to write such a
code like this:
if (x < -3) do_something
That way, there is no ambiguity. Don't you think it's important to write
clear code, including by using spaces where i
On 23-Aug-10 17:50:44, Barry Rowlingson wrote:
> On Mon, Aug 23, 2010 at 6:06 PM, Davor Cubranic
> 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 a
On Aug 23, 2010, at 1:19 PM, Radford Neal wrote:
> 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.
>
The results are likely very compiler- and architecture specific. On my machine
[x86_64, OS X 10
On Mon, Aug 23, 2010 at 6:06 PM, Davor Cubranic 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 they'll
> still r
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 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
On 2010-08-23, at 6:15 AM, Barry Rowlingson wrote:
> On Sun, Aug 22, 2010 at 4:33 PM, ivo welch 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 not to u
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, Radfor
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
unpro
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
> comp
Regarding my suggesting speed improvement to evalList, Martin Morgan
has commented by email to me that at one point an object is left
unprotected when COPY_TAG is called, and has wondered whether that is
safe. I think it is safe, but the code can be changed to protect this
as well, which actually
On Sun, Aug 22, 2010 at 4:33 PM, ivo welch wrote:
> 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 parenth
As I mentioned in my previous message about speeding up evalList, I've
been looking at ways to speed up the R interpreter. One sees in the
code many, many calls of PROTECT, UNPROTECT, and related functions, so
that seems like an obvious target for optimization. Indeed, I've
found that one can spe
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
mis
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
To: Simon Urbanek
On 08/20/2010 06:48 PM, Simon Urbanek wrote:
> On Aug 20, 2010, at 12:14 PM, Carl Martin Grewe
On Mon, 2010-08-23 at 03:22 +0100, ted.hard...@manchester.ac.uk wrote:
>
> [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, especial
26 matches
Mail list logo
