Hello,
I'm mailing r-devel because I think the performance problem I'm having
is best solved by re-writing reshape() in C. I've been reading the
"writing R extensions" documentation and I have some questions about
they best way to write the C bits, but first let me describe my problem:
I'm tryin
I have followed all instruction in R FAQ Section 9.2
This looks like a bug to me
"C:\Program Files\R\R-2.3.1\bin\Rgui.exe" --sdi
> version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor
Franck:
I suspect you'll have to include the exact wording of the relevant
setGeneric and setMethod calls (as well as any other functions called
in your method) to get an answer to your question. I just did:
> setGeneric("start", function(x, ...) standardGeneric("start"))
[1] "start"
> set
Hello !
there's a S3 method called start (and end too) to be used with objects of
class ts (package stats). I am writing a S4 class for which I would like to
use this function start, so that start with a ts calls the former method and
start with my S4 class (called MA) calls the function I want.
Fo
I think it needs to be strlen()+1, for the terminating null, or you'll
just be pray for your luck that your compiler actually
null-pad allocations to the nearest 4-byte or whatever and
so your program doesn't crash as it should later when you
try to read argV elsewhere. As for the other question a
UPDATE: Okay I've narrowed the problem down. Within my C routine I use the
getopt() method from . For some reason when I recall this routine
via my .Call, getopt() hasn't "refreshed" that is it still points to the end
of my parsed command line arguments. Is R keeping this function alive in
memo
On Wed, 23 Aug 2006, Tony Plate wrote:
> The way I avoid this problem is to use seq(len=n) instead of 1:n.
> Of course, the syntax can get inconvenient for starting values other
> than 1 or 0, but I haven't found that to be much of a problem.
>
> Using the idiom 1:n in programming (as opposed to i
On 8/23/06, John Chambers <[EMAIL PROTECTED]> wrote:
> A different discussion is the desire to pass object references in R.
> There are in fact objects that currently act as references, notably
> environments. If one wants to, a general reference-semantic set of
> capabilities can be added to R,
I use:
for (m in beg %:% end) {...}
where
"%:%" <- function(a, b) if (b >= a) a:b
-- David Brahm ([EMAIL PROTECTED])
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dominick Samperi
Sent: Wednesday, August 23, 2006 11:13 AM
To: r-devel@r-project.or
The way I avoid this problem is to use seq(len=n) instead of 1:n.
Of course, the syntax can get inconvenient for starting values other
than 1 or 0, but I haven't found that to be much of a problem.
Using the idiom 1:n in programming (as opposed to interactive use)
results in errors commonly enou
hadley wickham wrote:
>>> Providing the ability to write assignment functions that don't duplicate
>>> is a more urgent problem.
>>>
>> You mean, for end-users? It can be done via primitives.
>>
>
> Isn't this sort of a run-time optimisation? I thought R generally
> followed the funct
This is a longstanding problem when programing with seq.
In the common case that one wants 1,...,n such that if n is zero
a zero length answer is wanted, one can write seq(length = n)
instead of 1:n. However, the general case is still a problem,
as you point out.
On 8/23/06, Dominick Samperi <[EM
On Wed, 23 Aug 2006, Thomas Lumley wrote:
> On Wed, 23 Aug 2006, Dominick Samperi wrote:
>
> > In for loops of the form:
> > for(m in seq(beg,end))
> > ...
> >
> > when beg > end, the default behavior is
> > to decrement, and the action described
> > by ... is executed at least once.
> >
> > On t
Hello:
I have a general question about memory allocation. I'm having a problem
with an R function -- call it myRfunction -- that calls a C routine using
.Call. For some reason it works the first time I call it, but for every
subsequent time it doesn't. I'm thinking this has to be a memory alloc
I should point out that this recommendation was not designed just
to accommodate C/C++, it was motivated by problems
with R code of the form:
for(m in seq(beg,end))
val <- x[m]
Take beg=1, end=0, for example. This results in
val <- x[0]
and R issues no error about the subscript being out
of bound
On Wed, 23 Aug 2006, Dominick Samperi wrote:
> In for loops of the form:
> for(m in seq(beg,end))
> ...
>
> when beg > end, the default behavior is
> to decrement, and the action described
> by ... is executed at least once.
>
> On the other hand, if you view this
> construction as a translation o
In for loops of the form:
for(m in seq(beg,end))
...
when beg > end, the default behavior is
to decrement, and the action described
by ... is executed at least once.
On the other hand, if you view this
construction as a translation of the C code:
for(m = beg; m < end; m++)
...
then the semantics
Robin Hankin wrote:
> [[shifting to R-devel]]
>
> Hi Roger
>
> yes, I'm aware of gmp, but although it does handle big
> numbers, it uses exact integer arithmetic, which would be
> too slow for me.
>
> My example of 10^1 *(1+pi) ~= 4.14259*10^1
> would require gmp to process 1 digits,
> > Providing the ability to write assignment functions that don't duplicate
> > is a more urgent problem.
>
> You mean, for end-users? It can be done via primitives.
Isn't this sort of a run-time optimisation? I thought R generally
followed the functional programming model of immutable objects,
19 matches
Mail list logo
