Re: [Rd] Bug in new() or validObject() in methods package (PR#7922)
[EMAIL PROTECTED] writes: > Is it doing an extra eval or something? It looks like it: > > > x <- expression() > > x > expression() > > eval(x) > NULL > > > > x <- quote(expression()) > > x > expression() > > eval(x) > expression() > > eval(eval(x)) > NULL You do realize that the two expression() results are not identical: > x <- quote(expression()) > class(x) [1] "call" > x <- expression() > class(x) [1] "expression" Not that I can fathom what bearing that has on the real problem... -- 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
Re: [Rd] Re: [R] A long digression on packages
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > Jim raises good points, as do the replies. On the topic of '500+ and > growing', let me add my pet peeve: It is mighty impossible to know /what/ > changed /when/ in CRANland. > > Being Debian maintainer for a fair number of packages, I owe users of those > packages timely updates. But the best I can do is to look at the > timestamp-sorted source directory http://cran.r-project.org/src/contrib/?M=D > That is tedious, as well as error-prone. Moreover, as an R user, I'd like to > know what is being added and, and what is being changed. There is no way to > know right now. > > I would not be hard to write a little monitoring script that looks at the > directory (and keeps tab in a Rdata structure, or SQLite db, or ...) and > spits out either emails, or maybe rss-feed updates, of either or both of 'new > packages' or 'new versions'. If additionally we would enforce (err let's > start with encourage) a standardised changelog (say $SRC/inst/CHANGES or > $SRC/inst/ChangeLog) then that could get parsed too. I had meant to play > with some code for this for a while now but it just hasn't happened. > Whining on a list is easier than writing code, unfortunately... > > Comments? You might want to have a closer look at the way recommended packages are handled by an R distribution build, using rsync, links, timestamps, and makefile rules. -- 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
Re: [Rd] fix for save()'ing RAW on PPC (and other big endian platforms)
Byron Ellis <[EMAIL PROTECTED]> writes: > OutByte should take a byte, not an int. Writing the first byte of an > int is only going to work on little endian systems. > > serialize.c:262 > -static void OutByte(R_outpstream_t stream, int i) > +static void OutByte(R_outpstream_t stream, Rbyte i) Thanks for tracking this down. -- 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
[Rd] R-bugs will be offline starting June 7
Due to our IT unit moving on Wednesday and Biostat's move the day after, the web interface to r-bugs will be offline from the afternoon of June 7 at least until the afternoon of June 9, possibly going into the 10th. The email interface may come up somewhat earlier. -pd -- 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
Re: [Rd] Internationalizing the Rcmdr package?
"John Fox" <[EMAIL PROTECTED]> writes:
> Dear R-devel list members,
>
> I'm considering adding support for other languages than English to the Rcmdr
> package. I understand that the use of Tcl/Tk by the Rcmdr package means I
> won't be able to make full use of the internationalization facilities in R
> 2.1.0. I'm interested, therefore, in whether the following, more limited,
> strategy (which bears some similarity to the internationalization facilities
> in R) seems reasonable or whether there's a better approach. As well, I'm
> interested in whether the proposed approach is sufficiently flexible to be
> worthwhile -- does it cover enough languages?
>
> It would be simple for me to provide a file of messages, labels, and other
> text used by the Rcmdr, organizing this file with one message per line. A
> copy of the file, named, e.g., messages.francais, could contain translations
> into another language (e.g, French). Setting
> options(Rcmdr=list(language=francais)) would then activate translation when
> the Rcmdr starts up, reading the messages file into a data frame, treating
> the English text as row names. The messages could be handled by a function,
> say Text(), which would return English or translated text, as appropriate.
> Some experimentation shows that message retrieval by this scheme is
> essentially instantaneous even when there are several thousand relatively
> long messages in the data frame.
Offhand, I think you're better off latching on to an existing
mechanism. Tcl has something known as "msgcat", which appears to be
similar to GNU gettext (and there are conversion tools), or perhaps
you could interface to gettext itself (we do have the gettext()
function at the R level).
Two tricky bits:
(A) shortcut keys, which need to be coordinated to menu items
("Accept/Break/Cancel" translates to "Accepter/Afbryd/Annuller" in
Danish - if you're a little malicious, anyway)
(B) What is the general mechanism for extending message catalogs by an
R package?
Brian may well have thought of this stuff already.
--
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
Re: [Rd] R Include File Guards
Paul Roebuck <[EMAIL PROTECTED]> writes: > R 2.1.0/src/include from 2005/04/18 download > > Naming inconsistent for guards as well but that's pedantic. > Simple convention: > file > #ifndef R_FOO_H > file > #ifndef R_EXT_BAR_H > > Missing guards: > > > > > > > > > > > Illegal Guards (leading underscore): > > > Thanks. The ones outside R_ext, except Rinternals.h, are not part of the API, so it is not a bug that there are no guards - could still be a good idea to have them of course. libextern.h explicitly says that you shouldn't disallow including it more than once. So the ones with real problems would be What's illegal about leading underscores, BTW? -- 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
Re: [Rd] Specifying dependency on a specific patched version
Uwe Ligges <[EMAIL PROTECTED]> writes: > If I am compiling under 2.1.0 release, the package will fail my checks. > If I would be compiling under R-patched, it will not fail the checks, > but don't work for several users who probably do not want to use > un-released versions of R. > > I think the best way is to wait for the next release of R. > > Is there a schedule for R-2.1.1, BTW? Sort of. The expected date could be June 20, *if* the move of the IT department on June 7-8-9 and of the Biostat on June 9-10 leaves us with a sufficiently functional build system to start beta releases on Monday 13th... -- 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
Re: [Rd] Bug in axis labels (PR#7860)
[EMAIL PROTECTED] writes: > > Everything works fine in R1.5.1 (I know, I know!) on Debian Linux, which > > is why I'm reporting this as a Windows problem. > > I see the problem in the first figure, and it's still there in a recent > r-devel build. My test was also on Windows. Since png() uses the > Windows graphics driver, it does look like an R bug in the Windows > graphics driver, but I'd like to hear from someone on a different > platform... I don't see it with 2.1.0 on Linux (FC3). -- 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
Re: [Rd] Building R for windows tools link
Gregor GORJANC <[EMAIL PROTECTED]> writes: > > As the front page says > > > > `This site is intended as an intermediate repository for more or less > > finalized ideas and plans for the R statistical system.' > > > > What exactly is unclear about that? How to build current R is not part > > of the development of R. > > Nothing is unclear. I still think that building is part of the development. > I'm sure that R-devils, uups I meant R-devels, don't want to develop > something that is not buildable. Anyway, lets end with this disscussion. I > will remember that mentioned link is in R-admin manual. Just to be clear: The point is that the developer site was never intended as being complete and polished, and nobody wants to commit to making it so. It was set up for things like preliminary white papers which were too large to handle as part of regular email traffic within R Core, plus some items that we kept needing to remind ourselves (and some others) about. It is open to the public, but it is not a service. -- 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
Re: [Rd] Windows freezes plotting large line plots (PR#7856)
[EMAIL PROTECTED] writes: > The following command causes Windows XP to freeze so that I can only pull the > plug: > > plot(seq(1, 44100), rnorm(44100), type="l") > > This does not happen with > > plot(seq(1, 44100), rnorm(44100)) > and > > plot(seq(1,100), rnorm(100), type="l") This was fixed (worked around -- the bug is in Windows) once before during "belated beta testing" of 2.1.0. Try 2.1.0 patched. -- 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
Re: [Rd] bug in modulus operator %% (PR#7852)
"McGehee, Robert" <[EMAIL PROTECTED]> writes: > Yes, but from ?"%%": > "It is guaranteed that 'x == (x %% y) + y * (x %/% y)' (up to rounding > error) ..." > > (R 2.1.0) > > x <- 1 > > y <- 0.2 > > x %% y > [1] 0.2 > > (x %% y) + y * (x %/% y) > [1] 1.2 > > Certainly 1 does not equal 1.2 as the documentation would suggest, and > these seem like large enough numbers to not be effected by rounding > errors or lack of precision. Now that looks a bit odd, but it isn't universal: > x <- 1 > y <- 0.2 > x %% y [1] 0.2 > x %/% y [1] 4 > (x %% y) + y * (x %/% y) [1] 1 So what platform was that happening on? -- 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
Re: [Rd] bug in modulus operator %% (PR#7852)
[EMAIL PROTECTED] writes:
> The following can't be right,
> first rw2010:
>
> > 1 %% 0.001
> [1] 0.001
>
> Then rw2001:
>
> > 1 %% 0.001
> [1] -2.081668e-17
> >
>
> and the last seems about right.
A negative remainder? I don't think so. Presumably the result comes
from
o %% now warns if its accuracy is likely to be affected by lack
of precision (as in 1e18 %% 11, the unrealistic expectation of
PR#7409), and tries harder to return a value in range when it
is.
So, not a bug.
--
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
Re: [Rd] Variable names with spaces in lm
Gabor Grothendieck <[EMAIL PROTECTED]> writes: > 'lm' gives an error when using variables with spaces in them > in certain cases (but not all): > > my.list <- list(`a 1` = 1:4, `a 2` = 11:14) > lm(`a 1` ~ ., my.list) # Error : Object "a.1" not found > > # The following work ok so it does work in many cases: > > lm(`a 1` ~ ., as.data.frame(my.list, optional = TRUE)) # ok > lm(`a 1` ~ `a 2`, my.list) # ok > > Admittedly ?lm says that the data argument should be > a data frame or environment so this is not strictly a bug > but it seems to work with a list and the code even seems to > coerce it to a data frame. > > I am using Windows XP "R version 2.1.0, 2005-04-18". As you probably gathered, the issue is that there's an as.data.frame() without optional=TRUE sitting inside terms.formula which causes the "." to expand to a.1 + a.2. Sounds like that's unconditionally a bug, but I'm a little unsure... -- 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
Re: [Rd] Varying as.Date performance
Jeff Enos <[EMAIL PROTECTED]> writes: > Thanks for these suggestions. C-level profiling yields the following: > > % cumulative self self total > time seconds secondscalls s/call s/call name > 36.01 5.34 5.34 10 0.00 0.00 get_locale_strings > 4.32 5.98 0.64 10 0.00 0.00 mktime00 > 3.98 6.57 0.59 277462 0.00 0.00 Rf_eval > 3.71 7.12 0.55 472935 0.00 0.00 Rf_findVarInFrame3 > 3.64 7.66 0.54 10 0.00 0.00 strptime_internal > 3.51 8.18 0.521 0.52 7.51 do_strptime > > It looks like strftime is called from get_locale_strings, which might > be the culprit. Any suggestions on where I might go from here? You might try modifying get_locale_strings (and its wide counterpart) with a check for an unchanged locale. E.g. static char *last_LC_TIME=NULL; tmp = setlocale(LC_TIME, NULL) if (strcmp(tmp, last_LC_TIME)) return; last_LC_TIME = tmp; set the strings if the call to setlocale is considerably faster than 40 calls to strftime(), you might have a winner. -- 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
Re: [Rd] documenation for arrows() is backwards (PR#7839)
Peter Kleiweg <[EMAIL PROTECTED]> writes: > Peter Dalgaard wrote: > > > [EMAIL PROTECTED] writes: > > > > > > Let me point out that I for one do not consider it good netiquette to > > use fake or mangled email addresses on bug reports! I get enough mail > > from the Mailer Daemon as it is. > > Doesn't look like a fake or mangled address to me. You are not > familiar with the user+tag mail construct? It may be formally valid, but it still bounced -- 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
Re: [Rd] documenation for arrows() is backwards (PR#7839)
[EMAIL PROTECTED] writes: Let me point out that I for one do not consider it good netiquette to use fake or mangled email addresses on bug reports! I get enough mail from the Mailer Daemon as it is. -- 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
Re: [Rd] documenation for arrows() is backwards (PR#7839)
[EMAIL PROTECTED] writes:
> Full_Name: Michael Hoffman
> Version: 2.1.0
> OS: Linux (Fedora Core 3, kernel 2.6.11-1.14_FC3)
> Submission from: (NULL) (193.62.199.8)
>
>
> help(arrows) says:
>
> """
> arrows(x0, y0, x1, y1, length = 0.25, angle = 30, code = 2,
> col = par("fg"), lty = NULL, lwd = par("lwd"), xpd = NULL)
>
> ...
>
> If 'code=2' an arrowhead is drawn at '(x0[i],y0[i])' and if
> 'code=1' an arrowhead is drawn at '(x1[i],y1[i])'. If 'code=3' a
> head is drawn at both ends of the arrow. Unless 'length = 0',
> when no head is drawn.
> """
>
> If you do:
>
> plot(c(-1, 1), c(-1, 1), col=0)
> arrows(x0=0, y0=0, x1=0, y1=1, code=2)
>
> it is pretty clear that the arrowhead is drawn at x1, y1 with code=2. If you
> switch to code=1, the arrowhead is drawn at x0, y0. Either the documentation
> or
> the function is incorrect.
One way to decide is to compare with Splus. Now that doesn't have a
'code' argument and the arguments are named x1,y1,x2,y2 (I wonder why
R wanted to be different here?), but they do put the arrowheads at the
*to* end, which does seem to be the sensible thing to do.
Arguably, using 'code=2' as the default is a bit weird, but changing
it could be quite painful. I.e., we should fix the docs.
BTW, the docs also might say that code=0 makes arrows behave like
segments(). It is also a bit strange that the code argument isn't
vectorized, which might have been useful.
--
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
Re: [Rd] make hanging during compile of r-patched/R-devel on Fedora Core 3
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > > Any clue whether there is any benefit in using the FC3 versions over > > the versions that ships with R? > > Yes: at least for earlier versions, none. (See the comments in the > R-admin manual I quoted yesterday which no one else seems to have > read.) I did know about them. I was being mildly sarcastic and partly curious. In principle, having lapack/blas maintained as part of the distributions would be good, especially if they could sort out the (nontrivial) processor-specific tuning issues. Currently, the RPMs of R for both SuSE and Fedora ship with minimal tuning, and you need to compile your own version to take advantage of (say) an ATLAS blas. This is not hard to do, but you lose the niceties of the RPM system with respect to upgrades, dependencies and all that. In practice, if the distributions also ship minimally tuned libs, and buggy ones too, the point gets rather moot. -- 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
Re: [Rd] make hanging during compile of r-patched/R-devel on Fedora Core 3
Gavin Simpson <[EMAIL PROTECTED]> writes: > Basically, the LAPACK in FC3 is broken because it was compiled with > gcc-3.4 and that introduced errors when -O2 optimisations were used to > compile the rpm. That bug was recently reopened so there may be the > possibility of the FC3 rpm being updated (the underlying problem has > been fixed by compiling with lower optimisation). There's a pending update on lapack/blas now, which may or may not fix the issue (no announcement in the archives). Any clue whether there is any benefit in using the FC3 versions over the versions that ships with R? -- 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
Re: [Rd] formals assignment now strips attributres
Patrick Burns <[EMAIL PROTECTED]> writes: > Peter Dalgaard wrote: ... > >>fjj <- function() x > >>formals(fjj) <- list(x=quote(c(a=2, b=4))) > >>fjj() > >> > >a b > >2 4 > > > >>fix(fjj) > >>fjj() > >> > >a b > >2 4 > > > > But the point of using 'formals' in the first place is to get a > function that is self-contained. The real application is more > like: > > formals(fjj) <- list(x = an_object) > > I want 'fjj' to work even when 'an_object' is nowhere to be > found. > > 'formals' worked as (I) expected in versions 1.8.0 > through 1.9.1 at least. Pat It didn't change. It's the editing that is doing you in. There have been changes to deparse, and they seem to have introduced a bug, but a function object created in that way is fundamentally uneditable. -- 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
Re: [Rd] formals assignment now strips attributres
Patrick Burns <[EMAIL PROTECTED]> writes: > But the buglet gets more aggressive if you edit the function: > > > fjj <- function() x > > formals(fjj) <- list(x=c(a=2, b=4)) > > fjj > function (x = c(2, 4)) > x > > fjj() > a b > 2 4 > > fix(fjj) # do nothing but save > > fjj() > [1] 2 4 > > I'm quite sure that I wouldn't have noticed if my real function were > not broken. > > Now I know that my functions will work if I assign the formals after I > edit the > function -- even though they look like they shouldn't work. You did invite trouble by creating and subsequently a function that _has_ no source representation though: > fjj <- function() x > formals(fjj) <- list(x=quote(c(a=2, b=4))) > fjj() a b 2 4 > fix(fjj) > fjj() a b 2 4 > fjj function (x = c(a = 2, b = 4)) x -- 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
Re: [Rd] formals assignment now strips attributres
Patrick Burns <[EMAIL PROTECTED]> writes:
> The assignment form of 'formals' strips attributes (or something close
> to that) from the values in the list. This wasn't intentional, was it?
>
> The current behavior (2.0.0 through 2.1.0 on Windows at least):
>
> > fjj <- function() x
> > formals(fjj) <- list(x=c(a=2, b=4))
> > fjj
> function (x = c(2, 4))
> x
>
>
> Previous behavior:
>
> > fjj <- function() x
> > formals(fjj) <- list(x=c(a=2, b=4))
> > fjj
> function (x = structure(c(2, 4), .Names = c("a", "b")))
> x
It is only a buglet in deparsing:
> formals(fjj)
$x
a b
2 4
> fjj()
a b
2 4
> as.list(fjj)
$x
a b
2 4
[[2]]
x
BTW, why is it that we cannot deparse named vectors nicely?
> deparse(c(a=1,b=2))
[1] "structure(c(1, 2), .Names = c(\"a\", \"b\"))"
> deparse(as.list(c(a=1,b=2)))
[1] "structure(list(a = 1, b = 2), .Names = c(\"a\", \"b\"))"
Notice also that fjj constructed as above is not identical to
function (x = c(a = 1, b = 2))
x
since the default expression is a vector in one case and a call to "c"
in the other. This is part of the problem; you're trying to deparse
something that cannot be the result of parsing. (The existence of such
objects is a generic problem in the R (and S) language).
--
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
Re: [Rd] segfault during build of 2.1.0 on RH9; print.POSIXct implicated (PR#7827)
[EMAIL PROTECTED] writes:
> > unusual_but_ok <- c.POSIXlt(character(0))
> > unusual_but_ok
> character(0)
> > unusual_and_faults <- c.POSIXct(character(0))
> > unusual_and_faults
> Segmentation fault
>
> Running this test program under gdb, we find that we're running off the
> end of the stack, with 4222 stack frames showing -- apparently in an
> infinite recursion -- "as.character" shows up every 69 function calls:
This gives a protection stack overflow on FC3 and RH8. Is the stack
particularly small on RH9? I have 8MB on RH8 and 10MB on FC3. (The R
limits for expression depth and pointer protection were increased in
2.1.0). I can force a segfault, but only after "ulimit -s 1024" or so.
> #64 0x080ea1ef in Rf_usemethod (generic=0x81c8b12 "as.character", obj=0x0,
> call=0x85a04f4,
...
> So it would seem that *printing* the unusual POSIXct value is suspect.
Pretty obviously, yes.
> Looking at a R-1.8.1 install, we find these definitions in base/R/base:
>
> print.POSIXct <- function(x, ...)
> {
> print(format(x, usetz=TRUE), ...)
> invisible(x)
> }
>
> print.POSIXlt <- function(x, ...)
> {
> print(format(x, usetz=TRUE), ...)
> invisible(x)
> }
>
> However, looking at the 2.1.0 src file
> R-2.1.0/src/library/base/R/datetime.R, we find
>
> print.POSIXct <- function(x, ...)
> {
> print(format(x, usetz=TRUE, ...), ...)
> invisible(x)
> }
>
> print.POSIXlt <- function(x, ...)
> {
> print(format(x, usetz=TRUE), ...)
> invisible(x)
> }
>
> Note the suspicious definition of print.POSIXct using *two* sets of
> ellipses, and that the print.POSIXct and print.POSIXlt definitions no
> longer match.
Probably both should use the double ellipses, but "..." will be empty
on automatic printing, so that's not it.
The issue is an infinite recursion inside as.POSIXlt(). Specifically,
strptime() internally calls as.character(x) inside the fromchar()
function in as.POSIXlt(), and as.character.POSIXt() invokes format()
which calls as.POSIXlt() again.
I think the fix is to unclass(x) inside fromchar(), but perhaps others
know better?
--
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
Re: [Rd] I'm unable to download R from any of the CRAN mirrors. Any sugge (PR#7823)
This is not a bug in R. Please do not misuse the bug repository. The central CRAN site in Vienna was offline for some hours tonight. This may have disrupted mirroring, but things look like they are back to normal. If you have problems downloading in general, then you probably need to talk to your local support staff. [EMAIL PROTECTED] writes: > > Thanks. > > Eric Leifer, Ph.D. > Office of Biostatistics Research > National Heart, Lung, and Blood Institute > 6701 Rockledge Drive, MSC 8217 > Bethesda, MD 20892-8217 > Email: [EMAIL PROTECTED] > Phone: 301-435-0436 > FAX:301-480-1862 > > __ > R-devel@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- 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
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
Re: [Rd] Ctrl-c crashes R when run as sudo (PR#7819)
[EMAIL PROTECTED] writes: > > Thanks you, however Marc omitted to mention that you need to type > > signal SIGINT > > before running the backtrace (bt), because gdb will catch the INT > > signal thus not leading to the desired crash and the backtrace just > > shows when you hit Ctrl-C, not what happens after. Only after the > > signal SIGINT you should get the crash (if at all). ... > Manuel, I should have asked earlier, but I presume that you installed > from source as I don't see RPMs for 2.1.0 yet? > > Marc The effect seem to have been neatly backported to 2.0.1 though... Gdb doesn't seem to help. If you run a ps while "sudo R" is running, you'll see something like this: root 30416 0.0 0.1 2356 252 pts/5S+ 19:48 0:00 sesh /usr/bin/R root 30417 10.0 7.2 18016 13860 pts/5 S+ 19:48 0:01 /usr/lib/R/bin/exec/R What I suspect is happening is that the ^C kills the sesh process, but that in turn does not manage to kill R. -- 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
Re: [Rd] "wild" function example in optim
Thomas Lumley <[EMAIL PROTECTED]> writes: > On Tue, 26 Apr 2005, Werner Bier wrote: > > > Dear all, > > > > Firstly, I do apologize if my question is simple and posted in the > > wrong place but I had no reply from the R-help mailing list (maybe > > it is too simple!). > > > > I was wondering why parscale is set to 20 in the "wild" function > > example used in ?optim. This function has only one parameter and if > > we set parscale equal to 1 then the solution near the global minimum > > is not found. > > > > I would use parscale only in cases the object function has more than > > one parameter to be optimised, shouldn't I? > > > > parscale is more important in cases with more than one parameter (and > with one parameter you could set fnscale instead of parscale to get > the same effect) > > However, a sufficiently badly scaled one-d problem can still benefit > from fnscale or parscale. > > f > function(x) 1e-10*x^2 > > g > function(x) 2e-10*x > > optim(7,f,g,method="CG")$par > [1] 7 > > optim(7,f,g,method="CG",control=list(parscale=1e5))$par > [1] 1.209735e-14 > > optim(7,f,g,method="CG",control=list(fnscale=1e-10))$par > [1] 1.673141e-15 It also depends on the optimizer. The SANN optimizer basically jumps haphazardly (well, a bit more intelligently than that) back and forth along the x axis and then "cools down" in order to settle in the "best" local minimum. The parscale plays a role in setting the scale of those jumps and if it is too low it might not wander far enough to get near the true minimum. For further information, you really need to do your own reading. References are given on the help page. -- 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
Re: [Rd] tclServiceMode: stop Tcl/Tk from updating
"John Fox" <[EMAIL PROTECTED]> writes:
> Dear Duncan,
>
> I hope that some follow-up questions are in order:
>
> In the Rcdmr package, there is a pair of functions for initializing and
> completing dialogs:
>
> initializeDialog <- defmacro(window=top, title="", offset=10,
> expr={
> window <- tktoplevel(borderwidth=10)
> tkwm.title(window, title)
> position <- if (is.SciViews()) -1 else commanderPosition() # +PhG
> position <- if (any(position < 0)) "-50+50"
> else paste("+", paste(offset + position, collapse="+"), sep="")
> tkwm.geometry(window, position)
> }
> )
>
> dialogSuffix <- defmacro(window=top, onOK=onOK, rows=1, columns=1,
> focus=top,
> bindReturn=TRUE, preventGrabFocus=FALSE, preventDoubleClick=FALSE,
> expr={
> for (row in 0:(rows-1)) tkgrid.rowconfigure(window, row, weight=0)
> for (col in 0:(columns-1)) tkgrid.columnconfigure(window, col,
> weight=0)
> .Tcl("update idletasks")
> tkwm.resizable(window, 0, 0)
> if (bindReturn) tkbind(window, "", onOK)
> if (getRcmdr("double.click") && (!preventDoubleClick))
> tkbind(window, "", onOK)
> tkwm.deiconify(window)
> # focus grabs appear to cause problems for some dialogs
> if (GrabFocus() && (!preventGrabFocus)) tkgrab.set(window)
> tkfocus(focus)
> tkwait.window(window)
> }
> )
>
> (Both of these are "macro-like" in the sense of Thomas Lumley's R-news
> article.)
>
> If I understand you correctly, I could improve the R Commander's stability
> under windows by putting tclServiceMode(on = FALSE) at the beginning of
> initializeDialog(), and tclServiceMode(on = TRUE) at the end of
> dialogSuffix(). Is that correct? If so, is there any harm in doing this on
> other platforms, or should I test for Windows? Finally, do you mind if I put
> tclServiceMode() in the Rcmdr package for the time-being, or would it just
> be better to wait for R 2.1.1?
It's a horrible kludge (I can say so because I suggested it) and a
sign that we don't really understand the way the Tk event loop runs on
Windows.
However, as far as I can tell, it should be harmless to use
tclServiceMode() on other platforms, as long as you ensure that
on=TRUE is used whenever you do want to process events. Mostly, you'll
just be disabling event processing at points where you weren't
handling events anyway.
If you use things like tkwait.variable() when on=FALSE, then you're in
trouble, but that goes for all platforms.
--
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
Re: [Rd] Enhanced version of plot.lm()
Martin Maechler <[EMAIL PROTECTED]> writes: > This would be non-compatible though for all those that have > always used the current default 1:4. > OTOH, "MASS" or Peter Dalgaard's book don't mention plot( ) > or at least don't show it's result. Ummm, check page 183... -- 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
Re: [Rd] RAW types not restored from Rda files (PR#7812)
[EMAIL PROTECTED] writes:
> Full_Name: Byron Ellis
> Version: 2.1.0
> OS: OS X
> Submission from: (NULL) (67.124.246.46)
>
>
> > x = charToRaw("12345")
> > x
> [1] 31 32 33 34 35
> > save(x,file="x.Rda")
> > rm(x)
> > load("x.Rda")
> > x
> [1] 00 00 00 00 00
>
> Thats no fun.
It's not happening to me though (with R-devel). Can you do a hex dump
of the x.Rda file so that we can see whether the load or the save is
failing? As in
$ od -x x.Rda
000 4452 3258 580a 000a 0002 0202
020 0401 0400 0002 0001 1000 0009
0000040 7801 1800 0500 3231 3433
060 0035 00fe
065
--
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
Re: [Rd] Infinite degrees of freedom for F-distribution
Gordon Smyth <[EMAIL PROTECTED]> writes: > This is just a suggestion/wish that it would be nice for the > F-distribution functions to recognize limiting cases for infinite > degrees of freedom, as the t-distribution functions already do. > > The t-distribution functions recognize that df=Inf is equivalent to > the standard normal distribution: > > > pt(1,df=Inf) > [1] 0.8413447 > > pnorm(1) > [1] 0.8413447 > > On the other hand, pf() will accept Inf for df1, but returns the wrong result: > > > pf(1,df1=Inf,df2=1) > [1] 1 > > whereas the correct limiting value is > > > pchisq(1,df=1,lower.tail=FALSE) > [1] 0.3173105 > > pf() returns NaN when df2=Inf: > > > pf(1,df1=1,df2=Inf) > [1] NaN > Warning message: > NaNs produced in: pf(q, df1, df2, lower.tail, log.p) > > although the correct value is available as > > > pchisq(1,df=1) > [1] 0.6826895 > > > Gordon > > > version > _ > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status > major2 > minor1.0 > year 2005 > month04 > day 18 > language R This is actually a regression. It worked as you suggest in 2.0.1, at least on Linux. Also, somewhat disturbing, > pf(1,df1=1,df2=Inf) [1] NaN Warning message: NaNs produced in: pf(q, df1, df2, lower.tail, log.p) > pf(1,df1=1,df2=) [1] 0.6826895 > pf(1,df1=1,df2=) [1] 0.6826841 > pf(1,df1=1,df2=) [1] 0 (notice that the middle case has actually begun to diverge from the limiting value) -- 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
Re: [Rd] Plots with lots of points (PR#7805)
[EMAIL PROTECTED] writes: > Full_Name: Francisco Vera > Version: 2.1.0 > OS: Windows XP > Submission from: (NULL) (129.252.16.42) > > > I have this time series with 96000 data points which I am using R to analyze. > The plots produced by some functions (like stl) were working fine in version > 2.0.1, but the same plots are causing my machine to stop working all together > in > version 2.1.0. > > After trying several times, I uninstalled version 2.1.0 and install again > 2.0.1, > and the plots worked fine. So I think there is a bug introduced in version > 2.1.0. Could well be, but you're much more likely to find a volunteer to fix it for you if you provide a reproducible example. -- 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
Re: [Rd] RFC: hexadecimal constants and decimal points
Martin Maechler <[EMAIL PROTECTED]> writes: > BDR> We could do better by insisting that "." was the decimal > BDR> point in all interval conversions _to_ numeric. Then the > BDR> effect of setting LC_NUMERIC would primarily be on > BDR> conversions _from_ numeric, especially printing and > BDR> graphical output. (One issue would be what to do with > BDR> scan(), which has a `dec' argument but is implemented > BDR> assuming LC_NUMERIC=C. I would hope to continue to have > BDR> `dec' but perhaps with a locale-dependent default.) The > BDR> resulting asymmetry (R would not be able to parse its own > BDR> output) would be unhappy, but seems inevitable. (This could > BDR> be implemented easily by having a `dec' arg to EncodeReal > BDR> and EncodeComplex, and using LC_NUMERIC to control that > BDR> rather than actually setting the local category. For > BDR> example, deparsing needs to be done in LC_NUMERIC=C.) > > Yes, I like this quite a bit: > > - Only allow "." as decimal point in conversions to numeric. > > - Allowing "," (or other locale settings if there are) for > conversions _from_ numeric will be very attractive to some > (not to me) and will make the use of R's ``reporting > facility' much more natural to them. > > That the asymmetry is bit unhappy -- and that will be a good reason > to advocate (to the user community) that using "," for decimal > point may be a bad idea in general. Could I suggest that we tread very carefully here? This issue has caused several trip-ups historically: - The locale-dependent "comma-separated variables" format, in some cases not separated by commas. And it seems that you can still get Excel files that use comma both for separation and as decimal point (I thought that problem disappeared with early versions of Paradox, but apparently not, according to a resent query on r-help). - Exports from SAS as a text file cannot be read by SPSS and vice versa. etc. Quite possibly, the "computer world" missed the opportunity to agree on an international standard (what's the big deal with using commas anyway?). As it is we probably have to adjust to it, but we have to distinguish very carefully between reports, code, and data, and choose appropriate conventions for each case. -- 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
Re: [Rd] citation() chops "Roeland " (PR#7797)
[EMAIL PROTECTED] writes:
> Full_Name: Jari Oksanen
> Version: 2.0.1, 2.1.0 beta (2005-04-17)
> OS: Linux
> Submission from: (NULL) (130.231.102.145)
>
>
> If name ends with "and", such as "Roeland Lastname", citation() will chop
> "and"
> as a separate word giving "Roel and Lastname". This is the case in the
> upcoming
> release of vegan (1.6-8) just submitted to CRAN. Basically, this seems to
> happen
> in utils:::as.personList.default
>
> > unlist(as.personList("Roeland Lastname"))
> name.first name.middle name.last name.first name.middle name.last
> "" "" "Roel" "" "" "Lastname"
>
> and the culprit line seems to be:
>
> x <- unlist(strsplit(x, "[[:space:]]?(,|and)[[:space:]]+"))
>
> Fortunately, persons like Anders Andtfolk and Mandalay Grandjean are not
> chopped, because they don't have space after "and".
I'm sure it'll annoy Anders|George Sand, Bertrand Russell, Inge
Helland, et al., but it hardly counts as release-critical, nor trivial
enough to slip in during code freeze, especially as regular
expressions are involved (does one *ever* get them right on the first
try?)
--
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
Re: [Rd] dealing with empty actual arguments matched by '...' formals
Duncan Murdoch <[EMAIL PROTECTED]> writes: > Tony Plate wrote: > > I'm trying to write some functions to deal with empty actual > > arguments that are picked up by '...' formals. Such actual > > arguments are common (and very useful) in calls to subsetting > > functions, e.g., x[1:2,]. It seems that R and S-PLUS treat these > > arguments differently: in S-PLUS list(...) will return a list > > containing just the non-empty arguments, whereas in R list(...) > > stops with an error: > > > # In R: > > > f <- function(x, ...) list(...) > > > f(1,2) > > [[1]] > > [1] 2 > > > f(1,2,) > > Error in f(1, 2, ) : argument is missing, with no default > > > > > So it seems that quite different methods must be used in S-PLUS and > > R to detect and process the arguments of a function that can have > > empty arguments matched to '...'. > > Can you give an example where it's useful to do this, i.e. to have a > call like f(1,2,)? I've never used that construction as far as I can > recall. The standard case is indexing, as Tony mentions. The whole thing is somewhat tricky because at least some of R's semantics are deliberately different from S. E.g. > f <- function(i) g(i) > g <- function(i) missing(i) > f() [1] TRUE Same thing in S gives FALSE. S looks at the call to g whereas R looks at the value. This works by passing a "magic bullet" which is implemented as the "empty name", as you can get to see by doing something like > f <- function(...) match.call(expand.dots=FALSE)$... > l <- f(1,,2) > eval(l[[2]]) Error in eval(expr, envir, enclos) : Argument is missing, with no default > mode(l[[2]]) [1] "name" > as.character(l[[2]]) [1] "" One side effect of R's way of doing things is that a call to list(i,j,k) with k missing is hard to tell from list(i,j,). However, list() must be doing that somehow... I'm not sure it is a good thing, but it may have been necessary for S compatibility. I think that what Tony was up to might be doable through variations on the match.call() scheme above. -- 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
Re: [Rd] (no subject)
"Liaw, Andy" <[EMAIL PROTECTED]> writes: > > From: Lars Schouw > > > > Can anyone explain what this means the NEWS for for > > 2.1 beta? > > > > R is now linked against ncurses/termlib/termcap only > > if > > readline is specified (now the default) and that > > requires it. > > > > I get an error while running configure: > > checking for history_truncate_file... no > > configure: error: --with-readline=yes (default) and > > headers/libs are not available > > It means what it says: configure will try to find > ncurses/termcap/readline (and their headers) unless > you explicitly say --with-readline=no. ..the point being that you now get an error during configure, instead of a just build with non-functioning arrow keys. (If you're a sysadmin, you will catch the issue immediately, rather than your users at some later point...) (On Linux systems, it usually just means that you need to install readline-devel and ncurses-devel packages.) -- 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
Re: [Rd] inconsistent fonts generated in postscript file (PR#7795)
[EMAIL PROTECTED] writes: > Full_Name: Xiang Li > Version: 2.01 > OS: WinXP > Submission from: (NULL) (128.248.174.125) > > > I am trying to use the font of "TT Courier New: bold" to get the equal size of > letters. The "TT Courier New: bold" is the 11th font listed in the Rdevga > file. > > You can just try a simple case: > > plot(1:10, 1:10, xlab = "XILMV", font.lab = 11) > > I save the plot in postscript format, and found the font in .ps file becomes > Arial font. While I save the plot in JPEG or PNG format, everything is > correct. It's not a device independent font so you cannot expect it to be copied between devices. Look at the help page for postscript(). -- 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
Re: [Rd] strange error with rw2010dev
Martin Maechler <[EMAIL PROTECTED]> writes: > >>>>> "PD" == Peter Dalgaard <[EMAIL PROTECTED]> > >>>>> on 11 Apr 2005 09:46:11 +0200 writes: > > . > > MM> Thanks again for the report; this should be fixable > MM> before release. > > PD> Preferably before code freeze! (today) > > PD> I think we (Thomas L.?) got it analysed once before: The > PD> issue is that summary.matrix is passing > PD> data.frame(object) back to summary.data.frame without > PD> removing the AsIs class. > > PD> I don't a simple unclass() will do here. > > or, a bit more cautiously, A "think" fell out in the above... Beware! I think you might want cl <- class(object) class(object) <- cl[cl != "AsIs"] in case the object inherits from other classes. (Then again, it might not be necessary, but better safe than sorry.) > summary.matrix <- function(object, ...) > summary.data.frame(data.frame(if(inherits(object,"AsIs")) unclass(object) > else object), ...) > > That does cure the problem in the Kjetil's example and the equivalent > > ## short 1-liner: > summary(df <- data.frame(mat = I(matrix(1:8, 2 > > > I'm currently make-checking the above. > Martin > -- 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
Re: [Rd] strange error with rw2010dev
Martin Maechler <[EMAIL PROTECTED]> writes: > >>>>> "Kjetil" == Kjetil Brinchmann Halvorsen <[EMAIL PROTECTED]> > >>>>> on Sun, 10 Apr 2005 14:00:52 -0400 writes: > > Kjetil> The error reported below still occurs in todays > Kjetil> (2005-04-08) rw2010beta, should I file a formal bug > Kjetil> report? > > Thank you, Kjetil. > > It seems nobody has found time to look at this in the mean time. > However, > I can confirm the bug on quite a different platform > (Linux Redhat 64-bit on AMD 64). > The problem is infinite recursion which you see more easily, > when you set something like options(expressions=500). > > Further note that the bug is not new, it also happens in > previous versions of R ( -> i.e. no reason to stop using "R 2.1.0 beta"!) > > Here's a ``pure script'' > > testmat <- matrix(1:80, 20,4) > dim(testmat) > # > testframe <- data.frame(testmat=I(testmat), > x=rnorm(20), y=rnorm(20), z=sample(1:20)) > str(testframe) > > options(expressions=100) > summary(testframe) > ##> Error: evaluation nested too deeply: infinite recursion / > options(expression=)? > ## -- or -- > ##> Error: protect(): protection stack overflow > > > ### In the second case, I at least get a useful trace back: > > traceback() ## longish output, shows the infinite recursion: > > .. > ... > > 17: summary.data.frame(data.frame(object), ...) > 16: summary.matrix(object, digits = digits, ...) > 15: summary.default(X[[1]], ...) > 14: FUN(X[[1]], ...) > 13: lapply(as.list(object), summary, maxsum = maxsum, digits = 12, > ...) > 12: summary.data.frame(data.frame(object), ...) > 11: summary.matrix(object, digits = digits, ...) > 10: summary.default(X[[1]], ...) > 9: FUN(X[[1]], ...) > 8: lapply(as.list(object), summary, maxsum = maxsum, digits = 12, >...) > 7: summary.data.frame(data.frame(object), ...) > 6: summary.matrix(object, digits = digits, ...) > 5: summary.default(X[[1]], ...) > 4: FUN(X[[1]], ...) > 3: lapply(as.list(object), summary, maxsum = maxsum, digits = 12, >...) > 2: summary.data.frame(testframe) > 1: summary(testframe) > > > > Thanks again for the report; > this should be fixable before release. Preferably before code freeze! (today) I think we (Thomas L.?) got it analysed once before: The issue is that summary.matrix is passing data.frame(object) back to summary.data.frame without removing the AsIs class. I don't a simple unclass() will do here. -- 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
Re: [Rd] make check-all fails (PR#7784)
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > I think the issue is ATLAS on your old Athlon. ATLAS 3.6.0 compiled > from the sources works correctly with gcc-3.4.3 on my Athlon MP (and > also on an Athlon XP), but AFAIR those have instructions the Athlon > Thunderbird does not have. (Both my machines with such Athlons fried > their motherboards, so I no longer have access to one.) > > Incidentally to Peter: ATLAS 3.7.8 is an unreleased unstable version, > so I would hesitate to recommend it over 3.6.0. To be precise, it's a release on an unstable branch. Hasn't changed since 2004-07-23 though.. But you're right in principle; I had forgotten about that. -- 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
Re: [Rd] make check-all fails (PR#7784)
Peter Dalgaard <[EMAIL PROTECTED]> writes: > Aha! 100 times machine precision in not all that much when the numbers > themselves are in double digits. In fact, one is over 100. The case > that triggers the failure is #149 > > > 147 148 149 151 152 > > -1.598721e-14 -1.065814e-14 -2.842171e-14 -1.065814e-14 -2.131628e-14 > > which is 2 ULP off by my reckoning (scaling 35.15 to be between 0.5 > and 1 makes the error 2.842e-14/64 = 4.44e-16 and [EMAIL PROTECTED] > is 2.22e-16). > > So again, we might be too strict. I just wonder why we haven't heard > of this on any other platforms. I've fixed the precision requirement (for this and the reg-tests-1 issue) in the repository and what should become tomorrow's beta version. -- 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
Re: [Rd] make check-all fails (PR#7784)
"M. Edward (Ed) Borasky" <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > > >This looks more serious. 100 times machine precision is quite a large > >margin in these matters. Could you perhaps stick in a printout of the > >two terms and their difference? > > > >I have an ATLAS build on AMD64 and it passes all the checks, but it is > >using ATLAS 3.7.8, so you might want to try an upgrade. > > > > > Attached ... you actually weren't very far off: ... > > print (f2[common]) > 1 2 3 4 7 8 9 > 32.971099 37.113091 27.472204 16.891921 32.320560 -6.091053 -26.953745 > 12 13 14 15 16 17 18 ... > 41.798651 40.734935 40.285066 24.876177 8.442082 46.373463 72.652242 >118120121122123124125 > 65.983901 81.140660 101.389698 92.784665 86.803528 66.813059 76.464152 >126127128129130131132 > 85.562396 80.164720 55.046451 22.602751 38.602215 35.466808 28.565003 >133134135136137138139 > 30.487396 27.515347 17.475536 49.119123 11.994736 14.701687 49.795201 >140141142143144145146 > 5.664599 24.711067 20.426534 53.013693 5.758723 19.324367 41.190110 >147148149151152153 > 14.189862 -19.275130 35.155615 20.525269 40.584670 18.702940 ... Aha! 100 times machine precision in not all that much when the numbers themselves are in double digits. In fact, one is over 100. The case that triggers the failure is #149 > 147 148 149 151 152 > -1.598721e-14 -1.065814e-14 -2.842171e-14 -1.065814e-14 -2.131628e-14 which is 2 ULP off by my reckoning (scaling 35.15 to be between 0.5 and 1 makes the error 2.842e-14/64 = 4.44e-16 and [EMAIL PROTECTED] is 2.22e-16). So again, we might be too strict. I just wonder why we haven't heard of this on any other platforms. -- 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
Re: [Rd] make check-all fails (PR#7784)
[EMAIL PROTECTED] writes: > Full_Name: Ed Borasky > Version: R-beta 2.1.0 2005-04-08 > OS: Linux 2.6.11 GCC 3.3.5 > Submission from: (NULL) (24.21.57.139) > > > I downloaded the latest R-beta tarball and did a build with the default > options. > OS is Linux 2.6.11 and compiler is GCC 3.3.5. "make check-all" failed with the > following message: > > make[3]: Entering directory `/home/znmeb/R-beta/tests' > running code in 'reg-tests-1.R' ...make[3]: *** [reg-tests-1.Rout] Error 1 > make[3]: Leaving directory `/home/znmeb/R-beta/tests' > make[2]: *** [test-Reg] Error 2 > make[2]: Leaving directory `/home/znmeb/R-beta/tests' > make[1]: *** [test-all-basics] Error 1 > make[1]: Leaving directory `/home/znmeb/R-beta/tests' > make: *** [check-all] Error 2 > > I looked at "tests/reg-tests-1.Rout.fail"; it's 1427 lines long. The error > given > is > > > ## Comments: > > > > > > ## PR 796 (aic in binomial models is often wrong) > > ## > > a1 <- glm(cbind(ncases, ncontrols) ~ agegp + tobgp * alcgp, > + data = esoph, family = binomial())$aic > > a1 > [1] 236.9645 > > a2 <- glm(ncases/(ncases+ncontrols) ~ agegp + tobgp * alcgp, > + data = esoph, family = binomial(), weights=ncases+ncontrols)$aic > > a2 > [1] 236.9645 > > stopifnot(a1 == a2) > Error: a1 == a2 is not TRUE > Execution halted > > I am running on an Athlon Thunderbird with Atlas 3.6.0 installed. If > necessary, > I can back Atlas out and run this again. Hmm, could you replace the a1 == a2 with all.equal(a1, a2) instead? (inside reg-tests-1.R of course) Asking for identity up to machine precision does look a bit optimistic... -- 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
Re: [Rd] R-beta 2004-04-07 build failed on AIX
"Liaw, Andy" <[EMAIL PROTECTED]> writes: > OK, after re-building R with the debug flags, I don't think I'm getting > anything useful. GDB gives me: > > gdb) run --vanilla < /ltmp/try.R > Starting program: /SFS/user/ry/liawand/R/Rbuild/bin/exec/R --vanilla < > /ltmp/try.R Nothing in here?? > Error: [tcsetpgrp failed in terminal_inferior: Not owner] > aix-thread resume: unknown pthread 19 > aix-thread: fetch_registers: pthdb_pthread_context returned CALLBACK > > (gdb) bt > Error: aix-thread: fetch_registers: pthdb_pthread_context returned CALLBACK > > and: > > Unable to Read Instructions at 0x918c6d4 > > Anyone know what these means? Not really, but a couple of thoughts: 1) Why are threads involved? Multi-threaded blas? Can you build without one? 2) If you blew away the stack, the object is to get to the point just before it happened, which means checkpoints, single-stepping and general attempts to bisect the path leading to the point of failure. Can you read the gc_count variable after the crash? It is sometimes useful to conditionalize breakpoints (cond 1 gc_count==1234 etc.) -- 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
Re: [Rd] Problems with predict.lm: incorrect SE estimate (PR#7772)
[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, > >caclulated with predict.lm is incorrect. Consider the following example where > >the standard error is first calculated with predict.lm, then using delta > >method. and finally, using the formula rms*sqrt(1+1/n+(xp-x0)^2/Sxx). > > Your formula is incorrect. You've got the formula for the so called > "prediction error" (i.e. the stddev of the difference between the > prediction and a new observation) rather than the "standard error" > (i.e. the stddev of the prediction). And: > print(predict(a,new=data.frame(x=xp),interval="pred")) fit lwr upr [1,] 3.009091 2.794523 3.223659 > 3.009091 + qt(.975,8)*0.09304758 [1] 3.223659 > 3.009091 - qt(.975,8)*0.09304758 [1] 2.794523 so reading the help page might have given a clue that the authors knew what they were doing The help page text could be improved, though. Will do. > >$fit > >[1] 3.009091 > > > >$se.fit > >[1] 0.0359752 > > > >$df > >[1] 8 > > > >$residual.scale > >[1] 0.08581163 > > > >> print(se.delta.method <- sqrt(s[1,1]+xp^2*s[2,2]+2*xp*s[1,2] + rms^2)) > >[1] 0.09304758 > >> print(se.ss.formula <- rms*sqrt(1+1/n+(xp-xm)^2/sum((x-xm)^2))) > >[1] 0.09304758 -- 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
Re: [Rd] Error: cannot set length of non-vector
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.
>
> Note that this is *NOT* an error thrown by R CMD check. The failure
> occurs when checkVignettes() is running the code (via source()) of the
> .R files created via Stangle(), and all the info we have about the error
> is being passed on.
Aha, so *that's* how to reproduce it.
One thing that catches my eye is that
tools::checkVignettes has
outConn <- textConnection("out", "w")
sink(outConn, type = "output")
sink(outConn, type = "message")
for (f in rfiles) {
yy <- try(source(f))
and demo.R does extensive manipulation of an object called "out".
Perhaps it helps to do something like local(source(f, local=TRUE))? Or
maybe put local=TRUE in the textConnection() call.
--
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
Re: [Rd] Error: NAs are not allowed in subscripted assignments: change from R.1.9
"Vadim Ogranovich" <[EMAIL PROTECTED]> writes: > Hi, > > There seems to be a change in 2.0.1 in the workings of subscript > assignments with missing values. > > > # This is R.2.0.1 > > # assignment w/ missing index doesn't work when right-hand-side is a > matrix. It did work in 1.9.1 > > x = matrix(1, 2, 2); x[c(1,NA),] = x > Error: NAs are not allowed in subscripted assignments > # it does work for a vector > > x = matrix(1, 2, 2); x[c(1,NA),] = 1 > > Is this change intentional? There seems to be nothing about it in the > release notes. Yes, and oh yes there is, for the version where it changed, in ONEWS: o Subassignments involving NAs and with a replacement value of length > 1 are now disallowed. (They were handled inconsistently in R < 2.0.0, see PR#7210.) For data frames they are disallowed altogether, even for logical matrix indices (the only case which used to work). -- 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
Re: [Rd] Alpha releases from Copenhagen not mirrored?
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > On 3 April 2005 at 15:18, Dirk Eddelbuettel wrote: > | > | Looking at http://cran.r-project.org/src/base-prerelease shows that the > | latest alpha tarball is dated April 1. That page reveals its source via the > | various ?D=A etc sorting links, and looking at Peter's page at > | www.biostat.ku.dk, I do indeed see April 2 and 3 releases in Denmark. Has > | anything dropped in Vienna? > > I guess I could have checked before posting, but it looks like the error is > in .dk rather than in .at: > > [EMAIL PROTECTED]:~/src/debian/R> wget > http://www.biostat.ku.dk/~pd/R-pre/R-alpha_2005-04-03.tar.gz > --15:22:19-- http://www.biostat.ku.dk/%7Epd/R-pre/R-alpha_2005-04-03.tar.gz >=> `R-alpha_2005-04-03.tar.gz' > Resolving www.biostat.ku.dk... 192.38.18.114 > Connecting to www.biostat.ku.dk[192.38.18.114]:80... connected. > HTTP request sent, awaiting response... 403 Forbidden > 15:22:20 ERROR 403: Forbidden. Odd... There have been various issues causing the tarball build to fail occasionally. The Subversion database go itself wedged Saturday, which is the usual mod of failure, but this morning it was a collision with a temp dir in /tmp. When it happens, I run the build script by hand, but obviously not at 5am, so the CRAN mirroring might not pick it up. However, permissions are also different between cron-built tarballs and the manual ones. Looks like someone changed my umask to 0027 in a shell startup file... -- 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
Re: [Rd] Solaris10/amd64 + SunSutio Compile (PR#7767)
[EMAIL PROTECTED] writes: > Full_Name: Teru KAMOGASHRIA > Version: 2.0.1 > OS: SunOS sun 5.10 Generic i86pc i386 i86pc > Submission from: (NULL) (219.5.176.24) > > > rbinom.c cannot be compiled because of the casting problem. > > /opt/SUNWspro/bin/cc -I. -I../../src/include -I../../src/include > -I/usr/local/include -DHAVE_CONFIG_H -D__NO_MATH_INLINES -g -c rbinom.c -o > rbinom.o > "rbinom.c", line 60: operand must have real floating type: op "isfinite" > cc: acomp failed for rbinom.c > > Following patch may solve this problem. > > *** R-2.0.1.orig/src/nmath/rbinom.c Mon Nov 15 21:33:01 2004 > --- R-2.0.1/src/nmath/rbinom.c Sun Apr 3 00:19:52 2005 > *** > *** 57,63 > n = floor(nin + 0.5); > if (n != nin) ML_ERR_return_NAN; > > ! if (!R_FINITE(n) || !R_FINITE(pp) || > /* n=0, p=0, p=1 are not errors */ > n < 0 || pp < 0. || pp > 1.)ML_ERR_return_NAN; > > --- 57,63 > n = floor(nin + 0.5); > if (n != nin) ML_ERR_return_NAN; > > ! if (!R_FINITE((double)n) || !R_FINITE(pp) || > /* n=0, p=0, p=1 are not errors */ > n < 0 || pp < 0. || pp > 1.)ML_ERR_return_NAN; Hmm... But does it at all make sense to pass an integer to R_FINITE? and why isn't there a prototype causing automatic casting anyway? -- 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
Re: [Rd] An exercise in the use of 'substitute'
Douglas Bates <[EMAIL PROTECTED]> writes: [..snip..] > However, I haven't been able to work out a clever way of using > substitute to get the first part. I would like to be able to call, > e.g. > > with(fm, xyplot(resid(.) ~ carb)) > > and get a plot of resid(fm) ~ Formaldehyde$carb > > It is possible to do the first part by deparsing, substituting, and > parsing but that's inelegant. Can anyone suggest a more elegant > method? Here's part of one, I think: > w <- function(x,y)eval(substitute(substitute(y,list(.=quote(x) > w(fm, xyplot(resid(.) ~ carb)) xyplot(resid(fm) ~ carb) (The double substitute is often needed in this type of problem. Things would be easier if we had a version of substitute that didn't automatically quote it's argument.) -- 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
Alpha releases Re: [Rd] trouble building r-devel
<[EMAIL PROTECTED]> writes: > I haven't been able to build yesterday's R-devel (or, as a test, > R-devel_2005-03-11) on Windows XP. The error message I'm getting is to > do with 'arithmetic.c', as shown below. Apropos: The release process for 2.1.0 has now started and we are putting up alpha tarballs in (e.g.) http://cran.r-project.org/src/base-prerelease/R-alpha_2005-03-22.tar.gz These tarballs are made using the same procedure as we intend to use for the final release. It would be good if you'd try building from these sources (rather than the daily snapshots) so that we may catch any packaging errors in time. -- 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
Re: [Rd] FW: R Process Killed out of logical swap space: Case id #259-4945 (PR#7732)
[EMAIL PROTECTED] writes:
> Dear Professor Ripley,
Ummm, "PR" is for "Problem Report", not "Professor Ripley"
> I am attempting a large scale mixed-model analysis of longitudinal gene
> array data using R. I use a 64-bit SGI with 7GB available RAM and 40G
> logical swap space together with unlimited virual swap space. The OS is IRIX
> 6.5.24. I use R version 1.9.0 since I have had problems upgrading to R 2.0.1
> at 64-bit using native SGI compiler build.
>
> I write a serial for (i in 1:length(y)) { }
> containing the call to lme as follows
>
> f1<-lme( expr ~ time + age + sex,random = ~ time | id,
> correlation=cs3,data=gg.data.frame,method="ML",weights=varIdent(form= ~id))
>
> After ~ 200 - 300 loops the process is killed by the OS with the following
> errors
>
> Mar 17 08:55:56 1A:helmholtz unix: ALERT: R.bin [1157] - out of logical swap
> space during stack growth - see swap(1M) [filter /usr/sbin/klogpp failed:
> killed by signal 9]
> Mar 17 08:55:56 1A:helmholtz unix: ALERT: R.bin [1157] - out of logical swap
> space during stack growth - see swap(1M)
> Mar 17 08:55:56 1A:helmholtz unix: ALERT: R.bin [1157] - out of logical swap
> space during stack growth - see swap(1M)
> Mar 17 08:55:56 1A:helmholtz unix: ALERT: R.bin [1157] - out of logical swap
> space during stack growth - see swap(1M)
> Mar 17 08:55:56 1A:helmholtz unix: |$(0x6dc)ALERT: Process [R.bin] pid 1157
> killed: not enough memory to grow stack
> Mar 17 08:55:56 1A:helmholtz unix: |$(0x6dc)ALERT: Process [R.bin] pid 1157
> killed: not enough memory to grow stack
> Mar 17 08:55:56 1A:helmholtz unix: ALERT: syslogd[1642] was killed; Dynamic
> Loader cannot get enough memory to map exe
> Mar 17 08:55:56 1A:helmholtz unix: ALERT: syslogd[1642] was killed; Dynamic
> Loader cannot get enough memory to map exe
> Mar 17 08:55:56 1A:helmholtz unix: ALERT: syslogd [1642] - out of logical
> swap space during exec - see swap(1M)
> Mar 17 08:55:56 1A:helmholtz unix: ALERT: syslogd [1642] - out of logical
> swap space during exec - see swap(1M)
>
> I have observed the crash while examining the system memory and stack
> allocations - these do not appear to be growing during execution of the
> process loops. I have checked with SGI and the view is that this is likely
> related to R. While there are several work-arounds it would be ideal to
> 'batch' this job and further it is unclear to me what is happening. I am
> grateful for your attention and potential insights.
Hmm, I agree that this could well be a bug in R or the nlme package.
Sounds like a single huge memory allocation is attempted, which could
fairly easily happen as the result of a random memory overwrite.
However, it is not attractive to try and find bugs in old versions of
R (several bugs of this general variety have been fixed since 1.9.1),
and it is near impossible to find such bugs without a way of
reproducing the conditions. I.e. you are the one with the motivation
and probably also the only person with the means to pinpoint the bug.
Can you run your code under a debugger?
--
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
Re: [Rd] Lemon drops
Marc Schwartz <[EMAIL PROTECTED]> writes: > On Tue, 2005-03-15 at 18:05 +0100, Peter Dalgaard wrote: > > I bumped into the following situation: > > > > Browse[1]> coef > > deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP > > (Intercept)462510528492660762 > > Browse[1]> coef[,1] > > [1] 462 > > Browse[1]> coef[,1,drop=F] > > deg0NA > > (Intercept)462 > > > > where I really wanted neither, but > > > > (Intercept) > > 462 > > > > Anyone happen to know a neat way out of the conundrum? > > > > I can think of > > > > rowSums(coef[,1,drop=F]) > > > > or of course > > > > val <- coef[,1] > > names(val) <- rownames(x)) > > > > but the first one is sneaky and the second gets a bit tedious... > > Peter, > > How about something like this: > > > x > deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP > (Intercept)462510528492660762 > IV1 1 2 3 4 5 6 > > > > x[1] > (Intercept) > 462 > > > str(x[1]) > Named num 462 > - attr(*, "names")= chr "(Intercept)" > > > Does that work or am I missing something? You're missing the context. What I really need is something that will extract a column of a matrix as a vector in the usual way, but will not get confused if there is only one row. -- 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
[Rd] Lemon drops
I bumped into the following situation: Browse[1]> coef deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept)462510528492660762 Browse[1]> coef[,1] [1] 462 Browse[1]> coef[,1,drop=F] deg0NA (Intercept)462 where I really wanted neither, but (Intercept) 462 Anyone happen to know a neat way out of the conundrum? I can think of rowSums(coef[,1,drop=F]) or of course val <- coef[,1] names(val) <- rownames(x)) but the first one is sneaky and the second gets a bit tedious... -- 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
Re: [Rd] unexpected behaviour of expression(sum())
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > So my guess on scalable fonts was right. > > I suspect this is a problem in how the X server is using Type1 fonts, > specifically in how it thinks they are encoded. This is why I asked > about the locale: \summation is \345 in the Adobe symbol character set > and \circleplus is \305 which is a u/case to l/case difference in > Latin-1. Well, the X server is defenseless against people aliasing fonts with incompatible encodings... > I now recall Kurt had similar problems with gsfonts-x11 last August: > > >> Kurt has found a problem with the last two pages of demo(plotmath) on > >> X11 (some symbols either wrong or missing completely). > > We found > > >> the issue seems to be that gsfonts-x11 has aliases > >> > >> -adobe-symbol-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific > "-urw-standard symbols l-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific" > >> "-urw-standard symbols l-regular-r-normal--0-0-0-0-p-0-adobe-fontspecific" > >> "- > urw-standard symbols l-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific" > > >> Any way to ensure that these fonts are not taken by us? > > > I don't think so, for if I understand that the alias file is lying about > > encodings. We specifically added "-adobe-symbol" to overcome problems with > > abi symbol fonts at ETHZ, but if that package says the urw fonts in > > `standard symbols l' are in adobe symbol and they are not, you are in > > trouble. > ...as previously noted, it seems (who are you citing there?). I vaguely recall some messup with the GS fonts on Fedora 3 (making xpdf misbehave on slides) but it seems to have been resolved long ago. -- 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
Re: [Rd] Incorrect calculation of loop in R.2.0.1 (PR#7724)
[EMAIL PROTECTED] writes: > Full_Name: Ms. Drakes > Version: 2.01 2.0.1, I guess- > OS: Windows XP > Submission from: (NULL) (4.237.32.239) > > > file="C:/glob.csv" > glob=read.csv(file,header=T) > > y=glob$Temperature > > > z=max(y[1:40]) > # this has a probability of exceedance of 1/41 > # now you can check how this does in the 2nd sample - > sum=0 > for i = 41:100 if (z>y[i]sum=sum+1 That's not how you specify a for loop in R. Please read up on the syntax, e.g. in "An Introduction to R" > sum > sum=sum/60 > sum > > > error: the loop i=41:100 does not work correctly, only if information after > "if" > is enclosed in parentheses It is not a bug in R that your program does not work correctly. Please do not abuse the bug report system like that. -- 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
Re: [Rd] Bug in handling of promises?
Duncan Murdoch <[EMAIL PROTECTED]> writes:
[snip]
> So I tried to explicitly force it:
>
> > g <- function( H, prevEnv = NULL) {
> + if (!is.null(prevEnv)) H <- prevEnv$H
> + force(H)
> + return(environment(NULL))
> + }
>
> but this still doesn't work:
>
> > env <- g( function(x) x^2 )
> > env$H
>
> > env$H(1)
> Error: attempt to apply non-function
>
> It seems that I need to do an assignment to convert H from a promise
> to an evaluated object:
>
> > h <- function( H, prevEnv = NULL) {
> + if (!is.null(prevEnv)) H <- prevEnv$H
> + H <- H
> + return(environment(NULL))
> + }
> > env <- h( function(x) x^2 )
> > env$H
> function(x) x^2
> > env$H(1)
> [1] 1
>
> Is this a bug, or just the way things are?
>
> I get the same results in both R-patched and R-devel.
Hmm, I don't think it is a bug as such that a promise in a function
environment stays a promise. Otherwise the semantics of substitute()
get messed up. However, it is a bit peculiar that the evaluator
doesn't extract the value when such an object is encountered in an
expression. Apparently (conjecture!) this is only done during variable
lookup, but not on return values from functions:
> env <- g( 2 )
> env$H+2
Error in env$H + 2 : non-numeric argument to binary operator
> with(env,H+2)
[1] 4
> x <- env$H
> x+2
[1] 4
--
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
[Rd] R 2.1.0 scheduled for April 18
The release schedule has now been set with a release date on April 18. The detailed procedure can be found at http://developer.r-project.org/ (it is not quite there yet, but will appear after a short propagation delay.) The main point for non-developers is that we start making alpha tarballs on March 21 and beta tarballs on April 4. Only very simple and/or critical bugs are fixed in the last week before release. As usual, we encourage users to build and test the pre-release, and help us find and fix bugs before rather than immediately after the release. For the R Core Team Peter Dalgaard -- 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
[Rd] Re: [R] H-F corr.: covariance matrix for interaction effect
Peter Dalgaard <[EMAIL PROTECTED]> writes: > Where I would have expected > > > (20*5*0.6917-2)/(5*(19-5*.6917)) > [1] 0.8643953 > > Does anyone have a clue as to what is going on here? Is mighty SAS > simply doing the wrong thing? The G-G epsilon depends only on the > eigenvalues of the observed covariance matrix, so surely the H-F > correction should depend only on the dimension and the DF for the > empirical covariance matrix? Just in case anyone was wondering, I think I now know what SAS is doing, and yes, it is a bug. The HF correction is HFeps = (n * (k-1) * GGeps - 2) / ((k-1) * ((n-1) - (k-1) * GG.eps)) for the simple two-way layout, where the residual SSD matrix has (n-1) degrees of freedom. For the case with covariates, it looks like (to 4 significant digits) SAS is generalizing the above to HFeps = (n * (k-1) * GGeps - 2) / ((k-1) * (f - (k-1) * GG.eps)) where f is the degrees of freedom for the SSD. However, the first n also needs adjustment; the correctly generalized formula should read HFeps = ((f+1) * (k-1) * GGeps - 2) / ((k-1) * (f - (k-1) * GG.eps)) (The G-G epsilon is essentially the squared mean of the eigenvalues of a suitably transformed SSD divided by the mean of the squares of the eigenvalues. This is less than one unless all eigenvalues are identical. H-F replaces numerator and denominator with bias-corrected variants. However, since everything is a function of the SSD matrix, sthe formula can only depend on n via the degrees of freedom.) -- 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
Re: [Rd] Getting width of Tk text widget via tcltk
"John Fox" <[EMAIL PROTECTED]> writes:
> Dear Peter,
>
> As you can see from the expression, I didn't use integer division, nor did I
> round() or floor(). Here's my original example, using a monospaced font:
>
> > library(tcltk)
> > top <- tktoplevel()
> > textWindow <- tktext(top, bg="white", height=20, width=80, wrap="none",
> + font=tkfont.create(family="courier", size=10))
> > tkgrid(textWindow, sticky="news")
>
> > tkgrid.rowconfigure(top, 0, weight=1)
>
> > tkgrid.columnconfigure(top, 0, weight=1)
>
> > tkcget(textWindow, width=NULL)
> 80
> > tkwinfo("width", textWindow$ID)
> 646
> >
> > (as.numeric(tkwinfo("width", textWindow$ID))
> + - 2*as.numeric(tkcget(textWindow, borderwidth=NULL)) - 4) /
> + as.numeric(tkfont.measure(tkcget(textWindow, font=NULL), "0"))
> [1] 79.75
> >
> > (as.numeric(tkwinfo("width", textWindow$ID))
> + - 2*as.numeric(tkcget(textWindow, borderwidth=NULL)) - 2) /
> + as.numeric(tkfont.measure(tkcget(textWindow, font=NULL), "0"))
> [1] 80
>
> I believe that the right answer is 80, and this appears correct visually,
> confirmed by typing in the window.
Interesting...
> tkwinfo("width", textWindow)
488
> (as.numeric(tkwinfo("width", textWindow))
+ - 2*as.numeric(tkcget(textWindow, borderwidth=NULL)) - 4) /
+ as.numeric(tkfont.measure(tkcget(textWindow, font=NULL), "0"))
[1] 80
> (as.numeric(tkwinfo("width", textWindow))
+ - 2*as.numeric(tkcget(textWindow, borderwidth=NULL)) - 2) /
+ as.numeric(tkfont.measure(tkcget(textWindow, font=NULL), "0"))
[1] 80.3
Notice, btw, that textWindow$ID shouldnn't be necessary.
--
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
Re: [Rd] Getting width of Tk text widget via tcltk
"John Fox" <[EMAIL PROTECTED]> writes:
> Dear Peter,
>
> (as.numeric(tkwinfo("width", .output$ID))
> - 2*as.numeric(tkcget(.output, borderwidth=NULL)) - 2)/
> as.numeric(tkfont.measure(tkcget(.output, font=NULL), "0"))
>
> (for the text widget .output) appears to do the trick (note, subtracting 2
> rather than 4).
Hmm, that's odd. I needed the 4. Beware that Tcl does integer division
(%/%). Did you round() or floor() the result?
--
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
Re: [Rd] Getting width of Tk text widget via tcltk
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > > 743 > > > > I could convert pixels to characters, but wonder whether I can get the > > latter directly. > > I suspect you may have some difficulty with the latter, even in a > monospace font. Notice that 486 is not a multiple of 80, and if that > is actually 81, 743 is not a multiple of 6. > > I was trying to do this with heights for a listbox a few days ago, and > it seems that the line spacing is actually 1 pixel greater than is > reported. Since you can resize to a non-integer number of lines I > don't believe (and I tried to read the source code) that Tcl/Tk works > internally with characters. I think that's actually an issue that involves the window manager too. I don't think all WMs know how to deal in integer number of characters. Anyways, the following piece of Tcl seems to do the trick: % expr ([winfo width .a] - 2 * [.a cget -borderwidth] - 4)/[font measure [.a cget -font] 0] 27 Converting to R is left as an exercise... If I got it right then the point is that at either side of the window you have by 1 pixel, n border pixels, and 1 spacer pixel before the first character. -- 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
[Rd] Re: [R] H-F corr.: covariance matrix for interaction effect
Peter Dalgaard <[EMAIL PROTECTED]> writes: > Bela Bauer <[EMAIL PROTECTED]> writes: > > > Hi, > > > > I'm still not quite there with my H-F (G-G) correction code. I have it > > working for the main effects, but I just can't figure out how to do it > > for the effect interactions. The thing I really don't know (and can't > > find anything about) is how to calculate the covariance matrix for the > > interaction between the two (or even n) main factors. > > I've looked through some books here and I've tried everything that came > > to my mind, but I can't seem to be able to figure out an algorithm that > > does it for me. > > > > Could anyone give me a hint about how I could do this? > > (I'll append my code at the end, in case that helps in any way...) > > I have given it to you before: My plan is to drop the explicit formula > involving on/off diagonal elements of S and go directly at Box (1954), > theorems 3.1 and 6.1, involving eigenvalues of TST', where T is the > relevant residual operator. In the case where one of the factors have > only two levels, I believe you just take differences and use the usual > formula, but more than two levels is tricky. [moved to r-devel since this is getting technical] Now I am getting confused: I can reproduce the G-G epsilon in all the cases I have tried but the H-F epsilon eludes me. Consider this SAS code proc glm; model bmc1-bmc7= / nouni; repeated visit 7/printe; This ends up with Greenhouse-Geisser Epsilon0.6047 Huynh-Feldt Epsilon 0.7466 This makes OK sense since there are 22 observations > (22*6*0.6047 -2)/(6*(21-6*.6047)) [1] 0.7466162 However, consider the following small change: proc glm; class grp; model bmc1-bmc7= grp / nouni; repeated visit 7/printe; Now I get Greenhouse-Geisser Epsilon0.6677 Huynh-Feldt Epsilon 0.8976 Since we have one less DF for the covariance matrix, I would expect that the H-F epsilon would be > (21*6*0.6677)/(6*(20-6*.6677)) [1] 0.876696 The discrepancy gets worse as more covariates are added. If bmc1 is moved to the rhs, I get Greenhouse-Geisser Epsilon0.6917 Huynh-Feldt Epsilon 0.9533 Where I would have expected > (20*5*0.6917-2)/(5*(19-5*.6917)) [1] 0.8643953 Does anyone have a clue as to what is going on here? Is mighty SAS simply doing the wrong thing? The G-G epsilon depends only on the eigenvalues of the observed covariance matrix, so surely the H-F correction should depend only on the dimension and the DF for the empirical covariance matrix? -- 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
Re: [Rd] bug report for as.function (PR#7702)
[EMAIL PROTECTED] writes:
> Hi,
>
> I got the following message in R:
> Error in as.function.default(pdfs[1]) : invalid body argument for "function"
> Should NEVER happen; please bug.report() [mkCLOSXP]
Actually, I think that the only bug here is in the error message
(which presumably predates as.function()). If you can perform
arbitrary voodo and try to convert it into a function, then of course
you can also end up with an invalid body.
> Operating System: Windows XP (SP2)
> R version: R-2.0.1
> Code causing error follows:
>
> # create two probability density functions for mixtures of normal
> distibutions
> fmix1 <- function(x) {dnorm(x, mean=4, sd=2) * 0.5 + dnorm(x, mean=7,
> sd=1) * 0.5}
> fmix2 <- function(x) {dnorm(x, mean=3, sd=1) * 0.4 + dnorm(x, mean=6,
> sd=2) * 0.6}
>
> # put them together
> pdfs <- c(fmix1, fmix2)
>
> # perhaps this is not as it was intended but it leads to the bug.report
> message
> as.function(pdfs[1])
>
> Meanwhile I solved this problem otherwise.
> Hope this helps.
> Timo
>
> __
> R-devel@stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
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
Re: [Rd] eapply weirdness/bug
Luke Tierney <[EMAIL PROTECTED]> writes:
> For this specific case though, I _think_ the semantics we want is this:
>
> eapply1 <- function(env, FUN, ..., all.names = FALSE) {
> FUN <- match.fun(FUN)
> lapply(.Internal(env2list(env, all.names)), FUN, ...)
> }
>
> Not passing the ... in the current implementation is, I think, an
> oversight, as is the extra evaluation that occurs. Given that lapply
> is already internal I'm not sure there really is very much benefit in
> having the internal eapply. If not I'd prefer to replace it by
> something like this; if there are reasons for keeping the .Internal we
> can work on replicating these semantics as closely as possible. I
> think Robert is the one who would know the issues.
I agree on the semantics (I didn't quite think of the consequences of
FUN doing an eval.parent and things like that before). But if
implemented literally, wouldn't that env2list cause some undesirable
copying? I have the impression that people interested in eapply use
their environments to hold some pretty large objects. So maybe we
should stick with the get()-based version
eapply2 <- function(env, FUN, ..., all.names = FALSE) {
FUN <- match.fun(FUN)
nm <- ls(envir=env,all.names=all.names)
FUN2 <- function(name,...)FUN(get(name),...)
lapply(nm, FUN2, ...)
}
--
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
Re: [Rd] eapply weirdness/bug
Luke Tierney <[EMAIL PROTECTED]> writes: > looks like eapply has an extra eval in the code. It does because the > code creates a call of the form > > FUN() > > with the literal value in place and then calls eval on this, which > results in calling eval on value. The internal lapply in contrast > creates a call of the form > > FUN([[]]) > > and evals that. This causes the literal and values to > be evaluated, which is OK since they are guaranteed to be a list > (generic vector) and integer vector and so evaluate to themselves, and > the call to [ is then evaluated, returning what is in the list at the > appropriate index and passing that, without further evluation, to FUN. > The semantics we want in eapply is I think equivalent to creating > > FUN(get(, )) Or, as I was suggesting, eval(substitute(F(x), list(F=FUN,x=as.name(e)), envir) > and evaluating that, but we are not getting this. Direct use of this > would be less efficient that the current approach, but using > > FUN(quote()) > > as the constructed call should do the trick. You have to be careful only to do this if the value is of mode "call", I think. Or is quote always a no-op in the other cases? I'm getting a bit fond of the the solution that I had because it will also work if the FUN uses deparse(substitute()) constructions, and once you're at the level of constructing calls via LCONS() it isn't really inefficient either. Extra arguments could be a bit of a bother though. (What happens to those currently?? The function doesn't seem to pass them to .Internal.) -- 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
[Rd] Suggestions for enhanced routines for "mlm" models.
Dear R-devel'ers Below is an outline for a set of routines to improve support for multivariate linear models and "classical" repeated measurements analysis. Nothing has been coded yet, so everything is subject to change as loose ideas get confronted by the harsh realities of programming. Comments are welcome. They might even influence the implementation... -pd General considerations: - S3 class based to fit existing code - similar to lm/glm code fit <- lm(Y~...) creates basic mlm object (already does) SSD(obj) returns object of class "SSD": $SSD matrix of sums of squares & products $df degrees of freedom. Methods for (lm and) mlm. estVar(obj) obj$SSD/obj$df (could have methods for lm/mlm too) Convenience functions: Tr is the trace operator sum(diag(M)) proj is the projection operator possibly generalized to matrices. Rg: matrix rank (not sure we really need it, but see below) mauchley.test(obj, M=diag(ncol=p), T = proj(X, orth=TRUE), X = matrix(rep(1,p))) (p = ncol(obj$SSD)) Test of sphericity, i.e. that the obj represents a empirical covariance matrix S with true value proportional to M or that TST' is proportional to TMT'. Alternatively, give X with the property that TX == 0. (One sticky bit is that you can't really just use proj() because T must have maximal rank. What is the current best practice for dealing with that? qr() pivoting?) summary.mlm print.summary.mlm vcov.mlm summary.mlm could be a little smarter than just coordinatewise summary.lm. It could at least provide the estimated residual covariance matrix (or SSD structure). vcov currently inherits from "lm" leading to a completely arbitrarily scaled matrix. The correct matrix is a Kronecker product of the unscaled covariance matrix and estVar. anova.mlm, anova.mlmlist, drop1.mlm, add1.mlm These can (seemingly...) be obtained by relatively small modifications of their lm counterparts. The actual test calculations need to be excised from summary.manova (generalize? e.g. mvlin.test(SSD1, SSD2, method="Pillai")). It should be possible to wedge in tests under sphericity assumptions (with Greenhouse-Geisser and Huynh-Feldt corrections), as well as transformation/conditioning matrices (see below). A more radical idea is to say that these are all different kinds of MANOVA tables and extend the *.manova functions to understand them. This would break the symmetry with lm, though, since you then need to use summary() to get a meaningful listing. Notes on conditional tests (lower priority): Consider Y = (Y1,Y2) and a linear hypothesis matrix H. The test of zero intercept in the (multivariate) regression of H %*% Y2 on H %*% Y1 is of some interest, possibly after a linear transformation of Y. This is the test for additional information, but it is also the correct (ML) way of utilizing known-zero effects, e.g. pretreatment measurements. There is even a neat trick to fitting a linear structure across the responses by regressing on null-space contrasts. To some extent, conditional tests can be handled just by moving variables to the r.h.s. of the linear model specification, but there might be a point in having a more evocative interface, especially where transformed Y's are involved. This could be formula-based or matrix-based: contrasts=ginv(contr.sdif(4)) or formula based: ystruct=~index. -- 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
Re: [Rd] eapply weirdness/bug
<[EMAIL PROTECTED]> writes: > The following looks like an 'eapply' bug to me: > > t/subtest> e <- new.env() > t/subtest> e$tempo <- quote( 1+'hi') > > t/subtest> lapply( ls( e), function( x) length( get( x,e))) > [[1]] > [1] 3 > # seems reasonable-- e$tempo is a 'call' object of length 3 > > t/subtest> eapply( e, length) > Error in 1 + "hi" : non-numeric argument to binary operator > > t/subtest> eapply( e, length) > t/subtest> traceback() > 1: eapply(e, length) > > For some reason 'eapply' seems to *evaluate* objects of mode 'call' (it > happened with every call-mode object I tried). This shouldn't happen-- > or should it? It's probably related to the fact that > eval(substitute(length(x),list(x=e$tempo))) Error in 1 + "hi" : non-numeric argument to binary operator I.e., you cannot construct calls with a mode call argument by substituting the value of the mode call object. (Got that? Point is that the substitute returns quote(length(1+"hi"))) It is not clear to me that there is a nice way of fixing this. You probably need to construct calls of the form FUN(env$var) -- I suspect that with(env, FUN(var)) or eval(FUN(var), env) would looking for trouble. Hmm, then again, maybe it could work if FUN gets inserted as an anonymous function... -- 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
mapply(), was Re: [Rd] sprintf
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > sprintf() in R-devel is now vectorized, re-cycling its arguments, > including fmt, as required. Thanks, Brian. This leaves me with one question: what is actually the wisdom behind the USE.NAMES default in mapply? Seems to me that it gets in the way more often that it is useful (and has some real problems with recycling, clearly). Thomas? > >>> mapply(sprintf, "%04d %s", 1:3, "abc", USE.NAMES=FALSE) > >> [1] "0001 abc" "0002 abc" "0003 abc" > >> if (USE.NAMES && length(dots) && is.character(dots[[1]]) && > >> is.null(names(answer))) > >> names(answer) <- dots[[1]] > >> ) -- 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
Re: [Rd] sprintf - was formatC with illegal input crashes Rgui (PR#7686)
Wolfgang Huber <[EMAIL PROTECTED]> writes: > Personally, I would prefer the recycling, but of course it can be also > done this way: > > > mapply(sprintf, "%04d %s", 1:3, "abc") > %04d %s > "0001 abc" "0002 abc" "0003 abc" > > the only slightly unaesthetic thing being the names of the resulting vector. ...which is of course fixable with either of > mapply(sprintf, MoreArgs=list(fmt="%04d %s"), 1:3, "abc") [1] "0001 abc" "0002 abc" "0003 abc" > mapply(sprintf, 1:3, "abc", fmt="%04d %s") [1] "0001 abc" "0002 abc" "0003 abc" > mapply(sprintf, "%04d %s", 1:3, "abc", USE.NAMES=FALSE) [1] "0001 abc" "0002 abc" "0003 abc" (Only the last one is completely failsafe since the first two relies on 1:3 not being character: if (USE.NAMES && length(dots) && is.character(dots[[1]]) && is.null(names(answer))) names(answer) <- dots[[1]] ) -- 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
Re: [Rd] Bug in cor function (PR#7689)
[EMAIL PROTECTED] writes:
> I can't hardly accept the result of cor function with
> pairwize.colplete.obs or complete.obs
>
> insert print statements in cor function,
>
>
> + if (method != "pearson") {
> + Rank <- function(u) if (is.matrix(u))
> + apply(u, 2, rank, na.last = "keep")
> + else rank(u, na.last = "keep")
> + x <- Rank(x)
> + print(x) # add
> + if (!is.null(y)) {
> + y <- Rank(y)
> + print(y) # add
> + }
> + }
> + .Internal(cor(x, y, na.method, method == "kendall"))
>
> and, data is
> > x <- c(7, 9, 8, 0, NA, NA)
> > y <- c(2, 3, 4, NA, 4, 3)
>
> and, call cor function
> > cor(x, y, use="pair", method="sp")
>
> order of x, and y are
> [1] 2 4 3 1 NA NA
> [1] 1.0 2.5 4.5 NA 4.5 2.5
>
> alas!! and the result is
> [1] 0.4271211
>
> oh! no!!
>
> the result must be 0.5
And which part of the following did you fail to understand?
For 'cov()', a non-Pearson method is unusual but available for
the sake of completeness. Note that '"spearman"' basically
computes 'cor(R(x), R(y))' (or 'cov(.,.)') where 'R(u) := rank(u,
na.last="keep")'. Notice also that the ranking is (currently) done
removing only cases that are missing on the variable itself, which
may not be what you expect if you let 'use' be '"complete.obs"' or
'"pairwise.complete.obs"'.
If you have improved code to contribute, you're welcome (notice that
this requires reranking for every pair of variables in an n x n
correlation matrix in the pairwise case), but there's really not much
point in reporting issues that are already known and documented.
--
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
Re: [Rd] getAnywhere and functions starting with "." (PR#7684)
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > Were you unaware that the NEWS file is browsable at > > https://svn.r-project.org/R/trunk/NEWS > > ? (At least if the SVN server has not tied itself in a knot again...) Also note that the Subversion log at developer.r-project.org has all commits, with somewhat informative comments, e.g. - r33006 | pd | 2005-02-03 18:23:41 -0500 (Thu, 03 Feb 2005) | 1 line Changed paths: M /trunk/NEWS M /trunk/src/library/utils/R/objects.R getAnywhere got confused ----- -- 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
Re: [Rd] Pipe / Fork: Partial Solution / Providing Connections from C?
"Jan T. Kim" <[EMAIL PROTECTED]> writes: > > Well, that is probably reasonably easy, but (not the least due to that > > fact) I'm still surprised that it has not been done already. I can hardly > > imagine that I'm the first one to want to use some external utility from > > an R program in this way. > > > > So, what do you R-devel folks do in this case, and what would you > > recommend? > > I'm still curious about this one. If there really is no way of running > stuff through external filter processes in R, I'd volunteer to add > that. > > Best regards & thanks in advance, Jan If you know how, please do. I have a suspicion it might not be as easy as it sounds because of the producer/consumer aspects. Notice, though, that in most cases you can get by with system() or pipe() and a temporary file for either the input or the output. I remember speculating about these matters when I was first introduced to pipes in C: They'd show you how to open a pipe for reading and how to do it for writing, but not how to do both with the same process. Took me a while to realize that there is a nontrivial deadlock issue if you try to write to a process that itself is blocked trying to write its output. Now that is of course not to say that it cannot be done with clever multiplexing and buffering techniques -- or multithreading, except that R isn't threaded. BTW, we met in Heidelberg at the ECMBM ages ago, didn't we? -- 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
Re: [Rd] install issue | suse 9.2
It's not endemic to suse 9.2 (compile running as I write this). Google finds some messages from the amd64 list with similar error messages. Any chance you are running a 64bit OS and mixing up 32 and 64bit tool chains? rpm -qf `which gas` rpm -qf `which g77` could be revealing. "Dale Ryon Wilhelm" <[EMAIL PROTECTED]> writes: > looked thru config.log and got the following ( see below )... not > knowing much about fortran, this doesn't make much sense to me... my > apologies for the initial html message... > > configure:25460: checking how to get verbose linking output from g77 > configure:25471: g77 -c conftest.f >&5 > /tmp/ccK3gsfu.s: Assembler messages: > /tmp/ccK3gsfu.s:8: Error: suffix or operands invalid for `push' > /tmp/ccK3gsfu.s:12: Error: suffix or operands invalid for `push' > /tmp/ccK3gsfu.s:13: Error: suffix or operands invalid for `push' > configure:25477: $? = 1 > configure: failed program was: > | program main > | > | end > configure:25556: WARNING: compilation failed > configure:25562: result: > configure:25564: checking for Fortran libraries of g77 > configure:25585: g77 -o conftest -L/usr/local/lib conftest.f >&5 > /tmp/cclyaHyt.s: Assembler messages: > /tmp/cclyaHyt.s:8: Error: suffix or operands invalid for `push' > /tmp/cclyaHyt.s:12: Error: suffix or operands invalid for `push' > /tmp/cclyaHyt.s:13: Error: suffix or operands invalid for `push' > configure:25746: result: > configure:25785: checking for dummy main to link with Fortran libraries > configure:25824: gcc -o conftest -g -O2 -I/usr/local/include > -L/usr/local/lib co > nftest.c -ldl -lm >&5 > configure:25830: $? = 0 > configure:25834: test -z > || test ! -s conftest.err > configure:25837: $? = 0 > configure:25840: test -s conftest > configure:25843: $? = 0 > configure:25921: result: none > configure:25958: checking for Fortran name-mangling scheme > configure:25972: g77 -c conftest.f >&5 > /tmp/ccpZMdHB.s: Assembler messages: > /tmp/ccpZMdHB.s:6: Error: suffix or operands invalid for `push' > /tmp/ccpZMdHB.s:8: Error: suffix or operands invalid for `pop' > /tmp/ccpZMdHB.s:14: Error: suffix or operands invalid for `push' > /tmp/ccpZMdHB.s:16: Error: suffix or operands invalid for `pop' > configure:25978: $? = 1 > configure: failed program was: > | subroutine foobar() > | return > | end > | subroutine foo_bar() > | return > | end > configure:26186: error: cannot compile a simple Fortran program > See `config.log' for more details. > > > > > -Original Message- > From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 09, 2005 2:08 PM > To: Dale Ryon Wilhelm > Cc: r-devel@stat.math.ethz.ch > Subject: Re: [Rd] install issue | suse 9.2 > > It says > > > See `config.log' for more details > > Please look there and extract the information (and see the comment about > > HTML mail below). > > > On Wed, 9 Feb 2005, Dale Ryon Wilhelm wrote: > > > i am trying to install r v2.0.1 on my suse 9.2 pro box... when i run > > configure, i get the following error: > > > > > > > > checking how to get verbose linking output from g77... configure: > > WARNING: compilation failed > > > > > > > > checking for Fortran libraries of g77... > > > > checking for dummy main to link with Fortran libraries... none > > > > checking for Fortran name-mangling scheme... configure: error: cannot > > compile a simple Fortran program > > > > See `config.log' for more details > > > > > > > > anybody know why i am getting this error? g77 is installed correctly > and > > working properly... > > > > > > > > > > > > -<0>- > > > > d. ryon wilhelm > > > > EVNINE-VAUGHAN ASSOCIATES, INC. > > > > 415.835.7855 > > > > > > > > > > [[alternative HTML version deleted]] > > The posting guide does ask you not to send HTML mail. > > > -- > 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 > -- 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
Re: [Rd] Re: Packages and Libraries (was: Re: lme4 "package" etc ..)
Kurt Hornik <[EMAIL PROTECTED]> writes:
> >>>>> A J Rossini writes:
>
> > But I don't see a problem with "package("package")", though I'm sure
> > I'm missing something.
>
> package() [sic] might be the creator for package objects, provided we
> can decide on what they are (and what kind of packages [source,
> installed, ...] they are used for).
>
> usePackage() or use_package() otoh would indicate to "use" a package
> (i.e., load and attach it). The tricky part is deciding about the
> interface (e.g., finally disallowing non-standard evaluation as it is a
> programmer's nightmare) and what it should return. And that is work in
> progress ...
Any information on the rate...? (I still vote for usepackage() btw.)
It would be good if we could at least have an outline of the intended
functionality and see if we could forge ahead and get a preliminary
version done in time for 2.1.x
> Even if we don't like the current semantics, the *name* of library() in
> itself should not be a problem. After all, calling summary() does not
> imply that your primary argument is a summary, so why should calling
> library() imply that its primary argument is a "library"?
More likely it would imply that the *result* is a library...
Anyway, it was introduced at a time where we considered it important
to be "prototype compatible" as long as there was no good reason not
to. With 20-20 hindsight, we could probably have afforded to think up
a better name.
> > It really would end this constant confusion and save various folks
> > approx 15 minutes/week in knee-jerk responses, eh?
>
> Afaic, one of the issues is that it seems common practice to refer to
> collections of code as "libraries" or "packages", and we're trying to
> use these rather general-purpose terms in a very precise meaning, and
> obviously not very successful, in particular because the use of
> "library" is highly non-standard. One idea might be to replace the
> "library" by something else like ... "a place where R knows where to
> find packages" ... hmm, now that's too long, so ...
"store", or "depot" springs to mind. The latter might cause baz to go
postal, 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
Re: [Rd] Environment with no parent?
Duncan Murdoch <[EMAIL PROTECTED]> writes: > >(a) efficiency. Is it expensive no longer to have the base functions > >bound directly to their symbol? (My gut feeling is that with suitable > >hashing and cacheing, the penalty is minimal.) > > > >(b) you can *only* use get and simple variable retrieval in a non-base > >environment with a NULL parent (eval(x <- 1, envir=foo) would give > >'couldn't find function "<-"' or so). This could cause some confusion. > > (b) means that the default should stay the way it is, but I think > there should be a way to set up a truly empty environment. We have a > fair number of cases where envir=NULL is used, so it would be safest > to make it a different value -- even if NULL is the obvious value for > an empty environment. Not necessarily. It just means that you should think about it. It is not a given that envir=NULL really means what the author expected, and fixing them up to read envir=.BaseEnv is probably quite doable. -- 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
Re: [Rd] Environment with no parent?
Robert Gentleman <[EMAIL PROTECTED]> writes: >And, I think, that a better approach is to implement a proper hash > table class > and to then implement environments as hash table + parent (rather than > the > current version, which would be environment - parent), Sounds like a good idea. Environments probably need to be *references* to hash tables plus parent, though. > but the tuit > shortage is devastating on this side of the atlantic (possibly due to > the disadvantageous $/euro exchange rate; I'm sure you all can afford > more of them :-)) I'm sure my publisher will have suggestions for the use of any tuit that I can get (and they pay in $, notwithstanding the IRS wanting me to spend my copious free time on wrapping up enough red tape to prevent them from taxing income which they are clearly not entitled to do. Puff, pant...) -- 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
Re: [Rd] Environment with no parent?
Duncan Murdoch <[EMAIL PROTECTED]> writes: > Looking in envir.c, I see this: > > /* env is now R_NilValue, the base environment */ > > which doesn't give me much hope, but maybe there's a trick > > If not, would it be reasonable to install a magic "EmptyEnv" to use as > a parent in this sort of situation? > I'm fairly sure the answer is "nope". It's been annoying me for years, for language aesthetic reasons mostly, but also with some consideration of cases like yours, and I've been on the brink of implementing a version where the base environment was a true environment. Apart from the usual issue of "round tuits", I was held back by the fact that one has to consider at least two things: (a) efficiency. Is it expensive no longer to have the base functions bound directly to their symbol? (My gut feeling is that with suitable hashing and cacheing, the penalty is minimal.) (b) you can *only* use get and simple variable retrieval in a non-base environment with a NULL parent (eval(x <- 1, envir=foo) would give 'couldn't find function "<-"' or so). This could cause some confusion. -- 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
Re: [Rd] Incorrect behavior for ordering timepoints in "reshape" (PR#7669)
[EMAIL PROTECTED] writes:
> Full_Name: Dav Clark
> Version: 2.0.1
> OS: OS X 10.3
> Submission from: (NULL) (128.122.87.35)
>
>
> When the timepoints that reshape uses (in direction="long") are negative or
> fractional, the time label is assigned incorrectly. It is easier to give an
> example than to describe the problem abstractly:
>
> Assume you have a data.frame header with values related to peri-stimulus time
> like this:
>
> "HRF -5" "HRF -2.5" "HRF 0" "HRF 2.5" ... "HRF 10"
>
> And you give reshape a split argument of a space " ".
>
> Then the labels will be assigned strangely, based on alphabetical ordering.
> So
> the above list order maps to:
>
> -2.5, -5, 0, 10, ... 2.5
>
> Items under the "HRF -5" column in wide format recieve a -2.5 label, items
> under
> "HRF 2.5" receive a label of 10, and so on.
>
> Somewhere, the time labels are being used before conversion to numbers. But,
> reshape returns an error if it is not possible to convert the timepoints to
> numeric! So obviously, more functionality could be provided, or at least the
> documentation should reflect the current shortfall.
>
> For completeness, here is a minimal example demonstrating the bug:
>
> df <- data.frame(id="S1", V1="from -2", V2="from -1")
> names(df)[2:3] <- c("vals.-2", "vals.-1")
> df
> reshape(df, direction="long", varying=2:3)
Hmm, this looks messed up even without the negatives. The guess()
function inside reshape always sorts before converting to numeric, so
you get the 1 10 11 2 3 4 5 6 7 8 9 effect, but what is worse: the
sorting decouples the values from the variable names, as demonstrated
by modifying your example slightly
> reshape(df, direction="long", varying=3:2)
id timevals
S1.-1 S1 -1 from -1
S1.-2 S1 -2 from -2
I'm not at all sure I understand what was supposed to happen here,
perhaps the sort in
varying <- unique(nn[, 1])
times <- sort(unique(nn[, 2]))
is a thinko? Over to Thomas, I think.
--
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
Re: [Rd] sys.on.exit not working (PR#7665)
Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> It is working as documented: there is no on.exit set for str, is there?
>
> 'sys.on.exit()' retrieves the expression stored for use by
> 'on.exit' in the function currently being evaluated. (Note that
> ^
> this differs from S, which returns a list of expressions for the
> current frame and its parents.)
>
> I see you have looked at PR#269, but did not notice the crucial
> difference: here the current function is str (it is evaluating its
> arguments), not soe.test.
>
> On Mon, 7 Feb 2005 [EMAIL PROTECTED] wrote:
>
> > Full_Name: Mark Bravington
> > Version: 2.0.1
> > OS: Windows XP
> > Submission from: (NULL) (140.79.22.104)
> >
> >
> > 'sys.on.exit()' doesn't seem to be working, since R1.7.1 at least:
>
> Please read the FAQ: we don't want R-bugs clogged up with `doesn't
> seem to be working' reports, and we do say so.
>
> > soe.test <- function() {
> > on.exit( cat( 'In exit code\n'))
> > str( sys.on.exit()) # should display "language..." I think
> > 12
> > }
> >
> > (A similar bug was apparently fixed for version 0.65!)
>
> One difference being that PR#269 was a bug, and this is not.
It does, however, point to a subtlety with the sys.xxx functions,
which is liable to confuse users to the point of submitting spurious
bug reports. Perhaps we should add a note to the help page (in the
vain hope that people will read it).
Notice, BTW, that this exposes a slightly anomalous handling of the
"<-" operator. AFAIK this is common to all .Primitive calls, as
opposed to .Internal and other function calls: They do not create a
new context, hence do not increase sys.nframe() and sys.whatever in
the arguments still refer to the callers frame.
> soe.test
function() {
on.exit( cat( 'In exit code\n'))
a <- sys.on.exit() ; str(a)
12
}
> soe.test()
language cat("In exit code\n")
In exit code
[1] 12
but if you replace "<-" with a corresponding call to assign(), then
you get.
> soe.test()
NULL
In exit code
[1] 12
--
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
Re: [Rd] getAnywhere
"McGehee, Robert" <[EMAIL PROTECTED]> writes:
> Shouldn't this work?
>
> > .a <- 5
> > exists(".a")
> [1] TRUE
> > getAnywhere(".a")
> Error in exists(x, envir, mode, inherits) :
> invalid first argument
>
> getAnywhere doesn't seem to like the "." prefix. Is this a bug?
Yes. It goes looking for getS3method(gen="", cl="a", TRUE) without
checking whether gen (or cl) is empty. Looks like an easy fix.
--
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
Re: [Rd] Re: [R] RData loading weirdness
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > We've found Linux to be rather unhelpful with out-of-memory > conditions: one of our servers started `randomly' killing processes > when its swap space got full -- and one of the first was the sshd > daemon which cut off all remote access This is running off-topic, but I believe that this has been recently worked on, and at least SuSE (I'm not going home just to open the lid on the laptop running FC3 just now!) now has the behaviour controlled by kernel flags in /proc/sys/vm/local-oom-kill and /proc/sys/vm/overcommit_memory. Not sure what the first one means exactly, 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
Re: [Rd] print() from within a function - Windows specific? (PR#7584)
[EMAIL PROTECTED] writes:
> To control the progress of a function one can consider to use print() to
> issue a
> message in the command window. However, using Win98 / R 1.9 or WinXP / R 2.0,
> this approach is of little usefulness, since all the print() commands are
> issued
> at once, just before the control returns to the command window. A test code
> could be:
>
> for(i in 1:10){
> for(j in 1:1000){
> for(k in 1:1000){}
> }
> print(i)
> }
>
> I once ask a linux / unix user and he was not able to reproduce the problem.
It IS a FAQ though...
http://cran.r-project.org/bin/windows/base/rw-FAQ.html#The-output-to-the-console-seems-to-be-delayed
--
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
Re: [Rd] typo in ?NotYetImplemented
Torsten Hothorn <[EMAIL PROTECTED]> writes: > The `examples' section says > > plot.mlm # to see how the "NotYetImplemented" > # reference is made automagically > ^ I think that's a joke, not a typo... http://catb.org/~esr/jargon/html/A/automagically.html -- 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
Re: [Rd] about R CMD check
Douglas Bates <[EMAIL PROTECTED]> writes: > Uwe Ligges wrote: > > [EMAIL PROTECTED] wrote: > > > >> hello, > >> > >> I create a package which includes C code and Lapack. But when I run > >> " R CMD > >> check ". an error message, "/usr/bin/ld: cannot find -lfrtbegin " > >> occurs. could > >> you tell me what is the problem? > > OS? R version? Self compiled or rpm/apt get? > > Looks like RedHat Linux from the name of the libraries. > > > Why do you check "var" when the package claims to be called "WXT"? > > Before any checking it is a good idea to try R CMD INSTALL ... > > (which does not work either, I guess). > > My guess is that an f2c or g2c development package needs to be > installed. On a Debian system the library comes from the libg2c0-dev > package > > $ dlocate libfrtbegin > libg2c0-dev: /usr/lib/libfrtbegin.a More likely it is Fortran itself that isn't there: $ rpm -qf `locate libfrtbegin` gcc-g77-3.4.2-6.fc3 -- 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
Re: [Rd] R 'postscript' plot - not a valid postscript (PR#7559)
[EMAIL PROTECTED] writes: > Full_Name: Mr. Daniel Murray Bolser > Version: R 2.0.0 (2004-10-04) > OS: Linux beagle 2.4.20-31.9 #1 Tue Apr 13 17:38:16 EDT 2004 i686 athlon i386 > GNU/Linux > Submission from: (NULL) (193.60.81.207) > > > > Trying to execute the following code produces a 'not a valid postscript' error > from various postscript readers (gv, ggv, ghostscript). A very similar code > works fine. > > > > postscript() > > plot( 1:100, ylim=c(1,700), type='n', log='y') > > abline(v=seq(0,100,10)) > abline(h=10) > abline(h=seq(0,100, 10)) # Comment out this line and it works fine > > dev.off() > > > Just abline(h=0) gives the same effect, with the following in the postscript file 77.04 nan m 716.61 nan l which of course comes from trying to calculate log10(0). > Looking at this just now I see the problem, but if a ps file is written, it > should be viewable, so I think this is still a bug. Yes. However, the workaround would be rather obvious... -- 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
Re: [Rd] Very Long Expressions
"McGehee, Robert" <[EMAIL PROTECTED]> writes: > Greetings, > I'm having some difficulties with evaluating very long expressions > (Windows/Linux 2.0.1), as seen below, and would greatly appreciate any > help, thoughts or work arounds. Let's say that I wanted to see what I > would get if I added 1 to itself 498 times. One way of doing this would > be to evaluate the expression 1+1+1+... > > > eval(parse(text = paste(rep(1, 498), collapse = "+"))) > [1] 498 > > However, if we try this with 499+ items we get no answer: > > a <- eval(parse(text = paste(rep(1, 499), collapse = "+"))) > > a > Error: Object "a" not found > > And if this eval is passed to any other function, that function exits > without error and without returning and object. > > So it seems that we've reached some upper limit of evaluation terms. > While the parser is able to correctly create the long expression, eval > does not successfully evaluate it. > My problem is that since the evaluator does not return an object, error, > or warning, I'm not able to easily code around this problem. Also, I've > thought of no easy way to "count" the terms in the expression to see > whether we've breached the upper limit or not. It's a bug. 1.9.1 had > eval(parse(text = paste(rep(1, 499), collapse = "+"))) Error in eval(expr, envir, enclos) : evaluation nested too deeply: infinite recursion / options(expression=)? which also contains the hint about how to raise the limit. You do see it if you do > a <- try(eval(parse(text = paste(rep(1, 499), collapse = "+" > a [1] "evaluation nested too deeply: infinite recursion / options(expression=)?" attr(,"class") [1] "try-error" but that's obviously no excuse for not printing the message. The problem appears still to be present in r-devel (the version at hand was dated Jan.12, though). > If I were able to see if the eval would work on a particular expression, > one thing I had considered was to make an eval.long wrapper that peels > terms off the right hand side of an overly-long expression until every > sub-expression is legal. But do you *really* want to do it this way? Why? BTW, it's not really the length of the expression but its depth. The parse tree for 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 is really (((1+2)+3)+4)+5)+6)+7)+8). So you get 7 levels of parentheses. You can easily have less deeply nested parentheses: ((1+2)+(3+4))+((5+6)+(7+8)) With that sort of pattern, adding 500 terms requires a nesting no more than 9 levels deep. Persuading R to nest that way is a bit tricky 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
Re: [Rd] p.adjust(s), was "Re: [BioC] limma and p-values"
Martin Maechler <[EMAIL PROTECTED]> writes: > MM> I agree that I don't see a good reason to allow specifying 'n' > MM> as argument unless e.g. for "bonferroni". > MM> What do other think ? > > no reaction yet. > > I've thought a bit more in the mean time: > Assume someone has 10 P values and knows that he > only want to adjust the smallest ones. > Then, only passing the ones to adjust and setting 'n = 10' > can be useful and will certainly work for "bonferroni" but > I think it can't work in general for any other method. > > In sum, I still tend to agree that the argument 'n' should be > dropped -- but maybe with "deprecation" -- i.e. still allow it > for 2.1.x giving a deprecation warning. There's another case to consider, namely when you get the same tests multiple times. Think SAS, for instance; when it compares groups you get every comparison twice: I vs III as well as III vs I, so you need a way to say that there are really only k * (k - 1) / 2 tests. Then again, this probably only works for "bonferroni", and R's pairwise.t.test() evades this by extracting the lower.tri before adjustment. -- 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
Re: [Rd] Problem with compiling - Freebsd on AMD64 (PR#7489)
[EMAIL PROTECTED] writes: > Full_Name: Kelly Black > Version: 2.0.1 > OS: FreeBSD 5.3 on AMD64 > Submission from: (NULL) (149.106.32.93) > > > I downloaded R-2.0.1 from the R website, ran configure then make and got an > error. I will paste a copy of the output from the makefile below. The problem > was when the makefile tried to run the R binary. When I came across the error > I > reran configure, but this time with the following arguments: > > ./configure FFLAGS="-g" CFLAGS="-g" CXXFLAGS="-g" > > This time when I ran make it compiled with no problems. I tried the same thing > again only with all of the flags set to "-O" and again it compiled with no > problems. When I ran it with the flags set to "-g -O2" it had the same error. > A > copy of the output from gdb can be found at > http://blackk.union.edu/~black/freebsd/R-error.txt, but the output isn't very > helpful. Indeed... This sounds like a compiler error, so information about the GCC version used is crucial. Switching compilers or running with less than optimal optimization is your best chance, unless you can pinpoint exactly what is getting miscompiled so that a workaround can be found. -- 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
Re: [Rd] Any plans for commenting out region via something like " /* */ "?
"A.J. Rossini" <[EMAIL PROTECTED]> writes:
> Greetings from Switzerland!
>
> Are there any plans/initiatives/considerations in future versions of R
> for commenting out regions via something like " /**/ "?
I don't think so. Personally, I'd rather work on getting the parser to
behave properly in all cases on
if (FALSE){
...lots of lines...
}
What did "C-c ;" do wrong anyway, Mr.ESS?
> (I've got an application for which something like that would be
> useful; if not, there are less simple solutions).
>
> best,
> -tony
>
> "Commit early,commit often, and commit in a repository from which we can
> easily
> roll-back your mistakes" (AJR, 4Jan05).
...and commit to a branch or use #ifdef so that the daily package checks
don't break.
--
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
Re: [Rd] Broken Link for gregmisc_2.0.0.zip
"Warnes, Gregory R" <[EMAIL PROTECTED]> writes: > The link from > http://cran.r-project.org/src/contrib/Descriptions/gregmisc.html to the > windows package gregmisc_2.0.0.zip is broken. Looks like a generic errors in mirroring the windows packages. Has happened before. > Also, could the appropriate email address for reporting web site problems > please be added to the website in some conspicous place? Good idea. [Cc trimmed] -- 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
Re: [Rd] omegahat link on R site (PR#7471)
[EMAIL PROTECTED] writes: > Hello, > > On the R web site on the page about R Data Import/Export, the link to > omegahat.org in the Introduction is misspelled. In principle, please do not report website issues here since the website is not part of R (CRAN has a webmaster). However, the origin of this particular issue is inside the Import/Export manual, the source of which *is* part of R, so thank you after all. -pd -- 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
Re: [Rd] Re: [R] ISNAN() broken? in ver 2.x on MacOS X
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > R has no such bug number, nor does any search I do come up with > anything similar. The Cc: line suggests that it is a gcc PR#. Guess who fell into the same trap... -p > In any case, please do read the R posting guide, as this is not a > suitable topic for R-help and I have diverted it to R-devel where it > belongs. > > On Tue, 4 Jan 2005, Bill Northcott wrote: > > > This sort of confirms that it is a bug. > > > >> From: Andrew Pinski <[EMAIL PROTECTED]> > >> Date: 4 January 2005 7:39:38 PM > >> To: Bill Northcott <[EMAIL PROTECTED]> > >> Cc: gcc@gcc.gnu.org > >> Subject: Re: C++ header file problem - is this a bug? > >> On Jan 4, 2005, at 2:13 AM, Bill Northcott wrote: > >> > >>> Is this a bug or is it expected behaviour and if so why? > >> Yes this is a bug but it is already filed see PR 14608. > >> Thanks, > >> Andrew Pinski > > -- 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
Re: [Rd] row ("FORTRAN") order?
Peter Dalgaard <[EMAIL PROTECTED]> writes:
> Göran Broström <[EMAIL PROTECTED]> writes:
>
> > Reading about 'R_max_col' in "Writing R extensions", Version
> > 2.1.0,(2005-01-03), I find:
> >
> > "Given the nr by nc matrix matrix in row ("FORTRAN") order, ..."
> >
> > Looks like a contradiction to me, since FORTRAN stores matrices
> > columnwise. So is this a documentation bug?
>
> H. Maybe. FORTRAN order is known as column-*major* order. The row
> index varies most quickly, so the question is whether "row order" may
> have have some merit. Anyone have the terminology straight?
Gordon Smyth didn't think "row order" made sense either, so I've
changed "row" to "column-major" for r-devel.
--
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
Re: [Rd] Object Memory-limits in base and its help document
Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> On Tue, 4 Jan 2005 [EMAIL PROTECTED] wrote:
[snip]
> > help(Memory-limits) displays the document for Arithmetic.
>
> As is should, for that is an arithmetical operation.
Oddly enough that doesn't happen for me (current 2.0.1 patched):
> help(Memory-limits)
No documentation for 'Memory - limits' in specified packages and libraries:
you could try 'help.search("Memory - limits")'
I seem to recall getting the help for "-" in cases like this in some
earlier version, but it would have been earlier than 1.8.0.
[R-bugs removed from recipients]
--
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
Re: [Rd] row ("FORTRAN") order?
Göran Broström <[EMAIL PROTECTED]> writes:
> Reading about 'R_max_col' in "Writing R extensions", Version
> 2.1.0,(2005-01-03), I find:
>
> "Given the nr by nc matrix matrix in row ("FORTRAN") order, ..."
>
> Looks like a contradiction to me, since FORTRAN stores matrices
> columnwise. So is this a documentation bug?
H. Maybe. FORTRAN order is known as column-*major* order. The row
index varies most quickly, so the question is whether "row order" may
have have some merit. Anyone have the terminology straight?
--
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
Re: [Rd] Plot elements echo NULL (PR#7466)
[EMAIL PROTECTED] writes: > This has been reported by Peter Dalgaard in PR#7397. > Please check whether a bug has already been reported before submitting a > new report. Even the submitter had forgotten that he submitted it as a formal report then... Better have it in once too many than once too few, I suppose. -p -- 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
Re: [Rd] win variable in tcltk
"Gabor Grothendieck" <[EMAIL PROTECTED]> writes:
> The following gives an error message:
>
> library(tcltk)
>
> win <- list(env="A")
>
> tt <- tktoplevel()
> but <- tkbutton(tt, text="X", command=expression(tkdestroy(tt)))
> tkgrid(but)
>
> however, if one comments out the win line (and removes the
> win variable) then it works. It seems that tcltk is making
> use of a variable called win with a component name of env
> and I just happened to have a list in my workspace called win
> in which one of the components was called env. I suggest that
> this either be changed or documented. I spent quite a large
> amount of time until I realized what was going on.
Nice catch, Gabor...
The problem is at the end of .Tcl.args.objv:
current.win <- if (exists("win", envir = parent.frame()))
get("win", envir = parent.frame())
else .TkRoot
which tries to pick up the current window from the enclosing call to
tkwidget(). However, that is the grandparent, not the parent frame, so
we need parent.frame(2), twice, and probably also inherits=FALSE as a
partial safeguard. That will not cure the inadvertent capture though,
since you could run tkcmd() directly in an envir that has a "win"
variable.
The logic is quite dodgy in the first place, and maybe it could do
with a facelift. The basic issue is how to figure out which window a
callback binds to, so that we can save it in its environment and
thereby protect it from the garbage collector. There are three main
cases:
1) widget creation
2) widget configuration
3) explicit bindings
i.e. in Tcl:
button .a.b -command $cmd
.a.b configure -command $cmd
bind .a.b $cmd
respectively. What the R code is doing is to pick up from the call the
last window mentioned. In the widget creation case it looks in the
parent environment.
However, the third case can take a "tag" instead of a window name, in
which case it is far from obvious what to do, so we have the stopgap
of .TkRoot.
Longer term, this needs fixes on a higher level; I suspect via the
possibility of creating a new object types in Tcl to represent R
objects (Tcl_RegisterObjType() and all that).
Looking at tkwidget() I do however get the feeling that it might be
possible to get rid of the "win" business altogether, just by using
tkcmd(type, win, ...)
where it is currently using .Tk.ID(win). The final Tcl call should be
the same, and val2obj will set current.win correctly.
--
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
Re: [Rd] Startup problem in 2.0.1 with install to /opt/R (PR#7437)
[EMAIL PROTECTED] writes: > Full_Name: Stephen Harker > Version: 2.0.1 > OS: Linux ppc YDL 3.01 > Submission from: (NULL) (130.194.13.106) > > > I have made R 2.0.1 using YellowDog Linux 3.0.1 (kernel 2.6.7) on a > powerpc machine. This is to replace R 1.9.1. It makes without an error. > However, when I do `make check' towards the end I obtain the > following: > > make[3]: Entering directory `/home/sjh/GS/R-2.0.1/tests' > running code in 'internet.R' ...make[3]: *** [internet.Rout] Error 1 > make[3]: Leaving directory `/home/sjh/GS/R-2.0.1/tests' > make[2]: [test-Internet] Error 2 (ignored) > make[2]: Leaving directory `/home/sjh/GS/R-2.0.1/tests' > make[1]: Leaving directory `/home/sjh/GS/R-2.0.1/tests' > > Beyond that I found that running R from the build directory works okay. > T he configure script was set to install to /opt/R (using `configure > --prefix=/opt/R'). After `make install' when I try running version > 2.0.1 I get : > > Error in gzfile(file, "rb") : unable to open connection > In addition: Warning message: > cannot open compressed file `/opt/R/lib/R/library/base/R/base.rdx' > Error: couldn't find function "attach" > > R : Copyright 2004, The R Foundation for Statistical Computing > Version 2.0.1 (2004-11-15), ISBN 3-900051-07-0 > > None of the base commands are understood. > This suggests that a path somewhere is not being set correctly. Or that something didn't get copied into place by "make install". E.g., does /opt/R/lib/R/library/base/R/base.rdx actually exist? One common problem is if you have a competing "install" script/command in your path, although I suspect that normally bites earlier. It's normal to have failures from internet.R (if for instance you are not on-line at the time) which is why they are ignored. -p -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R and Gnumeric?
Marc Schwartz <[EMAIL PROTECTED]> writes: > I was just curious if anyone from R Core might comment on the nature and > scope of the cooperation, as I could not find anything at the Gnumeric > web site on this. > > Does this suggest that perhaps code sharing and/or some level of > validation is taking place on selected Gnumeric math/stat functions? It's fairly informal, and mainly on the special functions level. Gnumeric imports bits (all?) of R's standalone math library. You may have seen some bug reports from [EMAIL PROTECTED] (aka Morten Welinder) on accuracy issues and the like. Morten is a Gnome/Gnumeric developer and works with R-core members (I believe mostly Martin Maechler) from time to time. If you look at Morten's reports, I'm sure you'll agree that he is rather good at actively seeking out erroneous and suboptimal code. -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
