Re: [Rd] Problem with rnorm ?
> #include
> #include
>
> int main(void){
> double x[3];
> for(int i=0;i<3;i++) x[i]=rnorm(0,1);
> printf("%lf,%lf,%lf",x[0],x[1],x[2]);
> return 0;
> }
>
> output : -8.773321,-8.773321,-8.773321
You probably have to call GetRNGstate() before rnorm and PutRNGstate() after.
At least for extension packages, this is necessary, see section 6.3 in
R-exts.pdf.
Petr.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with rnorm ?
1) You are linking an executable against -lR. You can't do that as here,
for R is never initialized (and I very much doubt you will be able to
give a reference that recommended you to do that). You need to link
against standalone libRmath, or start up R properly if you really need R.
2) The arguments to rnorm() are doubles, not integers: did you not get a
warning? I would expect automatic conversion to occur, but it is better
to get this right.
On Fri, 11 May 2007, Tong Wang wrote:
> Hi,
>I couldn't get the rnorm() work right in C, for example, the following
> code produce strange results.
>
> #include
> #include
>
> int main(void){
> double x[3];
> for(int i=0;i<3;i++) x[i]=rnorm(0,1);
> printf("%lf,%lf,%lf",x[0],x[1],x[2]);
> return 0;
> }
>
> output : -8.773321,-8.773321,-8.773321
> compiling script: gcc -std=gnu99 -Wall -IC:/PROGRA~1/R/R-24~1.1/include
> test.c -LC:/PROGRA~1/R/R-24~1.1/bin -lR -o test
>
> Could someone tell me what's wrong with my code ? Thanks a lot.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
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
[Rd] Implicit vs explicit printing and the call stack
Hi everyone,
I've run into a bit of strange problem with implicit vs explicit
printing and the call stack. I've included an example at the bottom of
this email. The basic problem is that I have an S3 object with a
print method. When the object is implicitly printed (ie. typed
directly into the console) the function arguments in the call stack
are exploded out to their actual values, rather than just the name I
typed in (see below for an example if my language is confusing). When
I explicitly "print" the object, the call stack is fine.
This is not just of academic interest, because with a larger dataset
and an implicit print, there is a noticeable delay before control
returns to the prompt (I can't quantify it exactly because
system.time requires a explicit print, but it's on the order of a few
seconds).
I'm not sure if I've provided enough information to be able to solve
the problem, so please let me know what additional details would be
useful.
Thanks,
Hadley
> ggplot(mtcars, aes(x=cyl, y=-mpg)) + scale_y_log10() + geom_point()
Error in grid.pretty(.$domain()) : infinite axis extents [GEPretty(-inf,inf,5)]
In addition: Warning messages:
1: NaNs produced in: log(x, base)
2: no non-missing arguments to min; returning Inf
3: no non-missing arguments to max; returning -Inf
4: no non-missing arguments to min; returning Inf
5: no non-missing arguments to max; returning -Inf
> traceback()
16: .Call(L_pretty, range)
15: grid.pretty(.$domain())
14: get("breaks", env = .$y(), inherits = TRUE)(.$y(), ...)
13: .$y()$breaks()
12: range(at)
11: as.numeric(x)
10: unit(range(at), "native")
9: ggaxis_line(at, position)
8: ggaxis(.$y()$breaks(), .$y()$labels(), "left", range$y)
7: get("guide_axes", env = coordinates, inherits = TRUE)(coordinates,
...)
6: coordinates$guide_axes()
5: guides_basic(plot, scales, cs)
4: ggplot_plot(x, ...)
3: grid.draw(ggplot_plot(x, ...))
2: print.ggplot(list(data = list(mpg = c(21, 21, 22.8, 21.4, 18.7,
18.1, 14.3, 24.4, 22.8, 19.2, 17.8, 16.4, 17.3, 15.2, 10.4, 10.4,
14.7, 32.4, 30.4, 33.9, 21.5, 15.5, 15.2, 13.3, 19.2, 27.3, 26,
30.4, 15.8, 19.7, 15, 21.4), cyl = c(6, 6, 4, 6, 8, 6, 8, 4,
4, 6, 6, 8, 8, 8, 8, 8, 8, 4, 4, 4, 4, 8, 8, 8, 8, 4, 4, 4, 8,
6, 8, 4), disp = c(160, 160, 108, 258, 360, 225, 360, 146.7,
140.8, 167.6, 167.6, 275.8, 275.8, 275.8, 472, 460, 440, 78.7,
75.7, 71.1, 120.1, 318, 304, 350, 400, 79, 120.3, 95.1, 351,
145, 301, 121), hp = c(110, 110, 93, 110, 175, 105, 245, 62,
95, 123, 123, 180, 180, 180, 205, 215, 230, 66, 52, 65, 97, 150,
150, 245, 175, 66, 91, 113, 264, 175, 335, 109), drat = c(3.9,
3.9, 3.85, 3.08, 3.15, 2.76, 3.21, 3.69, 3.92, 3.92, 3.92, 3.07,
3.07, 3.07, 2.93, 3, 3.23, 4.08, 4.93, 4.22, 3.7, 2.76, 3.15,
3.73, 3.08, 4.08, 4.43, 3.77, 4.22, 3.62, 3.54, 4.11), wt = c(2.62,
2.875, 2.32, 3.215, 3.44, 3.46, 3.57, 3.19, 3.15, 3.44, 3.44,
4.07, 3.73, 3.78, 5.25, 5.424, 5.345, 2.2, 1.615, 1.835, 2.465,
3.52, 3.435, 3.84, 3.845, 1.935, 2.14, 1.513, 3.17, 2.77, 3.57,
2.78), qsec = c(16.46, 17.02, 18.61, 19.44, 17.02, 20.22, 15.84,
20, 22.9, 18.3, 18.9, 17.4, 17.6, 18, 17.98, 17.82, 17.42, 19.47,
18.52, 19.9, 20.01, 16.87, 17.3, 15.41, 17.05, 18.9, 16.7, 16.9,
14.5, 15.5, 14.6, 18.6), vs = c(0, 0, 1, 1, 0, 1, 0, 1, 1, 1,
1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 1, 0, 1, 0, 0, 0,
1), am = c(1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
1, 1, 1, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1), gear = c(4, 4,
4, 3, 3, 3, 3, 4, 4, 4, 4, 3, 3, 3, 3, 3, 3, 4, 4, 4, 3, 3, 3,
3, 3, 4, 5, 5, 5, 5, 5, 4), carb = c(4, 4, 1, 1, 2, 1, 4, 2,
2, 4, 4, 3, 3, 3, 4, 4, 4, 1, 2, 1, 1, 2, 2, 4, 2, 1, 2, 2, 4,
6, 8, 2)), layers = list(), scales = ,
defaults = list(x = cyl, y = -mpg), title = NULL, fixedaspect = FALSE,
coordinates = , formula = ". ~ .", margins = FALSE))
1: print(list(data = list(mpg = c(21, 21, 22.8, 21.4, 18.7, 18.1,
14.3, 24.4, 22.8, 19.2, 17.8, 16.4, 17.3, 15.2, 10.4, 10.4, 14.7,
32.4, 30.4, 33.9, 21.5, 15.5, 15.2, 13.3, 19.2, 27.3, 26, 30.4,
15.8, 19.7, 15, 21.4), cyl = c(6, 6, 4, 6, 8, 6, 8, 4, 4, 6,
6, 8, 8, 8, 8, 8, 8, 4, 4, 4, 4, 8, 8, 8, 8, 4, 4, 4, 8, 6, 8,
4), disp = c(160, 160, 108, 258, 360, 225, 360, 146.7, 140.8,
167.6, 167.6, 275.8, 275.8, 275.8, 472, 460, 440, 78.7, 75.7,
71.1, 120.1, 318, 304, 350, 400, 79, 120.3, 95.1, 351, 145, 301,
121), hp = c(110, 110, 93, 110, 175, 105, 245, 62, 95, 123, 123,
180, 180, 180, 205, 215, 230, 66, 52, 65, 97, 150, 150, 245,
175, 66, 91, 113, 264, 175, 335, 109), drat = c(3.9, 3.9, 3.85,
3.08, 3.15, 2.76, 3.21, 3.69, 3.92, 3.92, 3.92, 3.07, 3.07, 3.07,
2.93, 3, 3.23, 4.08, 4.93, 4.22, 3.7, 2.76, 3.15, 3.73, 3.08,
4.08, 4.43, 3.77, 4.22, 3.62, 3.54, 4.11), wt = c(2.62, 2.875,
2.32, 3.215, 3.44, 3.46, 3.57, 3.19, 3.15, 3.44, 3.44, 4.07,
3.73, 3.78, 5.25, 5.424, 5.345, 2.2, 1.615, 1.835, 2.465, 3.52,
3.435, 3.84, 3.845, 1.935, 2.14, 1.513, 3.17, 2.77, 3.57, 2.78
Re: [Rd] Implicit vs explicit printing and the call stack
I can't reproduce that with ggplot 0.4-0 as some of the functions you are
using do not appear to be part of ggplot (I suspect you are using a newer
version of ggplot than you have released) but the following illustrates
the difference using "R version 2.5.0 Patched (2007-05-01 r41405)"
and lattice 0.15-5 and grid 2.5-0 on Windows XP:
library(lattice)
xyplot(conc ~ uptake, CO2, xlim = Inf)
traceback()
print(xyplot(conc ~ uptake, CO2, xlim = Inf))
traceback()
On 5/12/07, hadley wickham <[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> I've run into a bit of strange problem with implicit vs explicit
> printing and the call stack. I've included an example at the bottom of
> this email. The basic problem is that I have an S3 object with a
> print method. When the object is implicitly printed (ie. typed
> directly into the console) the function arguments in the call stack
> are exploded out to their actual values, rather than just the name I
> typed in (see below for an example if my language is confusing). When
> I explicitly "print" the object, the call stack is fine.
>
> This is not just of academic interest, because with a larger dataset
> and an implicit print, there is a noticeable delay before control
> returns to the prompt (I can't quantify it exactly because
> system.time requires a explicit print, but it's on the order of a few
> seconds).
>
> I'm not sure if I've provided enough information to be able to solve
> the problem, so please let me know what additional details would be
> useful.
>
> Thanks,
>
> Hadley
>
>
> > ggplot(mtcars, aes(x=cyl, y=-mpg)) + scale_y_log10() + geom_point()
> Error in grid.pretty(.$domain()) : infinite axis extents
> [GEPretty(-inf,inf,5)]
> In addition: Warning messages:
> 1: NaNs produced in: log(x, base)
> 2: no non-missing arguments to min; returning Inf
> 3: no non-missing arguments to max; returning -Inf
> 4: no non-missing arguments to min; returning Inf
> 5: no non-missing arguments to max; returning -Inf
> > traceback()
> 16: .Call(L_pretty, range)
> 15: grid.pretty(.$domain())
> 14: get("breaks", env = .$y(), inherits = TRUE)(.$y(), ...)
> 13: .$y()$breaks()
> 12: range(at)
> 11: as.numeric(x)
> 10: unit(range(at), "native")
> 9: ggaxis_line(at, position)
> 8: ggaxis(.$y()$breaks(), .$y()$labels(), "left", range$y)
> 7: get("guide_axes", env = coordinates, inherits = TRUE)(coordinates,
> ...)
> 6: coordinates$guide_axes()
> 5: guides_basic(plot, scales, cs)
> 4: ggplot_plot(x, ...)
> 3: grid.draw(ggplot_plot(x, ...))
> 2: print.ggplot(list(data = list(mpg = c(21, 21, 22.8, 21.4, 18.7,
> 18.1, 14.3, 24.4, 22.8, 19.2, 17.8, 16.4, 17.3, 15.2, 10.4, 10.4,
> 14.7, 32.4, 30.4, 33.9, 21.5, 15.5, 15.2, 13.3, 19.2, 27.3, 26,
> 30.4, 15.8, 19.7, 15, 21.4), cyl = c(6, 6, 4, 6, 8, 6, 8, 4,
> 4, 6, 6, 8, 8, 8, 8, 8, 8, 4, 4, 4, 4, 8, 8, 8, 8, 4, 4, 4, 8,
> 6, 8, 4), disp = c(160, 160, 108, 258, 360, 225, 360, 146.7,
> 140.8, 167.6, 167.6, 275.8, 275.8, 275.8, 472, 460, 440, 78.7,
> 75.7, 71.1, 120.1, 318, 304, 350, 400, 79, 120.3, 95.1, 351,
> 145, 301, 121), hp = c(110, 110, 93, 110, 175, 105, 245, 62,
> 95, 123, 123, 180, 180, 180, 205, 215, 230, 66, 52, 65, 97, 150,
> 150, 245, 175, 66, 91, 113, 264, 175, 335, 109), drat = c(3.9,
> 3.9, 3.85, 3.08, 3.15, 2.76, 3.21, 3.69, 3.92, 3.92, 3.92, 3.07,
> 3.07, 3.07, 2.93, 3, 3.23, 4.08, 4.93, 4.22, 3.7, 2.76, 3.15,
> 3.73, 3.08, 4.08, 4.43, 3.77, 4.22, 3.62, 3.54, 4.11), wt = c(2.62,
> 2.875, 2.32, 3.215, 3.44, 3.46, 3.57, 3.19, 3.15, 3.44, 3.44,
> 4.07, 3.73, 3.78, 5.25, 5.424, 5.345, 2.2, 1.615, 1.835, 2.465,
> 3.52, 3.435, 3.84, 3.845, 1.935, 2.14, 1.513, 3.17, 2.77, 3.57,
> 2.78), qsec = c(16.46, 17.02, 18.61, 19.44, 17.02, 20.22, 15.84,
> 20, 22.9, 18.3, 18.9, 17.4, 17.6, 18, 17.98, 17.82, 17.42, 19.47,
> 18.52, 19.9, 20.01, 16.87, 17.3, 15.41, 17.05, 18.9, 16.7, 16.9,
> 14.5, 15.5, 14.6, 18.6), vs = c(0, 0, 1, 1, 0, 1, 0, 1, 1, 1,
> 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 1, 0, 1, 0, 0, 0,
> 1), am = c(1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 1, 1, 1, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1), gear = c(4, 4,
> 4, 3, 3, 3, 3, 4, 4, 4, 4, 3, 3, 3, 3, 3, 3, 4, 4, 4, 3, 3, 3,
> 3, 3, 4, 5, 5, 5, 5, 5, 4), carb = c(4, 4, 1, 1, 2, 1, 4, 2,
> 2, 4, 4, 3, 3, 3, 4, 4, 4, 1, 2, 1, 1, 2, 2, 4, 2, 1, 2, 2, 4,
> 6, 8, 2)), layers = list(), scales = ,
> defaults = list(x = cyl, y = -mpg), title = NULL, fixedaspect = FALSE,
> coordinates = , formula = ". ~ .", margins = FALSE))
> 1: print(list(data = list(mpg = c(21, 21, 22.8, 21.4, 18.7, 18.1,
> 14.3, 24.4, 22.8, 19.2, 17.8, 16.4, 17.3, 15.2, 10.4, 10.4, 14.7,
> 32.4, 30.4, 33.9, 21.5, 15.5, 15.2, 13.3, 19.2, 27.3, 26, 30.4,
> 15.8, 19.7, 15, 21.4), cyl = c(6, 6, 4, 6, 8, 6, 8, 4, 4, 6,
> 6, 8, 8, 8, 8, 8, 8, 4, 4, 4, 4, 8, 8, 8, 8, 4, 4, 4, 8, 6, 8,
> 4), disp = c(160, 160, 108, 258, 360, 225, 360, 146.7, 140.8,
> 167.6, 167.6, 275.8, 275.8, 275.8, 472, 460, 440, 78.7, 75.7,
> 71.1, 1
[Rd] The best way to use R's linear algebra functions from C
First of all, thanks to everybody for R. I have written a program in C that requires some basic matrix operations, namely the following: - matrix multiplication and addition, - determinant and transpose, - inverse of a symmetric matrix. Since I am a happy R user I thought I could call R from within my program for this purpose. I read "Writing R Extensions" and "R Internals" and a bunch of other things from the web, ran the "Embedded" tests, and grep'ed / looked at the source code. It is now my understanding that there are several ways I could use R from C: 1. Pass data from C to an R function, loaded during R runtime; 2. Build R statements and use Rparse.h to execute them; 3. Use Rembedded.h to call R's C functions; 4. Directly call R's C functions. 4) would be the fastest (I think?), and speed is some concern. However, I am finding it very tough going to discover how to implement this. For example: given two matrices represented as arrays of doubles and their numbers of rows and columns in C, which function in the R code should I call to multiply them (matprod and co. are not exported)? Which headers should I include? Should I link against a library, and if so, which one? Currently I am leaning towards a very roundabout solution: copy the double arrays into SEXPs, use Rembedded.h and load the required formulas from a .R file. This solution seems rather hacky and slow to me, but it is the only one I can get to work right now. However, I would rather not use it. In short, my question is: what is the proper or preferred method of solving this problem, and how do I find out how to apply it? Thank you very much for your attention. Best regards, Daniel Oberski University of Tilburg / European Social Survey [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with rnorm ?
It's working , Thanks a lot !!!
tong
- Original Message -
From: Prof Brian Ripley <[EMAIL PROTECTED]>
Date: Saturday, May 12, 2007 4:27 am
Subject: Re: [Rd] Problem with rnorm ?
To: Tong Wang <[EMAIL PROTECTED]>
Cc: R-devel
> 1) You are linking an executable against -lR. You can't do that as
> here,for R is never initialized (and I very much doubt you will be
> able to
> give a reference that recommended you to do that). You need to
> link
> against standalone libRmath, or start up R properly if you really
> need R.
>
> 2) The arguments to rnorm() are doubles, not integers: did you not
> get a
> warning? I would expect automatic conversion to occur, but it is
> better
> to get this right.
>
> On Fri, 11 May 2007, Tong Wang wrote:
>
> > Hi,
> >I couldn't get the rnorm() work right in C, for example, the
> following code produce strange results.
> >
> > #include
> > #include
> >
> > int main(void){
> > double x[3];
> > for(int i=0;i<3;i++) x[i]=rnorm(0,1);
> > printf("%lf,%lf,%lf",x[0],x[1],x[2]);
> > return 0;
> > }
> >
> > output : -8.773321,-8.773321,-8.773321
> > compiling script: gcc -std=gnu99 -Wall -IC:/PROGRA~1/R/R-
> 24~1.1/include test.c -LC:/PROGRA~1/R/R-24~1.1/bin -lR -o test
> >
> > Could someone tell me what's wrong with my code ? Thanks a lot.
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> 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
[Rd] Strange behavior of debugger
Hi, All:
I had some trouble debugging C source dynamically loaded into R , when I
issued N in gdb(or insight) , the debugger, instead of moving downward step by
step, jumped to strange positions (upward, downward, one step, a few steps
away).
To enter the debugger, I issued gdb(insight) Rgui.exe in Cygwin and add
this line : asm("int $3"); to my C code. After
entering R, I did something like: dyn.load("mypath/mycode.dll") , then out <-
.C("myfun", arg1=as.numeric(a),..)
The C files are compiled with:R CMD SHLIB -d myfile.c
I am using Win XP + Cygwin, and I have a binary version and a cygwin
compiled version of R-2.4.1 installed. This same
behavior show up in both installations. One thing is, even though I set the
evn DEBUG as T when built R from sourse in
Cygwin, the Rgui.exe I got doesn't seem to contain debug info. (although
R.exe does) , I am not sure if this means I did something wrong.
Appreciate any help.
tong
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
