Re: [Rd] Bug in Version 2010 (PR#7807)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--27464147-697381171-1114669841=:21056
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Looks like gettext cannot handle strings with embedded nulls.
I'll remove all such from translation.
On Fri, 22 Apr 2005 [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>
>> Duncan Murdoch wrote:
>>
>>
>>> [EMAIL PROTECTED] wrote:
>>>
>>>
Dr. Michael
Breuer
22.04.05
=D6kologiezentrum der Universit=E4t Kiel
Olshausenstra=DFe 75
24118 Kiel
Dear Ladies and Sirs,
After updating the R-Windows-program (binary) by the latest version
(2010), the R-Scripts that I want to execute are not shown in the
File-Window anymore. In the former version it worked correct.
However, if I call a script by command line, it will be found and
intepreted. I tried it on two PCs wirh Windows XP Home and Windows XP
Professional SP2.
>>>
>>>
>>>
>>> This is not enough information to allow us to try to duplicate your
>>> error. Tell us where you keep your scripts, how you start R (the
>>> starting directory is likely important), and the exact steps you take t=
o
>>> try to show your scripts. Without that information your report is too
>>> vague to act on.
>>>
>>> Duncan Murdoch
>>
>>
>>
>> Looks like it happens with the german (and maybe also other?)
>> translation. I'll take a closer look later.
>>
>> Uwe Ligges
>
> Indeed, if you set LANGUAGE=3Dde using the RGui-de.po as shipped with
> R-2.1.0, you won't see any files in that dialog. If you copy the english
> version to the translation, you see ALL files (not only R files as
> expected), and if you leave the translation blank (i.e. the english
> version will be displayed), you get the expected behaviour.
>
> I guess lines such as
>
> setuserfilter(G_("R files (*.R)\0*.R\0S files (*.q)\0*.q\0All files
> (*.*)\0*.*\0\0"));
>
> in rui.c are casuing the trouble. "S files (*.q)" never appears in the
> *.po(t) file, so it's probably a gettext related problem, but I really
> don't know how to fix this ...
>
>
> Uwe Ligges
>
> __
> R-devel@stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--=20
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
--27464147-697381171-1114669841=:21056--
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Enhanced version of plot.lm()
On 28 Apr 2005, at 1:30 AM, Martin Maechler wrote:
"PD" == Peter Dalgaard <[EMAIL PROTECTED]>
on 27 Apr 2005 16:54:02 +0200 writes:
PD> Martin Maechler <[EMAIL PROTECTED]> writes:
I'm about to commit the current proposal(s) to R-devel,
**INCLUDING** changing the default from
'which = 1:4' to 'which = c(1:3,5)
and ellicit feedback starting from there.
One thing I think I would like is to use color for the Cook's
contours in the new 4th plot.
PD> Hmm. First try running example(plot.lm) with the modified
function and
PD> tell me which observation has the largest Cook's D. With the
suggested
PD> new 4th plot it is very hard to tell whether obs #49 is
potentially or
PD> actually influential. Plots #1 and #3 are very close to
conveying the
PD> same information though...
I shouldn't be teaching here, and I know that I'm getting into fighted
territory (regression diagnostics; robustness; "The" Truth, etc,etc)
but I believe there is no unique way to define "actually influential"
(hence I don't believe that it's extremely useful to know
exactly which Cook's D is largest).
Partly because there are many statistics that can be derived from a
multiple regression fit all of which are influenced in some way.
AFAIK, all observation-influence measures g(i) are functions of
(r_i, h_{ii}) and the latter are the quantities that "regression
users" should really know {without consulting a text book} and
that are generalizable {e.g. to "linear smoothers" such as
gam()s (for "non-estimated" smoothing parameter)}.
Martin
I agree with Martin. I like the idea of using color (red?) for
the new Cook's contours. People who want (fairly) precise
comparisons of the Cook's statistics can still use the present
plot #4, perhaps as a follow-up to the new plot #5.
It would be possible to label the Cookwise most extreme
points with the actual values (to perhaps 2sig figures, i.e.,
labeling on both sides of such points), but this would add
what I consider is unnecessary clutter to the graph.
John.
John Maindonald email: [EMAIL PROTECTED]
phone : +61 2 (6125)3473fax : +61 2(6125)5549
Centre for Bioinformation Science, Room 1194,
John Dedman Mathematical Sciences Building (Building 27)
Australian National University, Canberra ACT 0200.
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: [Filtered!] Re: [R] postscript (eps) / latex / par(mfg=...) / problem!
On Wed, 2005-04-27 at 23:48 +0100, Dan Bolser wrote:
> On Tue, 26 Apr 2005, Marc Schwartz wrote:
> >So, unless I am missing something and without yet delving further into
> >graphic device specific source code, I suspect that there is a problem
> >when creating PS/EPS/PDF files in conjunction with par("mfg").
>
> Yup! I created a bug so hopefully its safely logged (described) now?
OK. I just posted a follow up to your bug report with a link to my post
on r-devel to provide further info and sample graphic files.
I suspect we'll need help from R Core on this one. If this is confirmed
as a bug, this is getting to the periphery of my low level graphic
device knowledge.
Marc
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Re: postscript (eps) / latex / par(mfg=...) / problem! (PR#7820)
Just for the sake of linkage and further information, a related post to this bug is on r-devel at: https://stat.ethz.ch/pipermail/r-devel/2005-April/033016.html Marc Schwartz __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Re: [Filtered!] Re: [R] postscript (eps) / latex / par(mfg=...) / problem!
On Tue, 26 Apr 2005, Marc Schwartz wrote:
>Warning: This message has had one or more attachments removed
>Warning: (x.mfg.eps).
>Warning: Please read the "FilterNotice.txt" attachment(s) for more information.
>
>[MOVED TO R-DEVEL]
>
>On Tue, 2005-04-26 at 18:05 +0100, Dan Bolser wrote:
>> Should I post this to 'bugs'?
>
>Dan,
>
>I suspect part of the problem here is that your code and example were
>difficult to replicate and there may have been a focus on the page
>rotation issue, which I think is a red herring here.
>
>All below is done with Version 2.1.0 Patched (2005-04-20), which is more
>recent of course and may reflect an existing problem when using par
>("mfg").
>
>
>mat <- matrix(c(1:14, 16, 20, 23, 24, 26, 28,
> 886, 792, 136, 201, 16, 58, 6,
> 21, 3, 9, 3, 9, 1, 4, 3, 1, 1,
> 1, 1, 1), ncol = 2)
>
>colnames(mat) <- c("CHAINS", "FREQUENCY")
>
># Use either the EPS or PDF creation here
># Naming the output file based upon the use or non-use
># of par("mfg")
>
># Comment the two par("mfg") lines below as appropriate
>
>
>postscript("x.mfg.eps", width = 6, height = 6,
> horizontal = FALSE, onefile = FALSE,
> paper = "special")
>
># pdf("nomfg.pdf", width = 5, height = 6)
>
>par(mfrow= c(2, 1))
>
>par(mfg = c(1, 1))
>par(mar = c(3, 4, 1, 2))
>plot(mat, type = "b")
>
>par(mfg = c(2, 1))
>par(mar = c(4, 4, 0, 2))
>plot(mat, type = "b", log = "y")
>
>dev.off()
>
>
>What I found, if correct, does not reflect rotation issues with the
>graphic, but a problem when using par("mfg"), resulting in both EPS and
>PDF files having a 0 page indication in the resultant file. I have
>attached EPS and PDF files here named based upon using or not using par
>("mfg").
>
>I also used the following LaTeX code to create PS/PDF files as
>appropriate with curious results. Modify the included graphic file name
>as appropriate when using it:
>
>\documentclass{report}
>\usepackage{graphicx}
>\begin{document}
>\begin{figure}
> \centering
> \includegraphics[width=\textwidth]{x.mfg.eps}
> \caption[X]{Hello!}
> \label{xFig}
>\end{figure}
>\end{document}
>
>
>When using latex and dvips with the x.mfg.eps file, the plot is in the
>upper left hand corner of the page, very small. Substituting the
>x.nomfg.eps file, the page looks fine.
>
>
>When using pdflatex with the mfg.pdf file, get the following error:
>
>Error: pdflatex (file mfg.pdf): pdf inclusion: required page does not
>exist <0>
>
> ==> Fatal error occurred, the output PDF file is not finished!
>
>
>Trying to open the mfg.pdf file, I get errors from multiple PDF viewers
>indicating the lack of pages in the file.
>
>Interestingly, when opening the EPS files in gv, it seems to happily
>ignore the 0 page issue and displays the x.mfg.eps file without problem.
>
>
>There are a few other posts in the archive that report problems that
>were presumed to be the usual rotation issues that Ted refers to in his
>reply post on r-help.
>
>However, when reading them:
>
>http://tolstoy.newcastle.edu.au/R/devel/04a/0344.html
>
>http://finzi.psych.upenn.edu/R/Rhelp02a/archive/25436.html
>
>in both cases, par("mfg") is being used, which is common to Dan's
>problem here.
>
>So, unless I am missing something and without yet delving further into
>graphic device specific source code, I suspect that there is a problem
>when creating PS/EPS/PDF files in conjunction with par("mfg").
Yup! I created a bug so hopefully its safely logged (described) now?
Cheers,
Dan.
>
>HTH,
>
>Marc Schwartz
>
>
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RE: [R] Advice for calling a C function
You have the dimensions switched, in
double x [*MATDESC][*OBJ];
so when the dimensions aren't equal you do get odd things.
You might be better off defining functions to index into mat with a pair of
subscripts directly (.C() copies the argument anyway). Come to think of it,
there might be macros/functions for this in Rinternals.h. Then you don't
need to worry about row-major vs column-major order and related issues.
Finally, as this is a C programming question, it should go to R-devel.
Reid Huntsinger
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tyler Smith
Sent: Tuesday, April 26, 2005 11:02 AM
To: R-Help
Subject: [R] Advice for calling a C function
Hi,
I'm having some trouble with a bit of combined C & R code. I'm trying to
write a C function to handle the for loops in a function I'm working on
to calculate a similarity matrix. Jari Oksanen has kindly added the
necessary changes to the vegan package so that I can use the vegdist
function, so this isn't absolutely necessary. However, I'm stubborn and
want to know why Jari's code works and mine doesn't! Other than, of
course, the obvious - one of us knows what their doing and the other
doesn't. I would appreciate any help. What I've done is:
pass a matrix x to my C function, as a double:
.C("gowsim", as.double(mat), as.integer(nrow(mat)), as.integer(ncol(mat)))
Then I try and reconstruct the matrix, in the form of a C array:
#include
#include
#include
void gowsim ( double *mat, int *OBJ, int *MATDESC)
{
double x [*MATDESC][*OBJ];
int i, j, nrow, ncol;
nrow = *OBJ;
ncol = *MATDESC;
/* Rebuild Matrix */
for (j=0; j < ncol; j++) {
for (i=0; i < nrow; i++) {
x[i][j] = *mat;
Rprintf("row %d col %d value %f\n", i, j, x[i][j]);
mat++;
}
}
for (i=0; i< nrow; i++) {
Rprintf("%f %f %f %f\n", x[i][0], x[i][1], x[i][2], x[i][3]);
}
}
The Rprintf statements display what's going on at each step. It looks
for all the world as if the assignments are working properly, but when I
try and print the matrix I get very strange results. If mat is 3x3 or
4x4 everything seems ok. But if mat is not symetrical the resulting x
matrix is very strange. In the case of a 5x4 mat only the first column
works out, and for 3x4 mat the second and third positions in the first
column are replaced by the first and second positions of the last
column. I'm guessing that I've messed up something in my use of
pointers, or perhaps the for loop, but I can't for the life of me figure
out what!! Once I sort this out I'll be calculating the differences
between rows in the x array en route to producing a similarity matrix. I
looked at the vegdist code, which is fancier than this, and manages to
avoid rebuilding the matrix entirely, but it's a bit beyond me.
I'm using WindowsXP, R 2.1.0 (2005-04-18), and the MinGW compiler.
Thanks for your continued patience,
Tyler
--
Tyler Smith
PhD Candidate
Department of Plant Science
McGill University
21,111 Lakeshore Road
Ste. Anne de Bellevue, Quebec
H9X 3V9
CANADA
Tel: 514 398-7851 ext. 8726
Fax: 514 398-7897
[EMAIL PROTECTED]
__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide!
http://www.R-project.org/posting-guide.html
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: (PR#7803) [Rd] print.data.frame(), wrong column names alignement,
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --27464147-733928972-1114633091=:27258 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE I've managed to solve this, but the major problem I had was not R but that= =20 printf was not respecting multi-byte characters in its field widths in Fedora Core 3. It is clear from the C99 standard that field widths are in= =20 characters not bytes. This may occur elsewhere. Similarly, double-width characters in e.g. Chinese will not be accounted=20 for. On Thu, 21 Apr 2005 [EMAIL PROTECTED] wrote: > Hello, > > When a data.frame contains column names with accentued characters > (UTF8 encoded), the alignement of the column names is wrong (extra > spaces inserted). > > For example : > >> Sys.getlocale() > [1] "[EMAIL PROTECTED];LC_NUMERIC=3DC;[EMAIL PROTECTED] o;[EMAIL PROTECTED];[EMAIL PROTECTED];LC_MESSAGES= [EMAIL PROTECTED];LC_PAPER=3DC;LC_NAME=3DC;LC_ADDRESS=3DC;LC_TELEPHONE=3D= C;LC_MEASUREMENT=3DC;LC_IDENTIFICATION=3DC" > >> print (data.frame(=3D1, b=3D2, c=3D3)) # (ok) > b c > 11 2 3 > > >> print (data.frame(=C3=A9=C3=A9=C3=A9=C3=A9=3D1, b=3D2, c=3D3)) # (extra = blanks) > =C3=A9=C3=A9=C3=A9=C3=A9 b c > 11 2 3 > > -- > > This is probably due to fact that the number of white spaces > to insert between the columns is computed using the length > of the column names (in bytes) instead of their width (in > characters), which are different in the example above. > > The problem is the same (extra spaces inserted) with > print.data.frame(..., right =3D FALSE). > > Thanks, > Cyril > > > --please do not edit the information below-- > > Version: > platform =3D i386-pc-linux-gnu > arch =3D i386 > os =3D linux-gnu > system =3D i386, linux-gnu > status =3D > major =3D 2 > minor =3D 1.0 > year =3D 2005 > month =3D 04 > day =3D 18 > language =3D R > > Search Path: > .GlobalEnv, package:methods, package:stats, package:graphics, package:grD= evices, package:utils, package:datasets, Autoloads, package:base --=20 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 --27464147-733928972-1114633091=:27258-- __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] as.data.frame: Error in "names<-.default" (PR#7808)
On Sun, 24 Apr 2005 [EMAIL PROTECTED] wrote:
[...]
>> f <- function(x) deparse(substitute(x))
>> f(FUN(x1[1:3,,], x2=c("a","b"), x3=c("a", "b"), x4=c("a", "b")))
> [1] "FUN(x1[1:3, , ], x2 = c(\"a\", \"b\"), x3 = c(\"a\", \"b\"), x4 =
> c(\"a\", "
> [2] "\"b\"))"
>
>
> which is caused by deparse() chopping up the expression. The fix would be
> to set the width.cutoff argument to something large. Here's a proposed
> patch:
[...]
> (I used width.cutoff=500, as ?deparse says that the max. I'd imagine the
> number of characters allowed for valid symbol names in R is probably lower
> than that?)
This is an expression, and can be arbitrarily long. So one needs to do
things like terms.formula:
else paste(deparse(form[[2]]), collapse = "")
or just use the initial part (as done elsewhere).
It's fixed in R-patched now.
--
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@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Enhanced version of plot.lm()
> "PD" == Peter Dalgaard <[EMAIL PROTECTED]>
> on 27 Apr 2005 16:54:02 +0200 writes:
PD> Martin Maechler <[EMAIL PROTECTED]> writes:
>> I'm about to commit the current proposal(s) to R-devel,
>> **INCLUDING** changing the default from
>> 'which = 1:4' to 'which = c(1:3,5)
>>
>> and ellicit feedback starting from there.
>>
>> One thing I think I would like is to use color for the Cook's
>> contours in the new 4th plot.
PD> Hmm. First try running example(plot.lm) with the modified function and
PD> tell me which observation has the largest Cook's D. With the suggested
PD> new 4th plot it is very hard to tell whether obs #49 is potentially or
PD> actually influential. Plots #1 and #3 are very close to conveying the
PD> same information though...
I shouldn't be teaching here, and I know that I'm getting into fighted
territory (regression diagnostics; robustness; "The" Truth, etc,etc)
but I believe there is no unique way to define "actually influential"
(hence I don't believe that it's extremely useful to know
exactly which Cook's D is largest).
Partly because there are many statistics that can be derived from a
multiple regression fit all of which are influenced in some way.
AFAIK, all observation-influence measures g(i) are functions of
(r_i, h_{ii}) and the latter are the quantities that "regression
users" should really know {without consulting a text book} and
that are generalizable {e.g. to "linear smoothers" such as
gam()s (for "non-estimated" smoothing parameter)}.
Martin
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Enhanced version of plot.lm()
Martin Maechler <[EMAIL PROTECTED]> writes: > I'm about to commit the current proposal(s) to R-devel, > **INCLUDING** changing the default from > 'which = 1:4' to 'which = c(1:3,5) > > and ellicit feedback starting from there. > > One thing I think I would like is to use color for the Cook's > contours in the new 4th plot. Hmm. First try running example(plot.lm) with the modified function and tell me which observation has the largest Cook's D. With the suggested new 4th plot it is very hard to tell whether obs #49 is potentially or actually influential. Plots #1 and #3 are very close to conveying the same information though... -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
SOLVED RE: [Rd] Problems compiling C code on windows
Thanks all replies,
I followed your advice. From readme.package I installed Rtools and Mingw,
set them in front of my path and now everything is running.
Thanks very much!
> -Original Message-
> From: Uwe Ligges [mailto:[EMAIL PROTECTED]
> Sent: 27 April 2005 14:59
> To: Victor Trevino
> Cc: r-devel@stat.math.ethz.ch
> Subject: Re: [Rd] Problems compiling C code on windows
>
> Victor Trevino wrote:
>
> > Hi all,
> >
> >
> >
> > I can't get my C routines running on a windows box. I have no problems
> at
> > all in Linux.
> >
> >
> >
> > On windows, I have installed cygwin and the compilation works well but
> once
> > I execute "dyn.load(.)" it hangs whatever I use C/C++ interfaces.
>
>
> cygwin is not supported. Please read the manuals on how to set upo a
> working environment under Windows.
>
> Uwe Ligges
>
>
>
> >
> >
> > In Linux it works wonderful but I need to get this code running on
> windows
> > boxes.
> >
> > I know that the problem should be something with the dll
> generation/linkage
> > in windows but I can't figure out.
> >
> >
> >
> > As a matter of test I did the following C code:
> >
> >
> >
> > #include
> >
> > #include
> >
> > SEXP thisisatest(SEXP);
> >
> > SEXP thisisatest(SEXP a)
> >
> > {
> >
> > long int i;
> >
> > if (!isReal(a)) printf("Vector should be double.\n");
> >
> > for (i=LENGTH(a)-1; i >=0; i--) {
> >
> > REAL(a)[i] = REAL(a)[i] + 1;
> >
> > }
> >
> > return (a);
> >
> > }
> >
> >
> >
> >
> >
> >
> >
> > Linux output:
> >
> > R CMD SHLIB thisisthetest.c
> >
> > gcc -I/usr/lib/R/include -I/usr/local/include -D__NO_MATH_INLINES -
> mieee-fp
> > -fPIC -O2 -g -pipe -march=i386 -mcpu=i686 -c thisisthetest.c -o
> > thisisthetest.o
> >
> > g++ -shared -L/usr/local/lib -o thisisthetest.so thisisthetest.o
> >
> >
> >
> > In R:
> >
> >
> >>dyn.load("thisisthetest.so")
> >
> >
> >>.Call("thisisatest",5)
> >
> >
> > [1] 6
> >
> >
> >
> > [[ WONDERFUL ]]
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Windows output:
> >
> > L:\R>Rcmd SHLIB thisisthetest.c
> >
> > making thisisthetest.d from thisisthetest.c
> >
> > gcc -IC:/PROGRA~1/R/rw2001/include -Wall -O2 -c thisisthetest.c -o
> > thisisthetest.o
> >
> > ar cr thisisthetest.a thisisthetest.o
> >
> > ranlib thisisthetest.a
> >
> > gcc --shared -s -o thisisthetest.dll thisisthetest.def thisisthetest.a
> > -LC:/PROGRA~1/R/rw2001/src/gnuwin32 -lg2c -lR
> >
> >
> >
> > In R:
> >
> >
> >>dyn.load("thisisthetest.dll")
> >
> >
> > [[ IT HANGS ]]
> >
> >
> >
> >
> >
> >
> >
> > I have tried different combinations in paths (for library search) and
> > compiling inside cygwin. no success.
> >
> >
> >
> > Any comments are very very very welcome.
> >
> >
> >
> >
> >
> > Thanks !
> >
> >
> >
> >
> >
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@stat.math.ethz.ch mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems compiling C code on windows
Victor Trevino wrote:
Hi all,
I can't get my C routines running on a windows box. I have no problems at
all in Linux.
On windows, I have installed cygwin and the compilation works well but once
I execute "dyn.load(.)" it hangs whatever I use C/C++ interfaces.
cygwin is not supported. Please read the manuals on how to set upo a
working environment under Windows.
Uwe Ligges
In Linux it works wonderful but I need to get this code running on windows
boxes.
I know that the problem should be something with the dll generation/linkage
in windows but I can't figure out.
As a matter of test I did the following C code:
#include
#include
SEXP thisisatest(SEXP);
SEXP thisisatest(SEXP a)
{
long int i;
if (!isReal(a)) printf("Vector should be double.\n");
for (i=LENGTH(a)-1; i >=0; i--) {
REAL(a)[i] = REAL(a)[i] + 1;
}
return (a);
}
Linux output:
R CMD SHLIB thisisthetest.c
gcc -I/usr/lib/R/include -I/usr/local/include -D__NO_MATH_INLINES -mieee-fp
-fPIC -O2 -g -pipe -march=i386 -mcpu=i686 -c thisisthetest.c -o
thisisthetest.o
g++ -shared -L/usr/local/lib -o thisisthetest.so thisisthetest.o
In R:
dyn.load("thisisthetest.so")
.Call("thisisatest",5)
[1] 6
[[ WONDERFUL ]]
Windows output:
L:\R>Rcmd SHLIB thisisthetest.c
making thisisthetest.d from thisisthetest.c
gcc -IC:/PROGRA~1/R/rw2001/include -Wall -O2 -c thisisthetest.c -o
thisisthetest.o
ar cr thisisthetest.a thisisthetest.o
ranlib thisisthetest.a
gcc --shared -s -o thisisthetest.dll thisisthetest.def thisisthetest.a
-LC:/PROGRA~1/R/rw2001/src/gnuwin32 -lg2c -lR
In R:
dyn.load("thisisthetest.dll")
[[ IT HANGS ]]
I have tried different combinations in paths (for library search) and
compiling inside cygwin. no success.
Any comments are very very very welcome.
Thanks !
[[alternative HTML version deleted]]
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Enhanced version of plot.lm()
> "MM" == Martin Maechler <[EMAIL PROTECTED]>
> on Tue, 26 Apr 2005 12:13:38 +0200 writes:
> "JMd" == John Maindonald <[EMAIL PROTECTED]>
> on Tue, 26 Apr 2005 15:44:26 +1000 writes:
JMd> The web page http://wwwmaths.anu.edu.au/~johnm/r/plot-lm/
JMd> now includes files:
JMd> plot.lm.RData: Image for file for plot6.lm, a version of plot.lm in
JMd> which
JMd> David Firth's Cook's distance vs leverage/(1-leverage) plot is plot 6.
JMd> The tick labels are in units of leverage, and the contour labels are
JMd> in units of absolute values of the standardized residual.
JMd> plot6.lm.Rd file: A matching help file
JMd> Comments will be welcome.
MM> Thank you John!
MM> The *.Rd has the new references and a new example but
MM> is not quite complete: the \usage{} has only 4 captions,
MM> \arguments{ .. \item{which} ..} only mentions '1:5' --- but
MM> never mind.
MM> One of the new examples is
MM> ## Replace Cook's distance plot by Residual-Leverage plot
MM> plot(lm.SR, which=c(1:3, 5))
MM> and -- conceptually I'd really like to change the default from
MM> 'which = 1:4' to the above
MM> 'which=c(1:3, 5))'
MM> This would be non-compatible though for all those that have
MM> always used the current default 1:4.
MM> OTOH, "MASS" or Peter Dalgaard's book don't mention plot( )
MM> or at least don't show it's result.
MM> What do others think?
MM> How problematic would a change be in the default plots that
MM> plot.lm() produces?
JMd> Another issue, discussed recently on r-help, is that when the model
JMd> formula is long, the default sub.caption=deparse(x$call) is broken
JMd> into multiple text elements and overwrites.
MM> good point!
JMd> The only clean and simple way that I can see to handle
JMd> is to set a default that tests whether the formula is
JMd> broken into multiple text elements, and if it is then
JMd> omit it. Users can then use their own imaginative
JMd> skills, and such suggestions as have been made on
JMd> r-help, to construct whatever form of labeling best
JMd> suits their case, their imaginative skills and their
JMd> coding skills.
MM> Hmm, yes, but I think we (R programmers) could try a bit harder
MM> to provide a reasonable default, e.g., something along
MM> cap <- deparse(x$call, width.cutoff = 500)[1]
MM> if((nc <- nchar(cap)) > 53)
MM> cap <- paste(substr(cap, 1, 50), "", substr(cap, nc-2, nc))
MM> {untested; some of the details will differ;
MM> and the '53', '50' could depend on par("..") measures}
In the mean time, I came to quite a nice way of doing this:
if(is.null(sub.caption)) { ## construct a default:
cal <- x$call
if (!is.na(m.f <- match("formula", names(cal {
cal <- cal[c(1, m.f)]
names(cal)[2] <- "" # drop " formula = "
}
cc <- deparse(cal, 80)
nc <- nchar(cc[1])
abbr <- length(cc) > 1 || nc > 75
sub.caption <-
if(abbr) paste(substr(cc[1], 1, min(75,nc)), "...") else cc[1]
}
I'm about to commit the current proposal(s) to R-devel,
**INCLUDING** changing the default from
'which = 1:4' to 'which = c(1:3,5)
and ellicit feedback starting from there.
One thing I think I would like is to use color for the Cook's
contours in the new 4th plot.
Martin
<.. lots deleted ..>
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems compiling C code on windows
On Wed, 27 Apr 2005, Victor Trevino wrote: I can't get my C routines running on a windows box. I have no problems at all in Linux. On windows, I have installed cygwin and the compilation works well but once I execute "dyn.load(.)" it hangs whatever I use C/C++ interfaces. Please try reading the R-admin manual (in 2.1.0) and installing a Windows compiler instead. R does not have a Cygwin port: it does have a native Windows port. -- 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@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problems compiling C code on windows
Hi all,
I can't get my C routines running on a windows box. I have no problems at
all in Linux.
On windows, I have installed cygwin and the compilation works well but once
I execute "dyn.load(.)" it hangs whatever I use C/C++ interfaces.
In Linux it works wonderful but I need to get this code running on windows
boxes.
I know that the problem should be something with the dll generation/linkage
in windows but I can't figure out.
As a matter of test I did the following C code:
#include
#include
SEXP thisisatest(SEXP);
SEXP thisisatest(SEXP a)
{
long int i;
if (!isReal(a)) printf("Vector should be double.\n");
for (i=LENGTH(a)-1; i >=0; i--) {
REAL(a)[i] = REAL(a)[i] + 1;
}
return (a);
}
Linux output:
R CMD SHLIB thisisthetest.c
gcc -I/usr/lib/R/include -I/usr/local/include -D__NO_MATH_INLINES -mieee-fp
-fPIC -O2 -g -pipe -march=i386 -mcpu=i686 -c thisisthetest.c -o
thisisthetest.o
g++ -shared -L/usr/local/lib -o thisisthetest.so thisisthetest.o
In R:
> dyn.load("thisisthetest.so")
> .Call("thisisatest",5)
[1] 6
>
[[ WONDERFUL ]]
Windows output:
L:\R>Rcmd SHLIB thisisthetest.c
making thisisthetest.d from thisisthetest.c
gcc -IC:/PROGRA~1/R/rw2001/include -Wall -O2 -c thisisthetest.c -o
thisisthetest.o
ar cr thisisthetest.a thisisthetest.o
ranlib thisisthetest.a
gcc --shared -s -o thisisthetest.dll thisisthetest.def thisisthetest.a
-LC:/PROGRA~1/R/rw2001/src/gnuwin32 -lg2c -lR
In R:
> dyn.load("thisisthetest.dll")
[[ IT HANGS ]]
I have tried different combinations in paths (for library search) and
compiling inside cygwin. no success.
Any comments are very very very welcome.
Thanks !
[[alternative HTML version deleted]]
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] smooth.spline(): residuals(), fitted(),...
It has bothered me for quite some time that a smoothing spline fit doesn't allow access to residuals or fitted values in general, since after fit <- smooth.spline(x,y, *) the resulting fit$x is really equal to the unique (up to 1e-6 precision) sorted original x values and fit$yin (and $y) is accordingly. There are several possible ways to implement the missing feature. My current implementation would add a new argument 'keep.data' which when set to TRUE would make sure that the original (x, y, w) are kept such that fitted values and (weighted or unweighted) residuals are sensibly available from the result. My main RFC (:= request for comments) is about the acceptance of the new behavior to become the *default* (i.e. 'keep.data = TRUE' would be default) such that by default residuals(smooth.spline(...)) will work. The drawback of the new default behavior would be that potentially a 'fit' can become quite a bit larger than previously, e.g. in the following extremely artificial example x0 <- seq(0,1, by = 0.1) x <- sort(sample(x0, 1000, replace = TRUE)) ff <- function(x) 10*(x-1/4)^2 + sin(7*pi*x) y <- ff(x) + rnorm(x) / 2 fit <- smooth.spline(x,y) but typically the size increase will only be less than about 40%. Comments are welcome. Martin Maechler, ETH Zurich __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RE: [R] when can we expect Prof Tierney's compiled R?
On Tue, 26 Apr 2005, Vadim Ogranovich wrote: Thank you for sharing the benchmark results. The improvement is very substantial, I am looking forward to the release of the byte compiler! The arithmetic shows that x[i]<- is still the bottleneck. I suspect that this is due to a very involved dispatching/search for the appropriate function on the C level. There might be significant gain if loops somehow cached the result of the initial dispatching. This is what you probably referred to as additional improvements in the engine itself. I'd be surprised if dispatching were the issue: have you (C-level) profiled to find out? Please do so: these statements do tend to get perpetuated as fact. You cannot cache the result, as [<- can change the class of x, as could other operations done by the rhs (e.g. if it were x[i] <- g(x, i) the function g could change its argument). There are a large number of allocations going on (e.g. you need to create a length-one vector x[i-1]), and gc.time(TRUE) [1] 0 0 0 0 0 system.time(f1(x, iA), gcFirst=TRUE) [1] 6.46 0.02 6.49 0.00 0.00 gc.time() [1] 1.83 1.30 1.85 0.00 0.00 (although note the comment in ?gc.time). It is typical that gc()-ing is a major component of the time for such simple tasks, and allocations can be even more. Note the use of gcFirst=TRUE (one could gc() before gc.time to be even fairer). Comparable figures for f2 system.time(f2(x, iA), gcFirst=TRUE) [1] 2.13 0.00 2.13 0.00 0.00 gc.time() [1] 0.69 0.54 0.71 0.00 0.00 It's quite typical for gc()-ing to take 1/3 of the time (as reported by gc.time) in trivial problems like this. Though the examples are very simple, I think they are typical of any simulation of dynamic systems where the new state is computed as a transformation of the previous state. In my example, the f1(), the state was a scalar and the transformation was the identity. I don't believe they are typical, as the transformation is so trivial. Of course, `simulation of dynamic systems' is not a typical task for R. In any case the timing of the byte-compilation is remarkable! Thanks, Vadim -Original Message- From: Luke Tierney [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 26, 2005 5:50 PM To: Vadim Ogranovich Cc: Peter Dalgaard; Jason Liao; r-devel@stat.math.ethz.ch Subject: RE: [R] when can we expect Prof Tierney's compiled R? For what it's worth (probably not much as these simple benchmarks are rarely representative of real code and so need to be taken with a huge chunk of salt) here is what happens with your examples in R 2.1.0 with the current byte compiler. Define your examples as functions: n = 1e6; iA = seq(2,n); x = double(n); f1 <- function(x, iA) for (i in iA) x[i] = x[i-1] f2 <- function(x, iA) for (i in iA) x[i-1] f3 <- function(x, iA) for (i in iA) 1 f4 <- function(x, iA) for (i in iA) x[i] = 1.0 f5 <- function(x, iA) for (i in iA) i-1 f6 <- function(x, iA) for (i in iA) i Make byte compiled versions: f1c <- cmpfun(f1) f2c <- cmpfun(f2) f3c <- cmpfun(f3) f4c <- cmpfun(f4) f5c <- cmpfun(f5) f6c <- cmpfun(f6) and run them: > system.time(f1(x, iA)) [1] 5.43 0.04 5.56 0.00 0.00 > system.time(f1c(x, iA)) [1] 1.77 0.03 1.81 0.00 0.00 > system.time(f2(x, iA)) [1] 1.72 0.01 1.74 0.00 0.00 > system.time(f2c(x, iA)) [1] 0.63 0.00 0.63 0.00 0.00 > system.time(f3(x, iA)) [1] 0.19 0.00 0.20 0.00 0.00 > system.time(f3c(x, iA)) [1] 0.14 0.00 0.15 0.00 0.00 > system.time(f4(x, iA)) [1] 3.78 0.03 3.82 0.00 0.00 > system.time(f4c(x, iA)) [1] 1.26 0.02 1.30 0.00 0.00 > system.time(f5(x, iA)) [1] 0.99 0.00 1.00 0.00 0.00 > system.time(f5c(x, iA)) [1] 0.30 0.00 0.31 0.00 0.00 > system.time(f6(x, iA)) [1] 0.21 0.00 0.23 0.00 0.00 > system.time(f6c(x, iA)) [1] 0.17 0.00 0.20 0.00 0.00 I'll let you do the arithmetic. The byte compiler does get rid of a fair bit of interpreter overhead (which is large in these kinds of examples compared to most real code) but there is still considerable room for improvement. The byte code engine currently uses the same internal C code for doing the actual work as the interpreter, so improvements there would help both interpreted and byte compiled code. Best, luke On Fri, 22 Apr 2005, Vadim Ogranovich wrote: If we are on the subject of byte compilation, let me bring a couple of examples which have been puzzling me for some time. I'd like to know a) if the compilation will likely to improve the performance for this type of computations, and b) at least roughly understand the reasons for the observed numbers, specifically why x[i]<- assignment is so much slower than x[i] extraction. The loops below are typical in any recursive calculation where the new value of a vector is based on its immediate neighbor say to the left. Specifically we assign the previous value to the current element. # this shows that the assignment x[i]<- is the bottl
