[Rd] More Detail on "Error : vector memory exhausted (limit reached?)"
Would it be possible to enhance this error message? Could the message say how large the limit was that was reached? Is it that the limit for one particular vector has been exceeded (and to how much would it have grown vs. how much was allowed?), or is it that the entire memory space has been exceeded (and rm'ing other objects could fix this)? regards, /iaw [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Deep Replicable Bug With AMD Threadripper MultiCore
The following program is whittled down from a much larger program that
always works on Intel, and always works on AMD's threadripper with
lapply but not mclappy. With mclapply on AMD, all processes go into
"suspend" mode and the program then hangs. This bug is replicable on an
AMD Ryzen Threadripper 2950X 16-Core Processor (128GB RAM), running
latest ubuntu 18.04. The R version 3.5.3 (2019-03-11) -- "Great Truth" ,
invoked with --vanilla. I hope this helps...it took quite a while to get
it to this stage. I sure hope that I am not reporting an old bug...
options("mc.cores"=4)
library(data.table)
library(parallel)
if (!file.exists("bugsample.csv")) {
NR <- 6480
notused <- data.frame(v1=1:NR, v2=1:NR, v3=1:NR, x1=log(1:NR),
x2=log(1:NR))
fwrite(notused, file="bugsample.csv")
stop("you can quit now and restart the program")
}
if (!exists("notused")) notused <- fread("bugsample.csv", nrows= Inf) ##
needed! Inf cannot be replaced by actual NR
sample <- data.frame( groupidentifier=c( rep(1,2000), rep(2, 4500 )
) )
sample$yvar <- sin(1:nrow(sample))
sample$xvar <- 1:nrow(sample)
testfun <- function(dl) {
with(dl, message("Working: ", first(groupidentifier), " with ",
nrow(dl)))
lapply( 1:nrow(dl), FUN=function(onedayindex) {
if ((onedayindex %% 500) != 0) return(NULL)
with(dl[1:onedayindex,],
c( tryCatch( coef(lm( yvar ~ xvar, data=dl[1:onedayindex,]
))[2], error = function(e) NA ) ) )
})
}
message("starting --- replicable hang with mclapply, but not lapply")
o <- mclapply(split( 1:nrow(sample), sample$groupidentifier ),
FUN=function(.index) testfun( sample[.index, , drop=FALSE] ))
message("never gets here with mclapply")
print( do.call("c", o[[1]]) )
print( do.call("c", o[[2]]) )
--
Ivo Welch (ivo.we...@ucla.edu)
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[R-pkg-devel] Starter Help
Apologies for the Intrusion. I am trying to learn package development with
roxygen. The ecosystem has been moving so fast that much of what I learned
by googling and reading on the web (including old posts) seems to be at
least mildly outdated.
* does the r-package-devel mailing list have a search engine? (or generic
google?) a FAQ?
* could someone please point me to a good current example that follows
appropriate style and other guidelines, using the '@' roxygen documentation
format? (The '@' example In Hadley's book does not include a @name, which
my `document()` does not like.)
I also have a few specific questions, but I may be able to figure it out
given the above.
* is it possible to import a set of *.Rd man documentation files into my R
session?
* is it still good practice to place my functions into their own
environments (aka `me$myfun <- cmpfun(function() message("my fun")`). I am
thinking that this complicates matters unnecessarily in a package, given
that packages have namespaces, and environment prefixes makes documentation
access more complex (not ?me$myfun but ?'me$myfun' now). and should I lose
the `cmpfun` in a package?
basic pointers appreciated.
/iaw
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[Rd] Extending suggestion for stopifnot
I am using a variant of stopifnot a lot. can I suggest that base R
extends its functionality? I know how to do this for myself. this is
a suggestion for beginners and students. I don't think it would break
anything.
first, I think it would be more useful if it had an optional character
string, so users could write
stopifnot( is.matrix(m), m is not a matrix )
this would mean that stopifnot would have to detect whether the last
argument is a string. (I think stopifnot should have had only one
condition, and one should have used all() to test multiple conditions,
but this is a bridge that was already crossed.) upon failure,
stopifnot should print the character string. that's it.
A second enhancement would be a smart string, which knows that
everything inside {{...}} should be evaluated.
stopifnot( is.matrix(m), m is not a matrix, but a {{class(m)}} )
my own programming variant looks even nicer,
is.matrix(m) %or% m is not a matrix but a {{class(m)}}
but requesting base R to add the %and% and %or% (or, better yet, 'and'
and 'or') operators by default would be pushing my luck.
/iaw
Ivo Welch (ivo.we...@gmail.com)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extending suggestion for stopifnot
thx, deepayan: how is stopifnot better than
if (!all(...)) stop()
given that we have stopifnot() and I have seen it used often, I think
my two suggestions would make it better.
thx, michael: the %and% and %or% constructs are indeed relics of my
perl background. my own definition is
`%and%` - function(e1, e2) { if (e1) { if (is.character(e2))
abort.estring(e2) else eval(e2) } }
it's syntactic sugar. my abort.estring() function prints the
character as n estring() [extended string, see below] and exits. it
can probably be written a lot better. remember, I am not an expert.
thx, peter: the estring has the advantage of having it all in one
string, which allows me to say, e.g.,
(x) %or% x is not true but {{x}}
the comma here does not work. it basically becomes an interpolated
string, just like the construct x is $x in perl.
thx, bill: ensureThat() is not a base R function. uggh---I think you
are right on precedence. I always use parens around my conditions.
old C habit from decades ago, so I never ran into this problem. if()
is good enough. my main suggestion was adding an optional message at
the end of stopifnot(), and possibly extended (interpolated) strings.
thx, brian: I think of lambda.r as being more heavyweight and
requiring a modestly steeper learning curve. if it was standard in
base R, I would definitely switch to it. I think we want a system
that my students are taught to use from day 1.
in sum, I agree that one accomplish the functionality in base R. my
initial suggestion was very simple and small: (1) adding an optional
character string at the end of an existing function, stopifnot(). (2)
I think estrings (that behave like characters but are interpolated
before printout) are useful in the same way perl interpolated strings
are useful. this would be a bigger change. some people would like
it. others don't see the advantage. I think the benefits would
outweigh the costs. (3) I just mentioned %and% and %or% as an
aside. it this is definitely a bigger change, where we can all
agree to disagree whether we like this in code or not. just ignore
#3.
best,
/iaw
estring - function(e2, N.UP =2) {
rx - (?=\\{\\{).*?(?=\\}\\})
match - gregexpr(rx, e2, perl=TRUE)
syntax - regmatches(e2, match)[[1]]
syntax - lapply(syntax, parse, file=, n=NULL)
## syntax-lapply(syntax, eval.parent, n=N.UP)
r - tryCatch( syntax-lapply(syntax, eval.parent, n=N.UP), error=
function(e) NULL )
if (is.null(r)) r - tryCatch( syntax-lapply(syntax, eval.parent,
n=N.UP+1), error= function(e) NULL )
if (is.null(r)) r - tryCatch( syntax-lapply(syntax, eval.parent,
n=N.UP-1), error= function(e) NULL )
if (is.null(r)) r - tryCatch( syntax-lapply(syntax, eval.parent,
n=N.UP-2), error= function(e) unknown variable )
## the return is now ignored. if we cannot recognize the syntax, we
just leave it.
s- unlist(sys.calls())
if (length(s)1) cat(Function ',
as.character(s[[length(s)-N.UP+1]]), ':\n\t, sep=) else
cat([GlobalEnv]:\t)
regmatches(e2, match) - %s
do.call(sprintf, c(fmt=e2, '...'=syntax) )
}
Ivo Welch (ivo.we...@gmail.com)
http://www.ivo-welch.info/
J. Fred Weston Professor of Finance
Anderson School at UCLA, C519
Director, UCLA Anderson Fink Center for Finance and Investments
Free Finance Textbook, http://book.ivo-welch.info/
Editor, Critical Finance Review, http://www.critical-finance-review.org/
On Tue, Aug 20, 2013 at 2:14 PM, Brian Rowe r...@muxspace.com wrote:
If all you care about is emulating static type checking, then you can also
accomplish the same thing with lambda.r using type constraints on function
definitions.
e.g.
f(m) %::% matrix : matrix
f(m) %as% { m }
f(as.data.frame(matrix(rnorm(12),nrow=3)))
Error in UseFunction(f, ...) : No valid function for 'f(data.frame)'
f(1)
Error in UseFunction(f, ...) : No valid function for 'f(1)'
f
function
[[1]]
f(m) %::% matrix:matrix
f(m) %as% …
On Aug 20, 2013, at 4:36 PM, Peter Langfelder peter.langfel...@gmail.com
wrote:
On Tue, Aug 20, 2013 at 11:41 AM, ivo welch ivo.we...@anderson.ucla.edu
wrote:
I am using a variant of stopifnot a lot. can I suggest that base R
extends its functionality? I know how to do this for myself. this is
a suggestion for beginners and students. I don't think it would break
anything.
first, I think it would be more useful if it had an optional character
string, so users could write
stopifnot( is.matrix(m), m is not a matrix )
this would mean that stopifnot would have to detect whether the last
argument is a string. (I think stopifnot should have had only one
condition, and one should have used all() to test multiple conditions,
but this is a bridge that was already crossed.) upon failure,
stopifnot should print the character string. that's it.
A second enhancement would be a smart string, which knows that
everything inside {{...}} should be evaluated.
stopifnot( is.matrix(m), m is not a matrix, but a {{class(m
Re: [Rd] Extending suggestion for stopifnot
functionality is nice. syntax is weird. I think I would have
preferred an interpolate function call.
stop( i(class is `class(pi)` and $pi) )
three typing letters, too, and more logical. most importantly, I wish
we had some form of this in base R from the outset--whatever it is--so
that my students get used to using the standard from the outset.
[the {{...}} had the advantage of being unlikely to break anything.
perl has it nicely done--- is interpolated, ' is not. but this is a
bridge that we crossed long ago in R. it would break too much.]
best,
/iaw
Ivo Welch (ivo.we...@gmail.com)
http://www.ivo-welch.info/
J. Fred Weston Professor of Finance
Anderson School at UCLA, C519
Director, UCLA Anderson Fink Center for Finance and Investments
Free Finance Textbook, http://book.ivo-welch.info/
Editor, Critical Finance Review, http://www.critical-finance-review.org/
On Tue, Aug 20, 2013 at 3:28 PM, Gabor Grothendieck
ggrothendi...@gmail.com wrote:
On Tue, Aug 20, 2013 at 6:00 PM, ivo welch ivo.we...@gmail.com wrote:
character string at the end of an existing function, stopifnot(). (2)
I think estrings (that behave like characters but are interpolated
before printout) are useful in the same way perl interpolated strings
are useful.
The gsubfn package has string interpolation somewhat like perl.
Preface a function call with fn$ and then back ticks and $ are
interpolated.
library(gsubfn)
fn$identity(pi is $pi)
library(sqldf)
fn$sqldf(select * from BOD where Time $pi)
fn$stop(class is `class(pi)`)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unmapped memory core dump with pure R program?
thx. would be happy to do this, but is it worth the effort? are you guys interested in potentially chasing this down or is this mundane? regards, /iaw Ivo Welch (ivo.we...@gmail.com) On Sun, Jul 14, 2013 at 2:54 AM, Dirk Eddelbuettel e...@debian.org wrote: On 13 July 2013 at 22:24, ivo welch wrote: | dear R developers---I am running a pure R program on the stock binary | debian (ubuntu) 64-bit linux distribution, 3.0.1. for identification, [...] | recurse some. I don't have symbols in my R binary, so the location may not | be useful, but I thought I would let you guys know. You can install the 'r-base-core-dbg' package [1] to get the (stripped) debugging symbols back. Dirk [1] Quite generally, on Debian/Ubuntu, for package $xys the corresponding $xyz-dbg contains the corresponding debugging symbols. -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unmapped memory core dump with pure R program?
happening on a home machine, which is not easy to ssh into. however, I can bring it into the office and see if I can replicate it there, too. if I can, I could put it up and give you an account on my machine. or I can tar it up incl the data and put it somewhere for download. whatever you prefer. regards, /iaw Ivo Welch (ivo.we...@gmail.com) [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unmapped memory core dump with pure R program?
hi dirk---look, it's a fickle bus segfault. if you read my email in full,
you will note that even eliminating an irrelevant print(head()) statement
makes it go away. we are lucky it is reproducible and thus easy to track
down for whoever wrote the code, given my code AND the data, of course.
(maybe it could do with me trying to create data that are random, maybe
not. but there is no point to me doing so. if we have the bug
reproducible, we should chase it down when we know it appears.) I know
that you cannot reproduce it from what I have posted. I also wrote that I
will bring the tarball (with the files) into my office tomorrow to see if I
can make it remotely available to simon or you, if you are interested.
I am trying to help...it did take me a day to reduce the code to figure out
what went wrong,, and an hour to get it to this point where it is easily
understandable, reproducible, and digestable by you.
regards,
/iaw
Ivo Welch (ivo.we...@gmail.com)
On Sun, Jul 14, 2013 at 9:20 AM, Dirk Eddelbuettel e...@debian.org wrote:
On 14 July 2013 at 09:04, ivo welch wrote:
| thanks, simon. it's replicable even on
|
|R version 3.0.1 Patched (2013-07-13 r63293) -- Good Sport
|
| (I presume that it is loading its own updated dynamic libraries when I
| installed it in a temporary directory and am invoking it as
| temp/R-patched/bin/R, and not the system-wide unpatched version.) the
It should stay within its own tree. I call my r-devel builds with a
two-line shell script wrapper to make sure its bin/ directory is prefixed
to
the $PATH.
| program that causes it is small enough to be displayable
|
| if (interactive()) options(error=recover)
| year - 1982
|
| for (yr in (year-6):year) {
| ifname - paste0(dbetas/dbetas-,yr, .Rdata)
That is obviously NOT reproducible as we do not have your files.
If possible, please create a _self-contained reproducible script_ as it
ought
to be possible to create such data matrices with random data.
Dirk
| load(ifname)
| print(head(dbetas,2)) ## if you remove this, then the core dump goes
| away
| dm - if (!exists(dm)) dbetas else rbind(dm, dbetas)
| cat([Loaded , yr,]\n)
| }
| cat(\n[, now(), Loaded All Data]\n)
|
|
| Reproducing the error,
|
| # r-devel/R-patched/bin/R --vanilla
|
| R version 3.0.1 Patched (2013-07-13 r63293) -- Good Sport
| Copyright (C) 2013 The R Foundation for Statistical Computing
| Platform: x86_64-unknown-linux-gnu (64-bit)
|
| R is free software and comes with ABSOLUTELY NO WARRANTY.
| You are welcome to redistribute it under certain conditions.
| Type 'license()' or 'licence()' for distribution details.
|
| Natural language support but running in an English locale
|
| R is a collaborative project with many contributors.
| Type 'contributors()' for more information and
| 'citation()' on how to cite R or R packages in publications.
|
| Type 'demo()' for some demos, 'help()' for on-line help, or
| 'help.start()' for an HTML browser interface to help.
| Type 'q()' to quit R.
|
| source(coredump.R)
| permno mmdd lagmvalbeta
| 31303 10006 19760102 219450 -0.81162794
| 31304 10006 19760105 218025 -0.01280477
| [Loaded 1976 ]
| permno mmdd lagmval beta
| 31556 10006 19770103 304709.4 4.5770379
| 31557 10006 19770104 301456.2 -0.3810519
| [Loaded 1977 ]
| permno mmdd lagmval beta
| 31808 10006 19780103 301219.5 1.277823
| 31809 10006 19780104 296854.0 2.671327
| [Loaded 1978 ]
| permno mmdd lagmvalbeta
| 32060 10006 19790102 269308.5 -0.06000999
| 32061 10006 19790103 269308.5 -0.83697042
| [Loaded 1979 ]
| permno mmdd lagmval beta
| 32313 10006 19800102 303420.8 -0.3768525
| 32314 10006 19800103 305635.5 2.2475787
| Error in rbind(deparse.level, ...) :
| 'pairlist' object cannot be coerced to type 'double'
|
| Enter a frame number, or 0 to exit
|
| 1: source(coredump.R)
| 2: withVisible(eval(ei, envir))
| 3: eval(ei, envir)
| 4: eval(expr, envir, enclos)
| 5: coredump.R#8: rbind(dm, dbetas)
| 6: rbind(deparse.level, ...)
|
| Selection: 6
| Called from: eval(substitute(browser(skipCalls = skip), list(skip = 7 -
| which)),
| envir = sys.frame(which))
| Browse[1] head(dm)
| permno mmdd lagmvalbeta
| 31303 10006 19760102 219450 -0.81162794
| 31304 10006 19760105 218025 -0.01280477
| 31305 10006 19760106 218025 7.26041268
| 31306 10006 19760107 236550 -1.23044474
| 31307 10006 19760108 235125 3.02461687
| 31308 10006 19760109 239400 2.04868169
| Browse[1] head(rbind(dm,dbetas))
|
| *** caught segfault ***
| address 0x10, cause 'memory not mapped'
|
| Traceback:
| 1: rbind(deparse.level, ...)
| 2: rbind(dm, dbetas)
| 3: head(rbind(dm, dbetas))
| 4: eval(expr, envir, enclos)
| 5: eval(substitute(browser(skipCalls = skip), list(skip = 7 - which)),
| envir
Re: [Rd] unmapped memory core dump with pure R program?
hi dirk---it is not 100% clear what causes it. it is a segfault. the bug does not show up at the head command. it shows up at a different place, but removing an unrelated print(head()) command means the bug does not appear later. it weighs in at about 280MB. I will make it available to simon on Monday, after verifying first that I can replicate it on another computer in my office. look, dirk, I know you put in an enormous amount of effort toward making R more useful. I know you are trying to help and helping. however, some of the R experts incl yourself can be sometimes aggressive to the point where it deters other R users from trying to provide help and feedback. even the comments of beginners can be useful in pointing out how to make R a better experience. sometimes, novices like me stumble over stuff that can help...and sometime we cry wolf when there is none because we misunderstand things or did not remember everything in the docs (or did not read the code). I believe some other R experts are struggling with the tone in the R list(s), too. in this sense, the R community is an odd beast. on the one hand, very gracious and helpful. on the other hand, sometimes seemingly almost bitter. regards, /iaw Ivo Welch (ivo.we...@gmail.com) On Sun, Jul 14, 2013 at 12:03 PM, Dirk Eddelbuettel e...@debian.org wrote: On 14 July 2013 at 11:45, ivo welch wrote: | hi dirk---look, it's a fickle bus segfault. if you read my email in full, you | will note that even eliminating an irrelevant print(head()) statement makes it | go away. we are lucky it is reproducible and thus easy to track down for | whoever wrote the code, given my code AND the data, of course. (maybe it | could do with me trying to create data that are random, maybe not. but there | is no point to me doing so. if we have the bug reproducible, we should chase | it down when we know it appears.) I know that you cannot reproduce it from | what I have posted. I also wrote that I will bring the tarball (with the | files) into my office tomorrow to see if I can make it remotely available to | simon or you, if you are interested. | | I am trying to help...it did take me a day to reduce the code to figure out | what went wrong,, and an hour to get it to this point where it is easily | understandable, reproducible, and digestable by you. Well your comment notwithstanding I actually had read your code snippet and concluded that at least your initial report was wrong (as you blamed rbind, not head which the comment now blames) but I have never made any promises to debug this -- R memory internals requires sturdier souls than mine. Rather, I was trying to explain to you that if you want your so far non-bug as not reproducible report to have any effect, you have to give those whose time you expect to be devoted to this at least the commonly required inputs to be able to replicate the issue. And no, the offer to supply 60gb of data does not commonly count as a suitable offer. A reproducible script might. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unmapped memory core dump with pure R program?
dear R developers---I am running a pure R program on the stock binary debian (ubuntu) 64-bit linux distribution, 3.0.1. for identification, 20abb3a1d917bce52a10dd40cb47b82b /usr/lib/R/bin/exec/R 58ebc91f143f752610c8dbe22182f3f3 /usr/lib/libR.so my R program loads 5 big matrices (about 1GB each)and rbind's them, all on a 16GB machine. alas, in one particular run, I am getting a mysterious Error in rbind(deparse.level, ...) : 'pairlist' object cannot be coerced to type 'double' so I dropped into the R debugger (option(error=recover)) and tried to do the rbind by hand again to figure out what this error message means in this context. (it works just fine with other combinations.) when I thus am trying to run it again, I am getting a Browse[1] head(rbind(dm,db)) *** caught segfault *** address 0x10, cause 'memory not mapped' Traceback: 1: rbind(deparse.level, ...) 2: rbind(dm, db) 3: head(rbind(dm, db)) 4: eval(expr, envir, enclos) ... I then created a core dump (where R prompts me), which goes for 82 levels (to _start), so its not an infinite recursion problem, but it does seem to recurse some. I don't have symbols in my R binary, so the location may not be useful, but I thought I would let you guys know. alas (gdb) bt #0 0x7ff956be3857 in ?? () from /usr/lib/R/lib/libR.so #1 0x7ff956be67d3 in Rf_allocVector () from /usr/lib/R/lib/libR.so #2 0x7ff956b90338 in ?? () from /usr/lib/R/lib/libR.so #3 0x7ff956b8fcfa in ?? () from /usr/lib/R/lib/libR.so #4 0x7ff956b90875 in Rf_duplicate () from /usr/lib/R/lib/libR.so #5 0x7ff956b48e98 in ?? () from /usr/lib/R/lib/libR.so #6 0x7ff956bb56da in ?? () from /usr/lib/R/lib/libR.so #7 0x7ff956bba9a8 in Rf_eval () from /usr/lib/R/lib/libR.so #8 0x7ff956bbec39 in Rf_applyClosure () from /usr/lib/R/lib/libR.so #9 0x7ff956b44c38 in ?? () from /usr/lib/R/lib/libR.so #10 0x7ff956be80a0 in ?? () from /usr/lib/R/lib/libR.so #11 0x7ff956bae21a in ?? () from /usr/lib/R/lib/libR.so #12 0x7ff956bba9a8 in Rf_eval () from /usr/lib/R/lib/libR.so #13 0x7ff956bbec39 in Rf_applyClosure () from /usr/lib/R/lib/libR.so its replicable. not sure if this is of any interest...just trying to help. please ignore if uninteresting. regards, /iaw Ivo Welch (ivo.we...@gmail.com) [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 3.0.1 : parallel collection triggers long memory not supported yet
Dear R developers:
...
7: lapply(seq_len(cores), inner.do)
8: FUN(1:3[[3]], ...)
9: sendMaster(try(lapply(X = S, FUN = FUN, ...), silent = TRUE))
Selection: .Error in sendMaster(try(lapply(X = S, FUN =
FUN, ...), silent = TRUE)) :
long vectors not supported yet: memory.c:3100
admittedly, my outcome will be a very big list, with 30,000 elements, each
containing data frames with 14 variables and around 200 to 5000
observations (say, 64KB on average). thus, I estimate that the resulting
list is 20GB. the specific code that triggers this is
exposures.list - mclapply(1:length(crsp.list.by.permno),
FUN=function(i, NMO=NMO) {
calcbeta.for.one.stock(crsp.list.by.permno[[i]], NMO=NMO)
},
NMO=NMO, mc.cores=3 )
the release docs to 3.0.0 suggest this error should occur primarily in
unusual situations. so, it's not really a bug. but I thought I would
point this out. maybe this is a forgotten updatedlet.
regards,
/iaw
Ivo Welch (ivo.we...@gmail.com)
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Money
ladies and gents---is there a list of what the R core team would like to get funded? let's presume that we could raise $100,000 or $1,000,000 (or even $10,000,000) for the core team. what would the R core team do with the money? is there a list somewhere, perhaps like kickstarter? my preference would be improving up the default error hunting process---from greater strictness to assertions to line numbers on errors, followed by a POD. I know there are many clever ways to go about every one of these issues in R, but they are not so standard and built into the core language that every beginning R student will benefit. /iaw Ivo Welch (ivo.we...@gmail.com) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Contract Syntactic Sugar
## the following is a dream: add some sugar syntax to allow for
contracts with teeth (in and out checking)
is.positive - function(x) (all(x0))
exponentiate - function( x ::is.data.frame , exponent ::is.numeric
is.positive) :: is.vector is.numeric {
x$base :: is.positive## error also if base does not exist
in x; may need some special IQ
x$base^exponent
}
should be self-explanatory. anything that has '::' means run what is
before through all the functions after and barf if it is not true.
any other operator rather than :: or other syntax would be as
good---this is just illustratory. in the end, this code should be
viewed by R as the same as
exponentiate - function( x, exponent ) {
stopifnot( is.data.frame(x) )
stopifnot( is.numeric(exponent) )
stopifnot( is.positive(exponent) )
stopifnot( exists(base, x) )
stopifnot( is.positive( x$base ) )
return.value - x$base^exponent
stopifnot( is.vector(return.value) )
stopifnot( is.numeric(return.value) )
return.value
}
is this a feasible summer project for a student with a prospect of
inclusion of the completed code in the R core language itself if I pay
for the development time? {or does better syntax already exist and I
am just ignorant (which I often am)?}
regards,
/iaw
Ivo Welch (ivo.we...@gmail.com)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Contract Syntactic Sugar
hi brian---interesting and very impressive. is it possible to move
everything into one definition and/or to chain multiple conditions?
exponentiate(x, exponent) %::% data.frame : c(numeric,allpositive) :
integer %as% {
x %has% base ## my invention, since this is not checked, and R is
not strict enough
x$base %::% allpositive
x$base ^ exponent
}
multiple creations as in your doc examples on the same function are a
recipe for errors for me. it's also why I am not too fond of
TypeInfo. chaining conditions in my c() is not important, as long as
I can define my own types (which can check multiple aspects at the
same time). suggestion: in your doc example, can you define a
different type than an integer? it's a little confusing. how about
defining a strictly positive integer?
regards,
/iaw
Ivo Welch (ivo.we...@gmail.com)
http://www.ivo-welch.info/
J. Fred Weston Professor of Finance
Anderson School at UCLA, C519
Director, UCLA Anderson Fink Center for Finance and Investments
Free Finance Textbook, http://book.ivo-welch.info/
Editor, Critical Finance Review, http://www.critical-finance-review.org/
On Mon, Feb 4, 2013 at 2:10 PM, Brian Lee Yung Rowe r...@muxspace.com wrote:
Ivo,
You might be interested in my lambda.r package which provides syntax (using
the %::% operator) for type constraints. Given a function with n arguments,
the type constraint requires n + 1 types, as the last type listed is the
return type. Lambda.r also provides syntax for specifying any arbitrary
condition on the input arguments via the %when% operator. For your example
below you could do the following:
exponentiate(x, exponent) %::% data.frame : numeric : numeric
exponentiate(x, exponent) %when% {
is.positive(x)
} %as% {
x$base ^ exponent
}
You can see more examples in the package (available on CRAN) or in the source
(https://github.com/muxspace/lambda.r).
HTH,
Brian
On Feb 4, 2013, at 4:53 PM, ivo welch ivo.we...@anderson.ucla.edu wrote:
## the following is a dream: add some sugar syntax to allow for
contracts with teeth (in and out checking)
is.positive - function(x) (all(x0))
exponentiate - function( x ::is.data.frame , exponent ::is.numeric
is.positive) :: is.vector is.numeric {
x$base :: is.positive## error also if base does not exist
in x; may need some special IQ
x$base^exponent
}
should be self-explanatory. anything that has '::' means run what is
before through all the functions after and barf if it is not true.
any other operator rather than :: or other syntax would be as
good---this is just illustratory. in the end, this code should be
viewed by R as the same as
exponentiate - function( x, exponent ) {
stopifnot( is.data.frame(x) )
stopifnot( is.numeric(exponent) )
stopifnot( is.positive(exponent) )
stopifnot( exists(base, x) )
stopifnot( is.positive( x$base ) )
return.value - x$base^exponent
stopifnot( is.vector(return.value) )
stopifnot( is.numeric(return.value) )
return.value
}
is this a feasible summer project for a student with a prospect of
inclusion of the completed code in the R core language itself if I pay
for the development time? {or does better syntax already exist and I
am just ignorant (which I often am)?}
regards,
/iaw
Ivo Welch (ivo.we...@gmail.com)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bounty on Error Checking
gents---first, thanks a lot for paying some attention to my suggestion.
I always write programs with options(warn=2). but it doesn't cover
everything. In particular, my code is littered with hand tests that
the dimensions are correct and that variables are defined:
stopifnot(is.data.frame(d) exists(x, where=d) (is.numeric(x))
of course, I should already know that d$x is what it is supposed to
be, but the whole point is that I make mistakes. my suggestion is
also not so much for myself, but for all of our students that we get
involved with R. it is one thing for me to fix my own problems. it
is another for me to be comfortable recommending our students to learn
programming in R.
perl has an exact equivalent to the variable definition that I think
would help a great deal:
use warnings FATAL = qw{ uninitialized };
one can test whether a variable is NULL. one can assign to a variable
that is NULL. one cannot *use* a variable that is NULL. I presume
this mostly means that code such as d=data.frame( x=2 ); return d$y+2
would abort. I guess a better perspective would be that R should
limit what one can do with NULL, not that it should limit the
variables. R is too generous in allowing mismatched operations.
(this also applies to silent automatic repetition of matrices to make
dimensions fit; for every time that it helps, there are probably two
times when it bites.) not being a programmer or language designer, I
am not the best person to suggest what to improve. but the strictness
of R seems too lax right now, making error tracking too difficult,
from the perspective of an end user. this is partly why I suggested a
more general bounty to improve on this aspect of R, rather than on my
specific issue(s).
best,
/iaw
Ivo Welch (ivo.we...@gmail.com)
http://www.ivo-welch.info/
J. Fred Weston Professor of Finance
Anderson School at UCLA, C519
Director, UCLA Anderson Fink Center for Finance and Investments
Free Finance Textbook, http://book.ivo-welch.info/
Editor, Critical Finance Review, http://www.critical-finance-review.org/
On Fri, Jan 4, 2013 at 7:38 AM, Matthew Dowle mdo...@mdowle.plus.com wrote:
On 04.01.2013 15:22, Duncan Murdoch wrote:
On 04/01/2013 10:15 AM, Matthew Dowle wrote:
On 04.01.2013 14:56, Duncan Murdoch wrote:
On 04/01/2013 9:51 AM, Matthew Dowle wrote:
On 04.01.2013 14:03, Duncan Murdoch wrote:
On 13-01-04 8:32 AM, Matthew Dowle wrote:
On Fri, Jan 3, 2013, Bert Gunter wrote
Well...
On Thu, Jan 3, 2013 at 10:00 AM, ivo welch ivo.welch at
anderson.ucla.edu wrote:
Dear R developers---I just spent half a day debugging an R
program,
which had two bugs---I selected the wrongly named variable,
which
turns out to have been a scalar, which then happily multiplied
as
if
it was a matrix; and another wrongly named variable from a data
frame,
that triggered no error when used as a[[name]] or a$name .
there
should be an option to turn on that throws an error inside R
when
one
does this. I cannot imagine that there is much code that wants
to
reference non-existing columns in data frames.
But I can -- and do it all the time: To add a new variable, d
to
a
data frame, df, containing only a and b (with 10 rows,
say):
df[[d]] - 1:10
Yes but that's `[[-`. Ivo was talking about `[[` and `$`; i.e.,
select
only not assign, if I understood correctly.
Trying to outguess documentation to create error triggers is a
very
bad idea.
Why exactly is it a very bad idea? (I don't necessarily disagree,
just
asking
for more colour.)
R already has plenty of debugging tools -- and there is even a
debug
package. Perhaps you need a better programming editor/IDE. There
are
several listed on CRAN, RStudio, etc.
True, but that relies on you knowing there's a bug to hunt for.
What
if
you
don't know you're getting incorrect results, silently? In a
similar
way
that options(warn=2) turns known warnings into errors, to enable
you
to
be
more strict if you wish,
I would say the point of options(warn=2) is rather to let you find
the location of the warning more easily, because it will abort the
evaluation.
True but as well as that, I sometimes like to run production systems
with
options(warn=2). I'd prefer some tasks to halt at the slightest hint
of
trouble than write a warning silently to a log file that may not be
looked
at. I think of that as being more strict, more robust. Since
option(warn=2)
is set even when there is no warning, to catch if one arises in
future.
Not
just to find it more easily once you know there is a warning.
I would not recommend using code that issues warnings.
Not sure what you mean here.
I just meant that I consider warnings to be a problem (as you do), so
they should all be fixed.
I see now, good.
an option to turn on warnings
[Rd] Bounty on Error Checking
Dear R developers---I just spent half a day debugging an R program, which had two bugs---I selected the wrongly named variable, which turns out to have been a scalar, which then happily multiplied as if it was a matrix; and another wrongly named variable from a data frame, that triggered no error when used as a[[name]] or a$name . there should be an option to turn on that throws an error inside R when one does this. I cannot imagine that there is much code that wants to reference non-existing columns in data frames. I know you guys are saints for developing without financial support. but maybe we non-insider end-users can help by putting up a bounty list on R-project for us end-users to contribute to? I would pledge $500 to a $10,000 fund that funds a project to comprehensively enhance the programming and debugging aspects of R. it would only take 20 of us to make this possible. personally, I think basic nudgeware is the way to go. when a user starts R in interactive mode, there should be a note that says, please donate $20 to the R foundation to support the development. press enter to continue or enter your contribution number to avoid this message in the future . you can even accept the same string if need be. it's a nudge only, not a requirement. regards, /iaw Ivo Welch (ivo.we...@gmail.com) http://www.ivo-welch.info/ J. Fred Weston Professor of Finance Anderson School at UCLA, C519 Director, UCLA Anderson Fink Center for Finance and Investments Free Finance Textbook, http://book.ivo-welch.info/ Editor, Critical Finance Review, http://www.critical-finance-review.org/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] short documentation suggestion for by --- reference simplify2array and ave
in the documentation for by, please change the See also section to
\seealso{\code{\link{tapply}}, \code{\link{simplify2array}},
\code{\link{ave}}}
(simplify2array, by, and ave should probably also be mentioned in the See
also section of apply.)
hope this helps.
/iaw
Ivo Welch (ivo.we...@gmail.com)
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] speeding up perception
thank you, simon. this was very interesting indeed. I also now understand how far out of my depth I am here. fortunately, as an end user, obviously, *I* now know how to avoid the problem. I particularly like the as.list() transformation and back to as.data.frame() to speed things up without loss of (much) functionality. more broadly, I view the avoidance of individual access through the use of apply and vector operations as a mixed IQ test and knowledge test (which I often fail). However, even for the most clever, there are also situations where the KISS programming principle makes explicit loops still preferable. Personally, I would have preferred it if R had, in its standard statistical data set data structure, foregone the row names feature in exchange for retaining fast direct access. R could have reserved its current implementation with row names but slow access for a less common (possibly pseudo-inheriting) data structure. If end users commonly do iterations over a data frame, which I would guess to be the case, then the impression of R by (novice) end users could be greatly enhanced if the extreme penalties could be eliminated or at least flagged. For example, I wonder if modest special internal code could store data frames internally and transparently as lists of vectors UNTIL a row name is assigned to. Easier and uglier, a simple but specific warning message could be issued with a suggestion if there is an individual read/write into a data frame (Warning: data frames are much slower than lists of vectors for individual element access). I would also suggest changing the Introduction to R 6.3 from A data frame may for many purposes be regarded as a matrix with columns possibly of differing modes and attributes. It may be displayed in matrix form, and its rows and columns extracted using matrix indexing conventions. to A data frame may for many purposes be regarded as a matrix with columns possibly of differing modes and attributes. It may be displayed in matrix form, and its rows and columns extracted using matrix indexing conventions. However, data frames can be much slower than matrices or even lists of vectors (which, like data frames, can contain different types of columns) when individual elements need to be accessed. Reading about it immediately upon introduction could flag the problem in a more visible manner. regards, /iaw __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] speeding up perception
Dear R developers: R is supposed to be slow for iterative
calculations. actually, it isn't. matrix operations are fast. it is
data frame operations that are slow.
R - 1000
C - 1000
example - function(m) {
cat(rows: ); cat(system.time( for (r in 1:R) m[r,20] -
sqrt(abs(m[r,20])) + rnorm(1) ), \n)
cat(columns: ); cat(system.time(for (c in 1:C) m[20,c] -
sqrt(abs(m[20,c])) + rnorm(1)), \n)
if (is.data.frame(m)) { cat(df: columns as names: );
cat(system.time(for (c in 1:C) m[[c]][20] - sqrt(abs(m[[c]][20])) +
rnorm(1)), \n) }
}
cat(\n Now as matrix\n)
example( matrix( rnorm(C*R), nrow=R ) )
cat(\n Now as data frame\n)
example( as.data.frame( matrix( rnorm(C*R), nrow=R ) ) )
When m is a data frame, the operation is about 300 times slower than
when m is a matrix.The program is basically accessing 1000
numbers. When m is a data frame, the speed of R is about 20 accesses
per seconds on a Mac Pro. This is pretty pathetic.
I do not know the R internals, so the following is pure speculation.
I understand that an index calculation is faster than a vector lookup
for arbitrary size objects, but it seems as if R relies on search to
find its element. maybe there isn't even a basic vector lookup table.
a vector lookup table should be possible at least along the dimension
of consecutive storage. another possible improvement would be to add
an operation that adds an attribute to the data frame that contains a
full index table to the object for quick lookup. (if the index table
is there, it could be used. otherwise, R could simply use the
existing internal mechanism.)
I think faster data frame access would significantly improve the
impression that R makes on novices. just my 5 cents.
/iaw
Ivo Welch (ivo.we...@gmail.com)
http://www.ivo-welch.info/
J. Fred Weston Professor of Finance
Anderson School at UCLA, C519
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] small suggestion---add sd to summary() for vectors, matrices, and data frames
Dear R developers---of course, I have my own function that does this, but I think this would be useful for others, too. summary() already returns the first moment, and I would hope most of us think of the standard deviation as a pretty common summary statistic. not to clutter this mailing list, but it would also be useful to have an optional parameter that creates a different type of output, stacking the univariate outputs, along the lines of for (i in 1:ncol(d)) cat(names(d)[i], summary(d[i]), \n) of course, both of these suggestions may be useful but are not necessary. my biggest suggestion is still to issue an ambiguity warning when -[0-9] is encountered, suggesting to users either to use '-[ ][0-9]' or '[ ]-[0-9]' spacing for disambiguation. this would help a lot of my students who are newcomers. regards, /iaw Ivo Welch (ivo.we...@brown.edu, ivo.we...@gmail.com) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] segfault interest?
in a long program, I ran into *** caught segfault *** address 0xdc3f9b48, cause 'memory not mapped' Traceback: 1: rep.int(seq_len(nx), rep.int(rep.fac, nx)) 2: rep.int(rep.int(seq_len(nx), rep.int(rep.fac, nx)), orep) 3: expand.grid(seq_len(nx), seq_len(ny)) 4: merge.data.frame(d, ss) 5: merge(d, ss) 6: valid.range(opt) 7: eval.with.vis(expr, envir, enclos) 8: eval.with.vis(ei, envir) 9: source(fut-into-opts.R) Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace I am pretty sure that I can program around it (and it is probably caused by my writing some error), but because it is replicable, I just wanted to learn if anyone is interested. oh---the program is pure R code, nothing special (like linked in C code or stuff like this). the error occurs on OSX. if there is interest, please email me and let me know what would be most useful to supply. if not, fine, too. regards, /iaw Ivo Welch (ivo.we...@brown.edu, ivo.we...@gmail.com) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] segfault interest?
I just figured out what is happening. The root drive (presumably OSX virtual memory) becomes depleted. The error message about memory not mapped was a hint, too. So, not really R's fault. However, I wonder whether R can be made to abort more gracefully, or at least trap the error message and translate it into something more meaningful (you have run out of [virtual] memory when executing 'R statement' ). of course, this may not be possible at all. /iaw __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] small syntax suggestion
Dear R development Team: I really know very little, so you may ignore this post. I have found that my students often make the mistake of mixing up comparisons and assignments with negative numbers: if (x-3) do_something; I parenthesize, but every once in a while, I forget and commit this mistake, too. so, I would suggest that R simply warn about an ambiguity. that is, it could suggest a space either between the and - , or after the - . x -3 ## means comparison already x- 3 ## means assignment already but warn when x-3 ## ambiguity warning instead of assignment x-(whatever) ## ok just a suggestion... regards, /iaw Ivo Welch (ivo.we...@brown.edu, ivo.we...@gmail.com) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
hi gabor: this would be difficult to do. I don't think you want to
read my programs. it would give you an appreciation of what ugly
horror programs end users can write in the beautiful R language ;-).
clearly, one can work around the lack of such a feature.
multiple-return values are syntax sugar. but maybe it helps to
explain how I got to my own view. I had to send an R program to
someone who had never used it before. without knowing R, he could
literally read the entire program. the only thing that stumped him
was the multiple return values. In my program, he saw
f= function() { return(list(a=myvector1, b=myvector2)) }
result=f()
a= result$a
b= result$a
rm(result)
I had picked this method up over the years reading r-help. of course,
I had 10 return values, not two, each return value with its own long
name. I think it would have been a whole lot nicer if I could have
written FOR HIM simply
f= function() { return(myvector1,myvector2); }
(a,b)= f()
again, its syntax sugar. I would find such syntax a whole lot more
appealing. and I often write functions that pass back a main program,
but also some debug or other information. maybe I am the only one...
regards,
/iaw
On Sat, Mar 7, 2009 at 9:28 AM, Gabor Grothendieck
ggrothendi...@gmail.com wrote:
Why? Can you demonstrate any situations where its useful? Despite
having my own facility for this I've found that over the years I
have never used it.
On Sat, Mar 7, 2009 at 9:23 AM, ivo...@gmail.com wrote:
Gentlemen---these are all very clever workarounds, but please forgive me for
voicing my own opinion: IMHO, returning multiple values in a statistical
language should really be part of the language itself. there should be a
standard syntax of some sort, whatever it may be, that everyone should be
able to use and which easily transfers from one local computer to another.
It should not rely on clever hacks in the .Rprofile that are different from
user to user, and which leave a reader of end user R code baffled at first
by all the magic that is going on. Even the R tutorials for beginners should
show a multiple-value return example right at the point where function calls
and return values are first explained.
I really do not understand why the earlier implementation of multiple-value
returns was deprecated. then again, I am a naive end user, not a computer
language expert. I probably would not even understand the nuances of syntax
ambiguities that may have arisen. (this is my shortcoming.)
regards,
/iaw
On Mar 7, 2009 4:34am, Wacek Kusnierczyk
waclaw.marcin.kusnierc...@idi.ntnu.no wrote:
mark.braving...@csiro.au wrote:
The syntax for returning multiple arguments does not strike me as
particularly appealing. would it not possible to allow syntax like:
f= function() { return( rnorm(10), rnorm(20) ) }
(a,d$b) = f()
FWIW, my own solution is to define a multi-assign operator:
'%
# a must be of the form '{thing1;thing2;...}'
a
e
stopifnot( length( b) == length( a))
for( i in seq_along( a))
eval( call( '
NULL
}
you might want to have the check less stringent, so that rhs may consist
of more values that the lhs has variables. or even skip the check and
assign NULL to a[i] for i length(b). another idea is to allow %
be used with just one variable on the lhs.
here's a modified version:
'%
a
if (length(a) 1)
a
if (length(a) length(b))
b
e
for( i in seq_along( a))
eval( call( '
NULL }
{a; b} %
# a = 1; b = 2
a %
# a = 3
{a; b} %
# a = 5; b = NULL
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R bug or ghostscript bug or my bug?
Dear R developers:
The following R program produces a pdf file that does not survive
ghostscript distillation correctly. The undistilled version is at
http://welch.econ.brown.edu/temp/try.PDF while the distilled version
is at http://welch.econ.brown.edu/temp/try.pdf . When previewed, the
points are wrong in the distilled .pdf version, but only in one of the
two points invokations (huh?) . The program that generated the pdf
files is
x= 1:10; y1= x; y2= y1/2;
plot.one = function( x, y ) {
lines( x, y, col=blue);
points( x, y, col=blue, pch=21, cex=1);
}
pdf(file = try.PDF)
plot(0, type=n, xlim=c(1,10), ylim=c(1,10))
plot.one( x, y1 )
plot.one( x, y2)
dev.off()
system(ps2pdf14 try.PDF try.pdf) # distillation.
-
Obviously, the error can be in ghostscript, not in R. Or it can be
that R produces a pdf file that has some slight problems that do not
usually show up, except when distilled.
Before I get too badly flamed, feel free to ignore this. I am just
trying to help. It took me some time to whittle down the program to
isolate the problem.
R was invoked under OSX via R --vanilla and is version 2.8.1.
ghostscript is 8.62 (2008-02-29) under OSX.
(It should be easy to check whether this also occurs under linux.)
/iaw
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] error messages with dimension mismatch?
dear R developers: may I suggest that you add to the various error messages that relate to non-conformable arguments (e.g. matrix multiplication) or not multiple of(e.g., comparison) the actual two dimension numbers that do not match up? something like Error in t(a) %*% vcov(reg.model) : non-conformable arguments to Error in t(a) %*% vcov(reg.model) : non-conformable arguments (0, 5) regards, /ivo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] proposal: allowing alternative variance estimators in glm/lm
Dear Brian / Thomas: May I suggest a cheap and amateurish solution, obviously without much knowledge or intelligence about the subject? As a non-statistician user of R, maybe a hook functionality at strategic places could provide some flexibility without too much pain. I think replacing the standard output from summary.lm would be a bad idea (it could easily create errors downstream, when idiots like myself ask why don't I get the s.e. that stata produces? duh---you loaded heteroskedasticity adjustment, but forgot about it). But I think some flexibility to add more information would be a very good thing. Hooks that can be set by functions (perhaps cascades) would allow third parties to create additional statistics, that could survive future changes to the functions themselves, without requiring a full object paradigm. For example, summary.lm could provide two hooks that allow programmers to chain my own objects to either the ans$coefficients and the ans object. (I guess even one hook would do.) Well-thought-out hooks could also add to print methods, etc., without requiring complete function rewrites, and would survive future changes in the real R code itself. From the perspective of a first-time amateurish end-user, an invokation of library(lm.addnormalized) could then magically always add a normalized coefficient to the coefficient output. An invokation of library(lm.addheteroskedasticity) could magically always add heteroskedasticity se's and T-stats. And so on. As I said, I don't know what I am talking about. I am really a non-statistician end-user, who is really a bit over his head with all of this---I am using R not because it is sensible given my needs and abilities, but because I am in awe by many of its capabilities ( and because I enjoy Brian berating me while he offers me usually desparately needed help ;-) ). Regards, /ivo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] request to add argv[0]
Dear R Developers: This has come up repeatedly in the r-help mailing list, most recently in a thread started by myself. The answers have been changing over the years. Would it be possible and easy for R to offer a global read-only option that gives the name of the currently executing R script, i.e., the equivalent of argv[0] in C? (PS: An even better mechanism would be the ability to pick off multiple arguments following the .R file, different from commandArgs(), but this is not as important and probably more difficult as it would change the invokation syntax of R.) sincerely, /ivo welch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel Digest, Vol 34, Issue 5
actually, I can confirm now that gs AFPL 8.53 is the culprit here on #2, copied below again (though it is not a bug but a feature, albeit one you need to know about.) the -dSAFER switch, which appears in later versions of AFPL gs, not only eliminates renamefile and deletefile (manpage), but seemingly also allows only fonts in the GS_LIB path to be used export GS_LIB=/usr/local/share/texmf/fonts/type1/yandy:$GS_LIB fixes this protection problem for me.hope this will help some of you when you run R pdf files through gs.regards, /iaw [2] I do not believe this is an R bug, but I want to mention it anyway because it comes from interacting the R-created graphics with gs. for some odd reason, when I include these external lucida fonts, and create graphics in R, the R-created pdf can no longer be distilled by gs 8.53, because it stumbles into a safety issue. that is, all the gs scripts named 'ps2pdf*' have the option -dSAFER on by default, which disables the renamefile and deletefile operators, and it somehow prevents finding the fonts. (the bug does not appear if I do not use the external fonts.) http://groups.google.com/group/comp.lang.postscript/browse_frm/thread/3613c16aec64a9ed/a7c40582a0b5be1b?lnk=stq=ivowelrnum=1hl=en#a7c40582a0b5be1b regards, /iaw [[alternative HTML version deleted]] [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
