Re: [Rd] Behavior of R CMD build and library() w.r.t. setGeneric-likefunctions
FYI I resolved this with a combination of explicit variable declarations
and tweaking namespace environment visibility. I'd still like to get a
better understanding of how setGeneric is able to define functions that
are visible without the explicit variable declarations. Any insight into
this is appreciated.
Regards,
Brian
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Rowe, Brian - Eqty
NY
Sent: Thursday, September 23, 2010 6:44 PM
To: r-devel@r-project.org
Subject: [Rd] Behavior of R CMD build and library() w.r.t.
setGeneric-likefunctions
Hello developeRs,
Apologies in advance for a rather long email, but to describe the
problem, I need to step through many details. I have been working on a
new dispatching system (futile.paradigm on CRAN) based on functional
programming concepts that is an alternative to S3 and S4 dispatching. I
use a declarative syntax using guard statements to control the
dispatching between function variants. I also provide post assertions
via an 'ensure' command that programatically behave similar to the
'guard' command. In a sense, these work like setGeneric/setMethod in S4.
As a simple example, I write code like this:
guard(month.date, isa(Date,date))
ensure(month.date, as.numeric(result) < 13)
month.date <- function(date) format(date, '%m')
guard(month.int, is.numeric(date))
month.int <- function(date) month(i2date(date))
and call it like this:
> month(20100913)
[1] "09"
Behind the scenes, the guard command is using 'assign' to create a
parent function with the name 'month'. This can be done explicitly as
well, although it is typically not necessary. The parent definition
looks like this:
month <- function(...) UseFunction('month',...)
The package works fine when I'm writing scripts, but all heck breaks
loose when I try to write a package that depends on futile.paradigm.
When I run R CMD check, it doesn't seem that the guard commands are
being executed. A less likely hypothesis is that they are being deleted
by the cleanEx() function.
* checking examples ... ERROR
Running examples in 'pars.core-Ex.R' failed.
The error most likely occurred in:
> set_date(20100921)
Error: could not find function "set_date"
Execution halted
If I add the explicit function definition for 'month' as shown above, I
get one of my own error messages indicating that no guard statements
were executed.
> set_date(20100921)
Error in UseFunction("set_date", ...) :
Function must have guards for functional dispatching
Calls: set_date -> UseFunction
Execution halted
I decided to bypass the check process and just install the built package
to see if it is an issue with check as opposed to the package.
Unfortunately, it seems that when the package is built, the guard
commands get stripped from the package.
> library(futile.paradigm)
Loading required package: futile.options
> debug(guard)
> library(pars.core)
Loading required package: futile.logger
It's unclear to me why this happens when setClass, setGeneric, etc work
under seemingly similar conditions. Is this because of the export*
declarations in the NAMESPACE? What happens in the R CMD build process
that strips these function calls and their side-effects? Finally, what
do I need to do to make my 'guard' and 'ensure' commands operate
properly in a package context?
Warm Regards,
Brian Rowe
--
This message w/attachments (message) is intended solely ...{{dropped:7}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
This message w/attachments (message) is intended solely ...{{dropped:7}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fourteen patches to speed up R
Luke - Thanks for your comments on the speed patches I submitted.
I'm glad you like patch-transpose, patch-for, patch-evalList, and
patch-vec-arith. I'll be interested to hear what you or other people
think about patch-dollar and patch-vec-subset after you've had more
time to consider them. (Recall I later posted a split of
patch-vecsubset into patch-vec-subset and a new patch-subscript,
fixing in patch-subscript a bug in my original combined patch.)
Regarding patch-square and patch-sum-prod, you make different changes
that address the largest inefficiencies, but I'd like to do some runs
comparing your version with mine to see how big the remaining
differences are. This is complicated by the fact that your changes to
sum and prod seem to encounter a bug in the C compiler I'm using (gcc
4.2.4 for i486-linux-gnu) at optimization level -O2 (the default for
the R configuration), the effect of which is for sum to deliver the
right answer, but just as slowly as before. This doesn't happen with
-O3. I'll investigate this further and report the conclusion.
Similarly, I'll do some more timing tests regarding patch-protect,
patch-fast-base, patch-fast-spec, and patch-save-alloc, and then
comment further on the gains that they produce.
Regarding patch-matprod, the issue of what BLAS routines do with NaN
and NA seems like it's one that needs to be resolved, preferably in a
way that doesn't slow down vector dot products by a factor of six.
However, I don't know what actual problem reports motivated the
current costly check for NAs. This all interacts with the extreme
slowness on some machines of arithmetic on LDOUBLEs, which also seems
like it needs some resolution. It's not clear to me what the
expectations regarding accuracy of functions like sum should be.
One could certainly argue that users would expect the same accuracy
as adding them up with "+", and no huge slowdown from trying to get
better accuracy. But maybe there's some history here, or packages
that depend on increased accuracy (though of course there's no
guarantee that a C "long double" will actually be bigger than a
"double".)
Regarding patch-parens, I don't understand your reluctance to
incorporate this two-line code change. According to my timing tests
(medians of five runs), it speeds up the test-parens.r script by 4.5%.
(Recall this is "for (i in 1:n) d <- (a+1)/(a*(b+c))".) This is not
a huge amount, but of course the speedup for the actual parenthesis
operator is greater, since there is other overhead in this test. It
would be even better to make all BUILTIN operators faster (which my
patch-evalList does), but there are limits to how much is possible.
The fact that "(" is conceptually a BUILTIN rather than a SPECIAL
doesn't seem relevant to me. "{" is also conceptually a BUILTIN.
Both are "special" from the point of view of the users, few of whom
will even imagine that one could call "(" and "{" as ordinary
functions. Even if they can imagine this, it makes no difference,
since the patch has no user-visible effects. If one is worried that
someone reading the code in src/main/eval.c might become confused
about the semantics of parentheses, a two-line comment saying "Parens
are conceptually a BUILTIN but are implemented as a SPECIAL to bypass
the overhead of creating an evaluated argument list" would avoid any
problem.
As an analogy, consider a C compiler generating code for "2*x". One
could argue that multiplication is conceptually repeated addition, so
converting this to "x+x" is OK, but converting it to "x<<1" would be
wrong. But I think no one would argue this. Rather, everyone would
expect the compiler to choose between "x+x" and "x<<1" purely on the
basis of which one is faster.
Radford
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] error with browseURL
> link="http://search.soufun.com/bbs/search.jsp?fld=all&city=%b9%e3%d6%dd&forum=%bd%f1%c8%d5%c0%f6%c9%e1%28%e2%f9%be%b0%bb%a8%d4%b0%29&sl=post&q=%c4%cf%b9%fa%b0%c2%c1%d6%c6%a5%bf%cb%bb%a8%d4%b0%20%ce%ac%c8%a8&serachtype=all&fw=forum&sort=score&imageField.x=25&imageField.y=8"; > browseURL(link) Error in shell.exec(url) : file name conversion problem > sessionInfo() R version 2.11.1 Patched (2010-08-25 r52804) Platform: i386-pc-mingw32 (32-bit) locale: [1] LC_COLLATE=Chinese (Simplified)_People's Republic of China.936 [2] LC_CTYPE=Chinese (Simplified)_People's Republic of China.936 [3] LC_MONETARY=Chinese (Simplified)_People's Republic of China.936 [4] LC_NUMERIC=C [5] LC_TIME=Chinese (Simplified)_People's Republic of China.936 attached base packages: [1] stats graphics grDevices utils datasets methods base The problem remains in R 2.12.0. Best -- Wincent Rong-gui HUANG Doctoral Candidate Dept of Public and Social Administration City University of Hong Kong http://asrr.r-forge.r-project.org/rghuang.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
