Re: [Rd] efficiency of sample() with prob.
> You chose to report just one extremely favourable example, < ignore> > I do think you are being `careless with the truth'. I chose to report whatever I got and whatever I felt the result was. It was not a scientific report and it was up to you (the R-team) to validate my result and make further investigations. When I was asked for a more thorough research in this field (and thus take the responsibility to my results), I said no since I did not have enough expertise and time. After all, I could have chosen not to report anything at all. If this mailing list only accepts serious contributions from field professionals, it is time for me to quit. > Hmm. A sample every 100ns and generating samples several times faster > than tabulating them is something to be impressed by. > Not in our tests. Did you try my 5 out of 10,000 non-zero probablilties > distribution, for example? No. I did not try. Intuitively, Walker's method may be slow because of the memory allocation and table setup stuff. It should be used with large sample and small prob vector. Bisection method should be quicker when the prob vector is large (so linear search is slow) and the sample size is relatively small. I thought bisection would be uniformly quicker than the linear search method since there is no additional cost other than a few more variables. If you have done enough experiments and know the fastest method in each case, it should be straightforward to implement a hybrid method where the best method is chosen based on the lengths of sample and prob vector. I might have been reporting partial results, but the 80 times speed-up in some cases was not faked. Cheers, Bo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] compile R with Portland Group compiler
Hi, After getting some help from Portland Group, I was able to pass the initial stage of building R with Portland Group Compiler on AMD Opeteron. For anyone who is interested in building R with PG compiler, here is a list of set flags used in config.site, CC=/usr/pgi/linux86-64/6.0/bin/pgcc CFLAGS='-g -O2 -mieee-fp' CPPFLAGS='-I/usr/pgi/linux86-64/6.0/include -I/usr/pgi/linux86-64/6.0/include/CC' F77=/usr/pgi/linux86-64/6.0/bin/pgf77 FFLAGS=-O2 CPICFLAGS=-fpic FPICFLAGS=-fpic SHLIB_LDFLAGS=-shared LDFLAGS='-L/usr/pgi/linux86-64/6.0/libso -L/usr/lib64' CXX=/usr/pgi/linux86-64/6.0/bin/pgCC CXXPICFLAGS=-fpic SHLIB_CXXLDFLAGS=-shared After installing R, I went ahead to install simpleaffy package. However, came across the following errors. PGC-S-0035-Syntax error: Recovery attempted by replacing '/' by double 0.0E+0 (simpleaffy.c: 455) PGC-S-0035-Syntax error: Recovery attempted by replacing identifier by by '!=' (simpleaffy.c: 455) PGC-S-0035-Syntax error: Recovery attempted by replacing integer 15 by '!=' (simpleaffy.c: 455) PGC-S-0039-Use of undeclared variable added (simpleaffy.c: 455) PGC-S-0037-Syntax error: Recovery attempted by deleting identifier march (simpleaffy.c: 455) PGC-S-0039-Use of undeclared variable Crispin (simpleaffy.c: 455) PGC-S-0035-Syntax error: Recovery attempted by replacing identifier with by '!=' (simpleaffy.c: 455) PGC-S-0035-Syntax error: Recovery attempted by replacing identifier in by '!=' (simpleaffy.c: 455) PGC-S-0039-Use of undeclared variable deals (simpleaffy.c: 455) PGC-S-0035-Syntax error: Recovery attempted by replacing identifier largest by '!=' (simpleaffy.c: 455) PGC-S-0039-Use of undeclared variable ties (simpleaffy.c: 455) PGC-S-0035-Syntax error: Recovery attempted by replacing '...' by ',' (simpleaffy.c: 455) PGC-S-0039-Use of undeclared variable the (simpleaffy.c: 455) PGC-S-0039-Use of undeclared variable ranks (simpleaffy.c: 455) PGC/x86-64 Linux/x86-64 6.0-5: compilation completed with severe errors make: *** [simpleaffy.o] Error 2 ERROR: compilation failed for package 'simpleaffy' Apparently, PG compiler doesn't like "//" style for comments. So, by changing "//" to "/* */" style fixed above errors. The commenting style errors also happened in other packages, such as affy. Since "/* */" comment style is acceptable by both PG Compiler and gcc, it is probably worthwhile to use "/* */" consistently throughout R packages. Regards, Jennifer Prof Brian Ripley wrote: > Let us be clear: some things in config.log are designed to fail, so > only unexpected errors are a cause to look there. The regex.c > warnings are it seems from an over-zealous compiler. > > The problems here seem to be the unknown use of .lo (which it seems to > have coped with) and a problem in the PG's own libc, which it seems > cannot be used in a shared object. That issue discussed in the > R-admin manual, and seems something you do need to take up with PG. > The crucial part is > >> /usr/bin/ld: /usr/pgi/linux86-64/6.0/lib/libpgc.a(fastmath.o): >> relocation >> R_X86_64_PC32 against `__fvdlog' can not be used when making a shared >> object; >> recompile with -fPIC > > > which is asking you to recompile their static library. If you can't > use a dynamic library then this is fatal. > > > On Wed, 24 Aug 2005, Jennifer Lai wrote: > >> I downloaded R-devel and compiled it with pgcc. This time, instead of >> breaking in src/main, compilation breaks in src/modules with the >> following error messages. >> >> Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. >> Copyright 2000-2005, STMicroelectronics, Inc. All Rights Reserved. >> /usr/pgi/linux86-64/6.0/bin/pgcc -shared >> -L/usr/pgi/linux86-64/6.0/lib -L/usr/lib64 -o R_X11.so dataentry.lo >> devX11.lo rotated.lo rbitmap.lo -lSM -lICE -L/usr/X11R6/lib64 -lX11 >> -ljpeg -lpng -lz >> File with unknown suffix passed to linker: dataentry.lo >> File with unknown suffix passed to linker: devX11.lo >> File with unknown suffix passed to linker: rotated.lo >> File with unknown suffix passed to linker: rbitmap.lo >> /usr/bin/ld: /usr/pgi/linux86-64/6.0/lib/libpgc.a(fastmath.o): >> relocation R_X86_64_PC32 against `__fvdlog' can not be used when >> making a shared object; recompile with -fPIC >> /usr/bin/ld: final link failed: Bad value >> make[4]: *** [R_X11.so] Error 2 >> make[4]: Leaving directory `/home/cuser/R-devel/src/modules/X11' >> make[3]: *** [R] Error 2 >> make[3]: Leaving directory `/home/cuser/R-devel/src/modules/X11' >> make[2]: *** [R] Error 1 >> make[2]: Leaving directory `/home/cuser/R-devel/src/modules' >> make[1]: *** [R] Error 1 >> make[1]: Leaving directory `/home/cuser/R-devel/src' >> make: *** [R] Error 1 >> >> Though src/main directory compiled successfully, I do still get >> warning messages from src/main/regex.c compilation. >> PGC-W-0155-64-bit integral value truncated (/usr/include/wctype.h: 109) >> PGC-W-0155-64-bit integral value truncated (/usr/i
Re: [Rd] compile R with Portland Group compiler
Thank you for the report. /* */ is standard C. simpleaffy is not a CRAN package: we test those with enough flags (-Wall -pedantic) that the use of // is flagged and would get reported to the maintainer/submitter. On Tue, 30 Aug 2005, Jennifer Lai wrote: > Hi, > After getting some help from Portland Group, I was able to pass the > initial stage of building R with Portland Group Compiler on AMD Opeteron. > > For anyone who is interested in building R with PG compiler, here is a list > of set flags used in config.site, > CC=/usr/pgi/linux86-64/6.0/bin/pgcc > CFLAGS='-g -O2 -mieee-fp' > CPPFLAGS='-I/usr/pgi/linux86-64/6.0/include > -I/usr/pgi/linux86-64/6.0/include/CC' > F77=/usr/pgi/linux86-64/6.0/bin/pgf77 > FFLAGS=-O2 > CPICFLAGS=-fpic > FPICFLAGS=-fpic > SHLIB_LDFLAGS=-shared > LDFLAGS='-L/usr/pgi/linux86-64/6.0/libso -L/usr/lib64' > CXX=/usr/pgi/linux86-64/6.0/bin/pgCC > CXXPICFLAGS=-fpic > SHLIB_CXXLDFLAGS=-shared > > After installing R, I went ahead to install simpleaffy package. However, came > across the following errors. > > PGC-S-0035-Syntax error: Recovery attempted by replacing '/' by double > 0.0E+0 (simpleaffy.c: 455) > PGC-S-0035-Syntax error: Recovery attempted by replacing identifier by by > '!=' (simpleaffy.c: 455) > PGC-S-0035-Syntax error: Recovery attempted by replacing integer 15 by '!=' > (simpleaffy.c: 455) > PGC-S-0039-Use of undeclared variable added (simpleaffy.c: 455) > PGC-S-0037-Syntax error: Recovery attempted by deleting identifier march > (simpleaffy.c: 455) > PGC-S-0039-Use of undeclared variable Crispin (simpleaffy.c: 455) > PGC-S-0035-Syntax error: Recovery attempted by replacing identifier with by > '!=' (simpleaffy.c: 455) > PGC-S-0035-Syntax error: Recovery attempted by replacing identifier in by > '!=' (simpleaffy.c: 455) > PGC-S-0039-Use of undeclared variable deals (simpleaffy.c: 455) > PGC-S-0035-Syntax error: Recovery attempted by replacing identifier largest > by '!=' (simpleaffy.c: 455) > PGC-S-0039-Use of undeclared variable ties (simpleaffy.c: 455) > PGC-S-0035-Syntax error: Recovery attempted by replacing '...' by ',' > (simpleaffy.c: 455) > PGC-S-0039-Use of undeclared variable the (simpleaffy.c: 455) > PGC-S-0039-Use of undeclared variable ranks (simpleaffy.c: 455) > PGC/x86-64 Linux/x86-64 6.0-5: compilation completed with severe errors > make: *** [simpleaffy.o] Error 2 > ERROR: compilation failed for package 'simpleaffy' > > Apparently, PG compiler doesn't like "//" style for comments. So, by changing > "//" to "/* */" style fixed above errors. > The commenting style errors also happened in other packages, such as affy. > Since "/* */" comment style is acceptable by both PG Compiler and gcc, it is > probably worthwhile to use "/* */" consistently throughout R packages. > > > Regards, > Jennifer > > Prof Brian Ripley wrote: > >> Let us be clear: some things in config.log are designed to fail, so only >> unexpected errors are a cause to look there. The regex.c warnings are it >> seems from an over-zealous compiler. >> >> The problems here seem to be the unknown use of .lo (which it seems to have >> coped with) and a problem in the PG's own libc, which it seems cannot be >> used in a shared object. That issue discussed in the R-admin manual, and >> seems something you do need to take up with PG. The crucial part is >> >>> /usr/bin/ld: /usr/pgi/linux86-64/6.0/lib/libpgc.a(fastmath.o): relocation >>> R_X86_64_PC32 against `__fvdlog' can not be used when making a shared >>> object; >>> recompile with -fPIC >> >> >> which is asking you to recompile their static library. If you can't use a >> dynamic library then this is fatal. >> >> >> On Wed, 24 Aug 2005, Jennifer Lai wrote: >> >>> I downloaded R-devel and compiled it with pgcc. This time, instead of >>> breaking in src/main, compilation breaks in src/modules with the following >>> error messages. >>> >>> Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. >>> Copyright 2000-2005, STMicroelectronics, Inc. All Rights Reserved. >>> /usr/pgi/linux86-64/6.0/bin/pgcc -shared -L/usr/pgi/linux86-64/6.0/lib >>> -L/usr/lib64 -o R_X11.so dataentry.lo devX11.lo rotated.lo rbitmap.lo >>> -lSM -lICE -L/usr/X11R6/lib64 -lX11 -ljpeg -lpng -lz >>> File with unknown suffix passed to linker: dataentry.lo >>> File with unknown suffix passed to linker: devX11.lo >>> File with unknown suffix passed to linker: rotated.lo >>> File with unknown suffix passed to linker: rbitmap.lo >>> /usr/bin/ld: /usr/pgi/linux86-64/6.0/lib/libpgc.a(fastmath.o): relocation >>> R_X86_64_PC32 against `__fvdlog' can not be used when making a shared >>> object; recompile with -fPIC >>> /usr/bin/ld: final link failed: Bad value >>> make[4]: *** [R_X11.so] Error 2 >>> make[4]: Leaving directory `/home/cuser/R-devel/src/modules/X11' >>> make[3]: *** [R] Error 2 >>> make[3]: Leaving directory `/home/cuser/R-devel/src/modules/X11' >>> make[2]: *** [R] Error 1 >>> make[2]: Leaving
Re: [Rd] .Call and Segmentation Fault
Hi Simon!
You are right!
Ok, here it is (a little resumed):
#include
#include
#include
#include
#include "interface.h"
SEXP main() {
int gtype, inform, m, n, maxoutit, maxtotit, maxtotfc, outiter,
totcgcnt, totfcnt, totgcnt, totiter, iprint, ncomp, i;
double f,nalpsupn,epsfeas,epsopt,snorm;
int *wi;
int *equatn, *linear;
double *l, *lambda, *rho, *u, *wd1, *wd2, *wd3, *wd4, *wd5, *wd6,
*wd7, *wd8, *wd9, *wd10, *wd11, *wd12, *wd13, *x;
FILE *fileOutput;
clock_t clock;
double time;
struct tms buffer;
/* SOME LINES TO SET UP PROBLEM DATA */
/* SOME LINES TO MEMORY ALLOCATION */
/* SOME LINES TO SET SOME ALGENCAN ARGUMENTS */
/* TRANSFORMS THE TYPE INT OF C IN THE TYPE LOGICAL OF FORTRAN
* FOR THE ARRAYS equatn AND linear */
C2FLOGICALV(equatn, m);
C2FLOGICALV(linear, m);
clock = times(&buffer);
/* CALL OPTIMIZATION PACKAGE */
fortran_optimization_package (n, x, l, u, m, lambda, rho, equatn, linear,
epsfeas,
epsopt, maxoutit, maxtotfc, maxtotit, iprint, ncomp, gtype,
f, snorm, nalpsupn, outiter, totiter, totfcnt, totgcnt,
totcgcnt, inform, wi, wd1, wd2, wd3, wd4, wd5, wd6, wd7,
wd8, wd9, wd10, wd11, wd12, wd13)
return R_NilValue
}
All the variables passed to fortran_optimization_package are allocated an
initialized correctly, that's why I resumed those lines with a comment.
Thanks,
Ricardo
> You still didn't even supply your declaration of the function you're
> calling, so there is not much we can help you with. Hopefully your
> function looks like this:
>
> #include
> #include
>
> SEXP foo() {
>
> [... you code goes here..]
>
> return R_NilValue;
> }
>
> If you're constructing the returned object then you should consider
> posting the whole code, because you're likely making a mistake
> somewhere in that part.
>
> Cheers,
> Simon
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: "loop connections"
Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > Just to be concrete, suppose one wants to run the following as a > concurrent process to R. (What is does is it implicitly sets x to > zero and then for each line of stdin it adds the first field of the > input to x and prints that to stdout unless the first field is > "exit" in which case it exits. gawk has an implicit read/process > loop so one does not have to specify the read step. The fflush() > command just makes sure that output is emitted, rather than > buffered, as it is produced.) It seems you're just trying to reinvent fifo and/or pipe connections for interprocess communication. That is not directly related to the problem I wanted to address. -- Dave __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fwd: segfault
On 29/ago/05, at 10:35, Prof Brian Ripley wrote:
> It does not crash for me on either Windows or Linux, but it does
> take a
> long time and the plot is a mess, so there does seem to be a
> lattice-related problem (maybe a usage one).
>
> However, I think the crash is a Mac (presumably quartz()) problem.
>
no, it also happens with the X11 device. BTW, it seems to be OS X
specific.
I'll try to debug
stefano
> On Mon, 29 Aug 2005, stefano iacus wrote:
>
>
>> This segfaults on OS X (10.4) on both X11 and quartz devices.
>> Seems a problem with lattice but I cannot test on other platforms
>> stefano
>>
>>
>> Begin forwarded message:
>>
>>
>>> From: "G. Sawitzki" <[EMAIL PROTECTED]>
>>> Date: 28 agosto 2005 14:11:18 GMT+02:00
>>> To: [EMAIL PROTECTED]
>>>
>>>
>>> Dear Stefano,
>>>
>>> this small exaple leads to a crash of R. I did not try it on
>>> versions other than the Mac version. So I am sending it to you
>>> directly. If it is a littice problem, could you pass it to Deepayan
>>> Sarkar? Thank you.
>>>
>>> g.
>>>
>>> ==
>>> #pbinom
>>> library(grid)
>>> library(lattice)
>>>
>>> n<-20
>>> psteps<-50
>>> binomtable<- function (n,psteps){
>>> x<-(0:(10*n))/10
>>> p<- (0:psteps)/psteps
>>> dd<-expand.grid(x=x,p=p)
>>> dd$F<- pbinom(dd$x,n,dd$p)
>>> dd$x0<-trunc(dd$x)
>>> dd
>>> }
>>>
>>> bt<-binomtable(n=5,psteps=100)
>>> bt[bt$x-bt$x0>=0.9,]$F<-NA
>>> wireframe(bt$F~bt$x*bt$p,bt,groups=bt$x0,shade=TRUE) # leads to R
>>> crash
>>> #wireframe(bt$F~bt$x*bt$p,bt,shade=TRUE) #ok
>>>
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] .Call and Segmentation Fault
I forgot to put the folowing includes in my last post:
#include
#include
Thanks,
Ricardo
-- Forwarded message --
From: Ricardo Luiz Andrade Abrantes <[EMAIL PROTECTED]>
Date: Aug 30, 2005 1:37 PM
Subject: Re: [Rd] .Call and Segmentation Fault
To: Simon Urbanek <[EMAIL PROTECTED]>, r-devel@r-project.org
Hi Simon!
You are right!
Ok, here it is (a little resumed):
#include
#include
#include
#include
#include "interface.h"
SEXP main() {
int gtype, inform, m, n, maxoutit, maxtotit, maxtotfc, outiter,
totcgcnt, totfcnt, totgcnt, totiter, iprint, ncomp, i;
double f,nalpsupn,epsfeas,epsopt,snorm;
int *wi;
int *equatn, *linear;
double *l, *lambda, *rho, *u, *wd1, *wd2, *wd3, *wd4, *wd5, *wd6,
*wd7, *wd8, *wd9, *wd10, *wd11, *wd12, *wd13, *x;
FILE *fileOutput;
clock_t clock;
double time;
struct tms buffer;
/* SOME LINES TO SET UP PROBLEM DATA */
/* SOME LINES TO MEMORY ALLOCATION */
/* SOME LINES TO SET SOME ALGENCAN ARGUMENTS */
/* TRANSFORMS THE TYPE INT OF C IN THE TYPE LOGICAL OF FORTRAN
* FOR THE ARRAYS equatn AND linear */
C2FLOGICALV(equatn, m);
C2FLOGICALV(linear, m);
clock = times(&buffer);
/* CALL OPTIMIZATION PACKAGE */
fortran_optimization_package (n, x, l, u, m, lambda, rho, equatn, linear,
epsfeas,
epsopt, maxoutit, maxtotfc, maxtotit, iprint, ncomp, gtype,
f, snorm, nalpsupn, outiter, totiter, totfcnt, totgcnt,
totcgcnt, inform, wi, wd1, wd2, wd3, wd4, wd5, wd6, wd7,
wd8, wd9, wd10, wd11, wd12, wd13)
return R_NilValue
}
All the variables passed to fortran_optimization_package are allocated an
initialized correctly, that's why I resumed those lines with a comment.
Thanks,
Ricardo
> You still didn't even supply your declaration of the function you're
> calling, so there is not much we can help you with. Hopefully your
> function looks like this:
>
> #include
> #include
>
> SEXP foo() {
>
> [... you code goes here..]
>
> return R_NilValue;
> }
>
> If you're constructing the returned object then you should consider
> posting the whole code, because you're likely making a mistake
> somewhere in that part.
>
> Cheers,
> Simon
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Call and Segmentation Fault
Hello to everybody! After reading all the C code, checking for problems, and find nothing, I decided something a little bit different... If my ".so" library works in a wrog way in R it should do the same in C. So I created a C program that loads my library file and the executes the same function R is executing. The program worked perfectly! In fact I changed two things in my library: The function I call now return an int, not a SEXP, and the return value is 0 not R_NilValue. Valgrind's output is ok too... If .Call has no problems, and if my function works perfect when called from a C program, where the problem lies? Why my program becomes "crazy" when I run it from R? I would apreciate very much your help! I don't where else I could find help on this. I can provide any piece of code that may help, Its just ask! Thanks, Ricardo On 8/28/05, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > > On Sat, 27 Aug 2005, Ricardo Luiz Andrade Abrantes wrote: > > > Hi! > > Yes, I am returning a SEXP from the functions called from R, and the > > problem occurs before (thousands of iterations before) the return > > point. > > In fact I runned valgrind into R and when I call ".Call(...) " I got > > many errors like: > > ==4324== Use of uninitialised value of size 8 > > ==4324== at 0x1CB0766D: tnls_ (gencan.f:4101) > > ==4324== by 0x1CB01962: gencan_ (gencan.f:1876) > > ==4324== by 0x1CAFECA5: easygencan_ (gencan.f:440) > > ==4324== by 0x1CB0B47D: algencan_ (algencan.f:517) > > ==4324== by 0x1CB09E74: easyalgencan_ (algencan.f:76) > > ==4324== by 0x1CAFE5B3: main (algencanma.c:808) > > what does not happens when I compile the algencanma as a regular > > program (not a library) and run it from shell. Valgrind does not find > > anything wrong when I run the program directly, except 2 missing > > free() calls. > > Do you have any ideas where the problem lies (R .Call function or C > program)? > > It cannot be .Call: your .Call passed no parameters so there was nothing > to be uninitialized. I did ask you why you were doing that. > > .Call is very heavily tested in lots of R applications, so the prior > probability of innocence must be very high. > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UK Fax: +44 1865 272595 > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Call and Segmentation Fault
Ricardo Luiz Andrade Abrantes <[EMAIL PROTECTED]> writes: > Hello to everybody! > After reading all the C code, checking for problems, and find nothing, I > decided something a little bit different... > If my ".so" library works in a wrog way in R it should do the same in C. So > I created a C program that loads my library file and the executes the same > function R is executing. > The program worked perfectly! In fact I changed two things in my library: > The function I call now return an int, not a SEXP, and the return value is 0 > not R_NilValue. > Valgrind's output is ok too... > If .Call has no problems, and if my function works perfect when called from > a C program, where the problem lies? Why my program becomes "crazy" when I > run it from R? > I would apreciate very much your help! I don't where else I could find help > on this. Well, did you try running under a debugger? R -d gdb then "bt" after the segfault. (Make sure that things are compiled with -g option) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 64 bit R for Windows
I am assisting in the purchase of 64-bit Windows XP system for researchers who run R. These systems will have AMD Opteron processors and at least 4GB of RAM. I'd appreciate advice on whether there is a working version of R that can take full advantage of such systems. Milton F. López IT Guy Inter-American Tuna Commission (IATTC) 8604 La Jolla Shores Drive La Jolla, CA 92037 Tel: (858) 546-7041, Fax: (858) 546-7133 email: [EMAIL PROTECTED] Web: http://www.iattc.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Call and Segmentation Fault
On Tue, 31 Aug 2005, Peter Dalgaard wrote: > Well, did you try running under a debugger? > > R -d gdb > > then "bt" after the segfault. (Make sure that things are compiled with > -g option) It would also be worth renaming the the function -- while I don't see exactly how it could be causing the problem, I would be nervous about having a C function called main() that wasn't the real main(). -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 64 bit R for Windows
Milton Lopez wrote: > I am assisting in the purchase of 64-bit Windows XP system for researchers > who run R. These systems will have AMD Opteron processors and at least 4GB of > RAM. I'd appreciate advice on whether there is a working version of R that > can take full advantage of such systems. No, there are no 64 bit Windows versions yet. You'll need to install some 64 bit version of Linux on those machines to take full advantage of the chips. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] pf hangs with infinite arguments (PR#8110)
Full_Name: Rob Hyndman Version: 2.1.1 OS: Windows Submission from: (NULL) (202.7.176.132) pf(Inf,x,Inf) causes R to hang up for any value of x. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pf hangs with infinite arguments (PR#8110)
Which x? Not for 1, 10, Inf for example. I did manage to make pf(Inf, 5, Inf) hang, but not under R-patched or R-devel. It seems this is already fixed (please see the reporting conditions in the FAQ or in the posting guide). pf(Inf, n1, Inf) is the same code as pchisq(Inf, n1) and pgamma(Inf, n1/2) The latter seems to be the same as PR#8001, as in the NEWS item o pgamma(Inf, 1.1) did not terminate (PR#8001). Please reopen this if you can reproduce it in R-devel (soon to become 2.2.0) or R-patched. On Wed, 31 Aug 2005 [EMAIL PROTECTED] wrote: > Full_Name: Rob Hyndman > Version: 2.1.1 > OS: Windows > Submission from: (NULL) (202.7.176.132) > > > pf(Inf,x,Inf) causes R to hang up for any value of x. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
