Hello,
I currently work on the development of an R package where most of the
algorithm is implemented in C.
I would like to use MPI to improve the speed of the C routines when used
in a distributed computing environment. I am very new to MPI.
>From what I found in the R archive and online, I ca
On Mon, 4 Apr 2005 17:15:29 +0200 (CEST), [EMAIL PROTECTED]
wrote :
>Test case:
>z <- ts(matrix(rnorm(200),10,20), start=c(1961,1))
>acf(z,lag.max=1)
>
>This segfaults for me. Maybe it shouldn't?
This was a bug in the memory allocation in the C code, now fixed.
I've committed the fix to the beta
On Mon, Apr 04, 2005 at 07:58:59AM -0700, Robert Gentleman wrote:
> Well, then what most of us, that really want to figure it out do is:
> 1) look at the check script and find the actual invocation of Sweave
> (try running checkVignettes from the prompt, try running R with
> --quiet, etc.
>
>
David emailed me his dataset, and I get a segfault crash with it.
This happens in an R memory allocation routine after the C function
acf() in src/library/stats/src/filter.c has returned, so it looks to
me as though acf() is writing somewhere it shouldn't.
I'll try to track it down...
Duncan Murd
> Kurt Hornik writes:
> Peter Dalgaard writes:
>> Kurt Hornik <[EMAIL PROTECTED]> writes:
>>> stack info at the C level to actually see where in the code the error
>>> triggers. If I add debugging info prior to the error call, the error is
>>> gone.
>>>
>>> Btw, if I comment *output* red
Is this changes intentional?
Now
Rcmd INSTALL --build --clean myPkg
builds the tar.gz, and only then cleans. Also, files left by xemacs like
myfile~ are now included in the tar.gz. I think this were excluded before?
Intentional?
--
Kjetil Halvorsen.
Peace is the most effective weapon of mass constr
Thanks!
I did not realize that predict.lm calculates the standard
error of the prediction (which goes asumptotically to zero)
rather then prediction error.
The formula for standard erro should omits leding 1 under
square root and with delta method, one should omit rms^2
component. Then everythin
[EMAIL PROTECTED] writes:
> On Mon, 4 Apr 2005 18:01:05 +0200 (CEST), [EMAIL PROTECTED]
> wrote :
>
> >Full_Name: Marek Ancukiewicz
> >Version: 2.01
> >OS: Linux
> >Submission from: (NULL) (132.183.12.87)
> >
> >
> >It seems that the the standard error of prediction of the linear regression,
> >
On Mon, 4 Apr 2005 [EMAIL PROTECTED] wrote:
> On Mon, 4 Apr 2005 17:15:29 +0200 (CEST), [EMAIL PROTECTED]
> wrote :
>
>> Test case:
>> z <- ts(matrix(rnorm(200),10,20), start=c(1961,1))
>> acf(z,lag.max=1)
>>
>> This segfaults for me. Maybe it shouldn't?
>
> Not for me in a recent alpha build on
On Mon, 4 Apr 2005 17:15:29 +0200 (CEST), [EMAIL PROTECTED]
wrote :
>Test case:
>z <- ts(matrix(rnorm(200),10,20), start=c(1961,1))
>acf(z,lag.max=1)
>
>This segfaults for me. Maybe it shouldn't?
Not for me in a recent alpha build on Windows. Could you try it in
the latest R-alpha from CRAN?
D
On Mon, 4 Apr 2005 18:01:05 +0200 (CEST), [EMAIL PROTECTED]
wrote :
>Full_Name: Marek Ancukiewicz
>Version: 2.01
>OS: Linux
>Submission from: (NULL) (132.183.12.87)
>
>
>It seems that the the standard error of prediction of the linear regression,
>caclulated with predict.lm is incorrect. Consider
Full_Name: Marek Ancukiewicz
Version: 2.01
OS: Linux
Submission from: (NULL) (132.183.12.87)
It seems that the the standard error of prediction of the linear regression,
caclulated with predict.lm is incorrect. Consider the following example where
the standard error is first calculated with predi
Test case:
z <- ts(matrix(rnorm(200),10,20), start=c(1961,1))
acf(z,lag.max=1)
This segfaults for me. Maybe it shouldn't?
cheers
dave
--please do not edit the information below--
Version:
platform = i386-pc-linux-gnu
arch = i386
os = linux-gnu
system = i386, linux-gnu
status =
major = 2
m
> Peter Dalgaard writes:
> Kurt Hornik <[EMAIL PROTECTED]> writes:
>> stack info at the C level to actually see where in the code the error
>> triggers. If I add debugging info prior to the error call, the error is
>> gone.
>>
>> Btw, if I comment *output* redirection in tools::checkVignette
Kurt Hornik <[EMAIL PROTECTED]> writes:
> stack info at the C level to actually see where in the code the error
> triggers. If I add debugging info prior to the error call, the error is
> gone.
>
> Btw, if I comment *output* redirection in tools::checkVignettes(), the
> error is gone as well.
>
> Charles Geyer writes:
> On Sun, Apr 03, 2005 at 09:13:56AM -0400, Duncan Murdoch wrote:
>> On Sat, 2 Apr 2005 23:50:24 -0600, Charles Geyer
>> <[EMAIL PROTECTED]> wrote :
>>
>> >The subject line says it all. How can I find what
>> >
>> >Error: cannot set length of non-vector
>> >
>> >m
16 matches
Mail list logo