Re: [Rd] rank(, ties.method="last")
> Suharto Anggono Suharto Anggono via R-devel
> on Wed, 21 Oct 2015 22:44:57 -0700 writes:
> --
> Henric Winell <[hidden email]>
> on Wed, 21 Oct 2015 13:43:02 +0200 writes:
>> Den 2015-10-21 kl. 07:24, skrev Suharto Anggono Suharto Anggono via
R-devel:
>>> Marius Hofert-4--
Den 2015-10-09 kl. 12:14, skrev Martin Maechler:
I think so: the code above doesn't seem to do the right thing.
Consider
the following example:
> x <- c(1, 1, 2, 3)
> rank2(x, ties.method = "last")
[1] 1 2 4 3
That doesn't look right to me -- I had expected
> rev(sort.list(x, decreasing = TRUE))
[1] 2 1 3 4
>>>
>>> Indeed, well spotted, that seems to be correct.
>>>
Henric Winell
>>> --
>>>
>>> In the particular example (of length 4), what is really wanted is the
following.
>>> ind <- integer(4)
>>> ind[sort.list(x, decreasing=TRUE)] <- 4:1
>>> ind
>> You don't provide the output here, but 'ind' is, of course,
>>> ind
>> [1] 2 1 3 4
>>> The following gives the desired result:
>>> sort.list(rev(sort.list(x, decreasing=TRUE)))
>> And, again, no output, but
>>> sort.list(rev(sort.list(x, decreasing=TRUE)))
>> [1] 2 1 3 4
>> Why is it necessary to use 'sort.list' on the result from
>> 'rev(sort.list(...'?
> You can try all kind of code on this *too* simple example and do
> experiments. But let's approach this a bit more scientifically
> and hence systematically:
> Look at rank {the R function definition} to see that
> for the case of no NA's,
> rank(x, ties.method = "first') ===sort.list(sort.list(x))
> If you assume that to be correct and want to define "last" to be
> correct as well (in the sense of being "first"-consistent),
> it is clear that
> rank(x, ties.method = "last) === rev(sort.list(sort.list(rev(x
> must also be correct. I don't think that *any* of the proposals
> so far had a correct version [but the too simplistic examples
> did not show the problems].
> In R-devel (the R development) version of today, i.e., svn
> revision >= 69549, the implementation of ties.method = "last'
> uses
> ## == rev(sort.list(sort.list(rev(x :
> if(length(x) == 0) integer(0)
> else { i <- length(x):1L
> sort.list(sort.list(x[i]))[i] },
> which is equivalent to using rev() but a bit more efficient.
> Martin Maechler, ETH Zurich
> --
> I'll defend that my code is correct in general.
> All comes from the fact that, if p is a permutation of 1:n,
> { ind <- integer(n); ind[p] <- 1:n; ind }
> gives the same result to
> sort.list(p)
Definitely; a known fact
(and that's how sort.list() -> order() is basically
implemented in R's C source code.)
> You can make sense of it like this. In ind[p] <- 1:n, ind[1] is the
position where p == 1. So, ind[1] is the position of the smallest element of p.
So, it is the first element of sort.list(p). Next elements follow.
> That's why 'sort.list' is used for ties.method="first" and
ties.method="random" in function 'rank' in R. When p gives the desired order,
> { ind <- integer(n); ind[p] <- 1:n; ind }
> gives ranks of the original elements based on the order. The original
element in position p[1] has rank 1, the original element in position p[2] has
rank 2, and so on.
> Now, I say that rev(sort.list(x, decreasing=TRUE)) gives the desired
order for ties.method="last". With the order, the elements are from smallest to
largest; for equal elements, elements are ordered by their positions backwards.
You are right, Suharto :
Your proposed
sort.list(rev(sort.list(x, decreasing=TRUE)))
is also correct and the same as my
rev(sort.list(sort.list(rev(x
from above
nd your variant will even be slightly more efficient if implemented optimally !
Indeed, I was thinking wrongly when I wrote
"I don't think that *any* of the proposals so far had a correct version"
because your proposal *was* correct.
I apologize for my wrong claim.
Best regards,
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] alternative read.arff function for the package foreign
Hello everyone, I guess this is really directed to the R Core Team, but I
understand that this is the best channel to submit this (please correct me
if I'm wrong!).
I would like to submit a function to consideration, as an upgrade for the
current read.arff in package foreign. Code in github:
https://raw.githubusercontent.com/jumanbar/misc/master/R/read.arff.R
This function is a modified version of the one found in the foreign
package. This changes aim to correct a problem I found with the standard
read.arff: levels in factors do not match what's explicitly written in the
original arff file.
For example, if a nominal attribute in some arff datafile has this line in
the header:
@attribute X {'A', 'B', 'C'}
But the data only have instances of 'A' and 'B', but not 'C', then what R
imports is:
dat <- read.arff("data.arff")
levels(dat$X)
[1] "a" "b"
Not only the levels are in lowercase, but also there is one level which has
disappeared. This is troublesome, specially if I wish to export my data
frame to an arff file using write.arff.
With this version of read.arff, when dealing with the aforementioned case,
I get:
levels(dat$X)
[1] "A" "B" "C"
And also I can set a couple of parameters which can help me tune up my work
flow to better fit my needs (for example, reading only a limited number of
lines, since I just want to make a couple of fast tests and therefore, I
don't need the whole dataset).
Thanks for your time,
Juan Manuel
--
MSc. Juan M. Barreneche Sarasola
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] C_LogLin (stats/loglin)
Hi everyone,
I have a question regarding a C function of the "stats" package in R.
I tried to understand the loglin basic function of the stats
package implemented in
R. The implemented function itself runs without any problem (perhaps
see sample). When I
ran it line by line it stopped at the lines 23-24 of the
loglin-function; (the following line):
z <- .Call(C_LogLin, dtab, conf, table, start, nmar, eps, iter)
.Call calls the C/C++ function C_LogLin. But when I am running it
line by line I get
the following error on line 23/24:
Error: object 'C_LogLin' not found
Hence, my questions:
1. Where does the original loglin function get the C_LogLin
function from (some libraries? where are they stored)?
2. Why does it not work in the normal R command (line by) line but in
the implemented loglin function?
3. Is it possible to isolate the C_LogLin function so I can use it
in other scripts or programming languages e.g. Matlab?
Thank you in advance for your help,
Kai
#Sample
# Example data
mytable = array(0,dim=c(3,4,5))
mytable[1,,1] = c(35,26,36,29); mytable[2,,1] = c(21,12,26,27);
mytable[3,,1] = c(9,26,23,38);
mytable[1,,2] = c(43,26,89,26); mytable[2,,2] = c(78,42,32,9);
mytable[3,,2] = c(34,39,42,51);
mytable[1,,3] = c(51,72,62,21); mytable[2,,3] = c(6,52,71,32);
mytable[3,,3] = c(35,36,48,21);
mytable[1,,4] = c(12,26,53,42); mytable[2,,4] = c(96,75,81,56);
mytable[3,,4] = c(32,65,75,63);
mytable[1,,5] = c(21,18,24,33); mytable[2,,5] = c(22,56,36,91);
mytable[3,,5] = c(32,65,63,14);
# Call of the original function works fine
loglin(mytable,list(c(1,2),c(1,3)))
# line by line does not work
table = mytable; margin = list(c(1,2),c(1,3)); start = rep(1,
length(table)); fit = FALSE; eps = 0.1;
iter = 20L; param = FALSE; print = TRUE;
rfit <- fit
dtab <- dim(table)
nvar <- length(dtab)
ncon <- length(margin)
conf <- matrix(0L, nrow = nvar, ncol = ncon)
nmar <- 0
varnames <- names(dimnames(table))
for (k in seq_along(margin)) {
tmp <- margin[[k]]
if (is.character(tmp)) {
## Rewrite margin names to numbers
tmp <- match(tmp, varnames)
margin[[k]] <- tmp
}
conf[seq_along(tmp), k] <- tmp
nmar <- nmar + prod(dtab[tmp])
}
ntab <- length(table)
if (length(start) != ntab ) stop("'start' and 'table' must be same length")
z <- .Call(C_LogLin, dtab, conf, table, start, nmar, eps, iter)
...
--
Kai Nitschke, Dipl.-Psych.
Division of Functional Brain Imaging (FBI)
Dept. of Neurology, University of Freiburg
Breisacher Str. 64, 79095 Freiburg, Germany
Phone: +49 (0) 761 270 - 50410
Email: kai.nitsc...@uniklinik-freiburg.de
URL: http://www.uniklinik-freiburg.de/fbi/people/kai-nitschke.html
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C_LogLin (stats/loglin)
Kai,
Apologies for the double message, it didn't go to the list last time.
On Thu, Oct 22, 2015 at 9:59 AM, Kai Nitschke <
kai.nitsc...@uniklinik-freiburg.de> wrote:
>
> “.Call” calls the C/C++ function “C_LogLin”. But when I am running it line
> by line I get
> the following error on line 23/24:
> Error: object 'C_LogLin' not found
>
> Hence, my questions:
> 1. Where does the original “loglin” function get the “C_LogLin” function
> from (some libraries? where are they stored)?
>
The libraries are in the stats package, built from the c code found in the
/src directory of the package's source code.
> 2. Why does it not work in the normal R command (line by) line but in the
> implemented “loglin” function?
>
Notice that C_LogLin is not in quotes. That is actually an R object, not a
string, and it is one that is not exported by the stats package.
stats:::C_LogLin would probably work.
> 3. Is it possible to isolate the “C_LogLin” function so I can use it in
> other scripts or programming languages e.g. Matlab?
>
A function called by the .Call interface is going to operate on R's
internal representation of R objects, called SEXPs, It won't work in other
languages without major reworking (I can't say how major without looking
for at the code to see if, e.g., it's just a wrapper that calls another c
function that might be amenable to that). Even then, you'd have to look at
if/how it deals with NAs, etc.
~G
On Thu, Oct 22, 2015 at 9:59 AM, Kai Nitschke <
kai.nitsc...@uniklinik-freiburg.de> wrote:
> Hi everyone,
>
> I have a question regarding a C function of the "stats" package in R.
>
> I tried to understand the “loglin” basic function of the “stats” package
> implemented in
> R. The implemented function itself runs without any problem (perhaps see
> sample). When I
> ran it line by line it stopped at the lines 23-24 of the loglin-function;
> (the following line):
> z <- .Call(C_LogLin, dtab, conf, table, start, nmar, eps, iter)
>
> “.Call” calls the C/C++ function “C_LogLin”. But when I am running it line
> by line I get
> the following error on line 23/24:
> Error: object 'C_LogLin' not found
>
> Hence, my questions:
> 1. Where does the original “loglin” function get the “C_LogLin” function
> from (some libraries? where are they stored)?
> 2. Why does it not work in the normal R command (line by) line but in the
> implemented “loglin” function?
> 3. Is it possible to isolate the “C_LogLin” function so I can use it in
> other scripts or programming languages e.g. Matlab?
>
> Thank you in advance for your help,
> Kai
>
>
> #Sample
>
> # Example data
> mytable = array(0,dim=c(3,4,5))
> mytable[1,,1] = c(35,26,36,29); mytable[2,,1] = c(21,12,26,27);
> mytable[3,,1] = c(9,26,23,38);
> mytable[1,,2] = c(43,26,89,26); mytable[2,,2] = c(78,42,32,9);
> mytable[3,,2] = c(34,39,42,51);
> mytable[1,,3] = c(51,72,62,21); mytable[2,,3] = c(6,52,71,32);
> mytable[3,,3] = c(35,36,48,21);
> mytable[1,,4] = c(12,26,53,42); mytable[2,,4] = c(96,75,81,56);
> mytable[3,,4] = c(32,65,75,63);
> mytable[1,,5] = c(21,18,24,33); mytable[2,,5] = c(22,56,36,91);
> mytable[3,,5] = c(32,65,63,14);
>
> # Call of the original function works fine
> loglin(mytable,list(c(1,2),c(1,3)))
>
> # line by line does not work
> table = mytable; margin = list(c(1,2),c(1,3)); start = rep(1,
> length(table)); fit = FALSE; eps = 0.1;
> iter = 20L; param = FALSE; print = TRUE;
> rfit <- fit
> dtab <- dim(table)
> nvar <- length(dtab)
> ncon <- length(margin)
> conf <- matrix(0L, nrow = nvar, ncol = ncon)
> nmar <- 0
> varnames <- names(dimnames(table))
> for (k in seq_along(margin)) {
> tmp <- margin[[k]]
> if (is.character(tmp)) {
> ## Rewrite margin names to numbers
> tmp <- match(tmp, varnames)
> margin[[k]] <- tmp
> }
> conf[seq_along(tmp), k] <- tmp
> nmar <- nmar + prod(dtab[tmp])
> }
> ntab <- length(table)
> if (length(start) != ntab ) stop("'start' and 'table' must be same length")
> z <- .Call(C_LogLin, dtab, conf, table, start, nmar, eps, iter)
> ...
>
>
> --
> Kai Nitschke, Dipl.-Psych.
>
> Division of Functional Brain Imaging (FBI)
> Dept. of Neurology, University of Freiburg
>
> Breisacher Str. 64, 79095 Freiburg, Germany
> Phone: +49 (0) 761 270 - 50410
> Email: kai.nitsc...@uniklinik-freiburg.de
> URL: http://www.uniklinik-freiburg.de/fbi/people/kai-nitschke.html
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Gabriel Becker, PhD
Associate Scientist (Bioinformatics)
Genentech Research
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Changed behaviour when passing a function?
Hi all,
When teaching this year's class, I was quite amazed that one of my examples
didn't work any longer. I wanted to illustrate the importance of
match.fun() with following code:
myfun <- function(x, FUN, ...){
FUN(x, ...)
}
round <- 2
myfun(0.85, FUN = round, digits=1)
I expected to see an error, but this code doesn't generate one. It seems as
if in the current R version match.fun() is added automatically.
I've scrolled through the complete R News section specifying all the
changes and bug fixes, starting from 3.0.0. I couldn't find anything on
that change in behaviour though. Where can I find more information on what
changed exactly?
Thanks
Cheers
Joris
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 (0)9 264 61 79
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check --as-cran without qpdf
On 10/10/2015 6:30 AM, Kirill Müller wrote: Today, a package that has an HTML vignette (but no PDF vignette) failed R CMD check --as-cran on a system without qpdf. I think the warning originates here [1], due to a premature check for the existence of qpdf [2]. Setting R_QPDF=true (as in /bin/true) helped, but perhaps it's possible to check qpdf existence only when it matters. I have attached a patch (untested) that could serve as a starting point. The code links correspond to SVN revision 69500. Thanks. The patch looks fine, and is now in R-devel and (in a few minutes) in R-patched. Thanks! Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Missing parenthesis in R-exts.texi
Line 1204 (right now) of svn/r-devel/doc/manual/R-exts.texi has
dest <- file.path(R_PACKAGE_DIR, paste0('bin', R_ARCH)
which lacks a closing ) -- two open, only one close right now.
Dirk
[1] I would have reported a bug, but I am aware of a recent and
not-so-friendly response when bugzilla was used to report a typo.
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Missing parenthesis in R-exts.texi
On 22/10/2015 2:38 PM, Dirk Eddelbuettel wrote:
Line 1204 (right now) of svn/r-devel/doc/manual/R-exts.texi has
dest <- file.path(R_PACKAGE_DIR, paste0('bin', R_ARCH)
which lacks a closing ) -- two open, only one close right now.
Dirk
[1] I would have reported a bug, but I am aware of a recent and
not-so-friendly response when bugzilla was used to report a typo.
Thanks, now fixed. Generally reporting here creates a lot less work
than filing a bug report, so we prefer it. The only negative is that
some reports here get lost.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Best way to implement optional functions?
I'm planning on adding some new WebGL functionality to the rgl package, but it will pull in a very large number of dependencies. Since many people won't need it, I'd like to make the new parts optional. The general idea I'm thinking of is to put the new stuff into a separate package, and have rgl "Suggest" it. But I'm not sure whether these functions should only be available in the new package (so users would have to attach it to use them), or whether they should be in rgl, but fail if the new package is not available for loading. Can people suggest other packages that solve this kind of problem in a good way? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best way to implement optional functions?
On Thu, 2015-10-22 at 15:55 -0400, Duncan Murdoch wrote:
> I'm planning on adding some new WebGL functionality to the rgl package,
> but it will pull in a very large number of dependencies. Since many
> people won't need it, I'd like to make the new parts optional.
>
> The general idea I'm thinking of is to put the new stuff into a separate
> package, and have rgl "Suggest" it. But I'm not sure whether these
> functions should only be available in the new package (so users would
> have to attach it to use them), or whether they should be in rgl, but
> fail if the new package is not available for loading.
>
> Can people suggest other packages that solve this kind of problem in a
> good way?
We have a number of functions in PerformanceAnalytics or
PortfolioAnalytics that rely on packages in 'Suggests'.
The model we have chiefly used is
stopifnot("package:MASS" %in% search() || require("MASS",quietly=TRUE))
of course, it is now no longer recommended to do it this way, so we'll
probably need to test and load namespaces instead.
It makes sense to me to have such functions in the main package, and
provide pointers in the documentation and the error message which
describe that the other package is required to be available for the
function to work.
Regards,
Brian
--
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best way to implement optional functions?
On 22 October 2015 at 15:08, Brian G. Peterson wrote:
| On Thu, 2015-10-22 at 15:55 -0400, Duncan Murdoch wrote:
| > I'm planning on adding some new WebGL functionality to the rgl package,
| > but it will pull in a very large number of dependencies. Since many
| > people won't need it, I'd like to make the new parts optional.
| >
| > The general idea I'm thinking of is to put the new stuff into a separate
| > package, and have rgl "Suggest" it. But I'm not sure whether these
| > functions should only be available in the new package (so users would
| > have to attach it to use them), or whether they should be in rgl, but
| > fail if the new package is not available for loading.
| >
| > Can people suggest other packages that solve this kind of problem in a
| > good way?
|
| We have a number of functions in PerformanceAnalytics or
| PortfolioAnalytics that rely on packages in 'Suggests'.
|
| The model we have chiefly used is
|
| stopifnot("package:MASS" %in% search() || require("MASS",quietly=TRUE))
|
| of course, it is now no longer recommended to do it this way, so we'll
| probably need to test and load namespaces instead.
|
| It makes sense to me to have such functions in the main package, and
| provide pointers in the documentation and the error message which
| describe that the other package is required to be available for the
| function to work.
Rcmdr by John Fox has also done this for many years -- and has also moved
back from "everything in Depends (or Imports)" to "most things in Suggests".
As I maintain the package in Debian I had to add a fair number of packages
because the requirement was "hard" (via Depends/Imports) so that the extra
package was needed to actually start Rcmdr.
Generally, a soft requirement is much better, especially when coupled with
appropriate tests -- eg via requireNamespace("packageName", quietly=TRUE) --
and this can be coupled with notifying the user about the optional package.
Also note that CRAN got itself a new Repo Policy revision where this was added:
A package listed in `Suggests' or `Enhances' should be used
conditionally in examples or tests if it cannot straightforwardly be
installed on the major R platforms.
This is step forward as it recognises that Suggests: need to be tested for.
Sadly it still waters it down via the "not straightforwardly". But then Rome
wasn't built with a single Policy Revision either ...
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changed behaviour when passing a function?
Joris,
When a function call (detected via the parenthesis) R does the equivalent
of get(..., mode="function") to resolve the symbol.
> round = 2
> round(5.3)
[1] 5
> get("round")
[1] 2
> get("round", mode = "function")
function (x, digits = 0) .Primitive("round")
It's done this for a while, but didn't always do it, I think. I don't know
when the change happened.
Best,
~G
On Thu, Oct 22, 2015 at 10:59 AM, Joris Meys wrote:
> Hi all,
>
> When teaching this year's class, I was quite amazed that one of my examples
> didn't work any longer. I wanted to illustrate the importance of
> match.fun() with following code:
>
> myfun <- function(x, FUN, ...){
> FUN(x, ...)
> }
> round <- 2
> myfun(0.85, FUN = round, digits=1)
>
> I expected to see an error, but this code doesn't generate one. It seems as
> if in the current R version match.fun() is added automatically.
>
> I've scrolled through the complete R News section specifying all the
> changes and bug fixes, starting from 3.0.0. I couldn't find anything on
> that change in behaviour though. Where can I find more information on what
> changed exactly?
>
> Thanks
> Cheers
> Joris
>
> --
> Joris Meys
> Statistical consultant
>
> Ghent University
> Faculty of Bioscience Engineering
> Department of Mathematical Modelling, Statistics and Bio-Informatics
>
> tel : +32 (0)9 264 61 79
> joris.m...@ugent.be
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Gabriel Becker, PhD
Associate Scientist (Bioinformatics)
Genentech Research
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changed behaviour when passing a function?
On 22/10/2015 1:59 PM, Joris Meys wrote:
Hi all,
When teaching this year's class, I was quite amazed that one of my examples
didn't work any longer. I wanted to illustrate the importance of
match.fun() with following code:
myfun <- function(x, FUN, ...){
FUN(x, ...)
}
round <- 2
myfun(0.85, FUN = round, digits=1)
I expected to see an error, but this code doesn't generate one. It seems as
if in the current R version match.fun() is added automatically.
I've scrolled through the complete R News section specifying all the
changes and bug fixes, starting from 3.0.0. I couldn't find anything on
that change in behaviour though. Where can I find more information on what
changed exactly?
When you say "current R version", what do you mean? I see an error:
> myfun <- function(x, FUN, ...){
+ FUN(x, ...)
+ }
> round <- 2
> myfun(0.85, FUN = round, digits=1)
Error in myfun(0.85, FUN = round, digits = 1) (from #2) :
could not find function "FUN"
I see this in 3.2.2, R-patched and R-devel.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changed behaviour when passing a function?
Of course (and unsurprisingly) Duncan is correct. I see that behavior in R
3.1.0, as well as the modern ones Duncan mentioned.
What I said is true, as far as it goes, but the symbol being resolved is
FUN, so when looking for a function it doesn't find the function version of
round.
Did you perhaps have a function named FUN in your global environment? If so
you are being bitten by what I mentioned before.
> FUN = function(...) 1
> myfun <- function(x, FUN, ...){
+ FUN(x, ...)
+ }
> round <- 2
> myfun(0.85, FUN = round, digits=1)
[1] 1
~G
On Thu, Oct 22, 2015 at 2:25 PM, Duncan Murdoch
wrote:
> On 22/10/2015 1:59 PM, Joris Meys wrote:
>
>> Hi all,
>>
>> When teaching this year's class, I was quite amazed that one of my
>> examples
>> didn't work any longer. I wanted to illustrate the importance of
>> match.fun() with following code:
>>
>> myfun <- function(x, FUN, ...){
>> FUN(x, ...)
>> }
>> round <- 2
>> myfun(0.85, FUN = round, digits=1)
>>
>> I expected to see an error, but this code doesn't generate one. It seems
>> as
>> if in the current R version match.fun() is added automatically.
>>
>> I've scrolled through the complete R News section specifying all the
>> changes and bug fixes, starting from 3.0.0. I couldn't find anything on
>> that change in behaviour though. Where can I find more information on what
>> changed exactly?
>>
>>
> When you say "current R version", what do you mean? I see an error:
>
> > myfun <- function(x, FUN, ...){
> + FUN(x, ...)
> + }
> > round <- 2
> > myfun(0.85, FUN = round, digits=1)
> Error in myfun(0.85, FUN = round, digits = 1) (from #2) :
> could not find function "FUN"
>
> I see this in 3.2.2, R-patched and R-devel.
>
> Duncan Murdoch
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Gabriel Becker, PhD
Associate Scientist (Bioinformatics)
Genentech Research
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changed behaviour when passing a function?
On 22/10/2015 5:44 PM, Gabriel Becker wrote:
Of course (and unsurprisingly) Duncan is correct. I see that behavior
in R 3.1.0, as well as the modern ones Duncan mentioned.
What I said is true, as far as it goes, but the symbol being resolved
is FUN, so when looking for a function it doesn't find the function
version of round.
It comes down to the order of operations: we need to bind something to
FUN, and we need to look up a function named FUN. Since the binding
comes first, it fails. If it happened in the other order: look for a
function named FUN,
find an unresolved binding to "round", look in the caller frame for a
function named round, we wouldn't get the error. But that's not how we
do it.
Duncan Murdoch
Did you perhaps have a function named FUN in your global environment?
If so you are being bitten by what I mentioned before.
> FUN = function(...) 1
> myfun <- function(x, FUN, ...){
+ FUN(x, ...)
+ }
> round <- 2
> myfun(0.85, FUN = round, digits=1)
[1] 1
~G
On Thu, Oct 22, 2015 at 2:25 PM, Duncan Murdoch
mailto:murdoch.dun...@gmail.com>> wrote:
On 22/10/2015 1:59 PM, Joris Meys wrote:
Hi all,
When teaching this year's class, I was quite amazed that one
of my examples
didn't work any longer. I wanted to illustrate the importance of
match.fun() with following code:
myfun <- function(x, FUN, ...){
FUN(x, ...)
}
round <- 2
myfun(0.85, FUN = round, digits=1)
I expected to see an error, but this code doesn't generate
one. It seems as
if in the current R version match.fun() is added automatically.
I've scrolled through the complete R News section specifying
all the
changes and bug fixes, starting from 3.0.0. I couldn't find
anything on
that change in behaviour though. Where can I find more
information on what
changed exactly?
When you say "current R version", what do you mean? I see an error:
> myfun <- function(x, FUN, ...){
+ FUN(x, ...)
+ }
> round <- 2
> myfun(0.85, FUN = round, digits=1)
Error in myfun(0.85, FUN = round, digits = 1) (from #2) :
could not find function "FUN"
I see this in 3.2.2, R-patched and R-devel.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Gabriel Becker, PhD
Associate Scientist (Bioinformatics)
Genentech Research
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best way to implement optional functions?
On 10/22/2015 03:55 PM, Duncan Murdoch wrote: I'm planning on adding some new WebGL functionality to the rgl package, but it will pull in a very large number of dependencies. Since many people won't need it, I'd like to make the new parts optional. The general idea I'm thinking of is to put the new stuff into a separate package, and have rgl "Suggest" it. But I'm not sure whether these functions should only be available in the new package (so users would have to attach it to use them), or whether they should be in rgl, but fail if the new package is not available for loading. Can people suggest other packages that solve this kind of problem in a good way? I do something similar in several packages. I would distinguish between the situation where the new functions have some functionality without all the extra dependencies, and the case where they really do not. In the former case it makes sense to put the functions in rgl and then fail when the extra functionality is demanded and not available. In the latter case, it "feels like" you are trying to defeat Depends: or Imports:. That route has usually gotten me in trouble. Another thing you might want to consider is that, at least for awhile, the new functions in rglPlus will probably be less stable then those in rgl. Being able to change those and update rglPlus without needing to update rgl can be a real advantage (i.e. if the API for the new functions is in rgl, and you need to change it, then you are required to notify all the package maintainers that depend on rgl, do reverse testing, and you have to explain that your update of rgl is going to break rglPlus and you have a new version of that but you cannot submit that yet because it will not work until the new rgl is in place.) Paul Duncan Murdoch __ 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] C_LogLin (stats/loglin)
Hi Gabriel,
it actually works with: z <- .Call(stats:::C_LogLin, dtab, conf,
table, start, nmar, eps, iter).
This helps me a great deal. I will inform myself further about SEXPs.
Thank you very much,
Kai
Zitat von Gabriel Becker :
Kai,
Apologies for the double message, it didn't go to the list last time.
On Thu, Oct 22, 2015 at 9:59 AM, Kai Nitschke <
kai.nitsc...@uniklinik-freiburg.de> wrote:
“.Call” calls the C/C++ function “C_LogLin”. But when I am running it line
by line I get
the following error on line 23/24:
Error: object 'C_LogLin' not found
Hence, my questions:
1. Where does the original “loglin” function get the “C_LogLin” function
from (some libraries? where are they stored)?
The libraries are in the stats package, built from the c code found in the
/src directory of the package's source code.
2. Why does it not work in the normal R command (line by) line but in the
implemented “loglin” function?
Notice that C_LogLin is not in quotes. That is actually an R object, not a
string, and it is one that is not exported by the stats package.
stats:::C_LogLin would probably work.
3. Is it possible to isolate the “C_LogLin” function so I can use it in
other scripts or programming languages e.g. Matlab?
A function called by the .Call interface is going to operate on R's
internal representation of R objects, called SEXPs, It won't work in other
languages without major reworking (I can't say how major without looking
for at the code to see if, e.g., it's just a wrapper that calls another c
function that might be amenable to that). Even then, you'd have to look at
if/how it deals with NAs, etc.
~G
On Thu, Oct 22, 2015 at 9:59 AM, Kai Nitschke <
kai.nitsc...@uniklinik-freiburg.de> wrote:
Hi everyone,
I have a question regarding a C function of the "stats" package in R.
I tried to understand the “loglin” basic function of the “stats” package
implemented in
R. The implemented function itself runs without any problem (perhaps see
sample). When I
ran it line by line it stopped at the lines 23-24 of the loglin-function;
(the following line):
z <- .Call(C_LogLin, dtab, conf, table, start, nmar, eps, iter)
“.Call” calls the C/C++ function “C_LogLin”. But when I am running it line
by line I get
the following error on line 23/24:
Error: object 'C_LogLin' not found
Hence, my questions:
1. Where does the original “loglin” function get the “C_LogLin” function
from (some libraries? where are they stored)?
2. Why does it not work in the normal R command (line by) line but in the
implemented “loglin” function?
3. Is it possible to isolate the “C_LogLin” function so I can use it in
other scripts or programming languages e.g. Matlab?
Thank you in advance for your help,
Kai
#Sample
# Example data
mytable = array(0,dim=c(3,4,5))
mytable[1,,1] = c(35,26,36,29); mytable[2,,1] = c(21,12,26,27);
mytable[3,,1] = c(9,26,23,38);
mytable[1,,2] = c(43,26,89,26); mytable[2,,2] = c(78,42,32,9);
mytable[3,,2] = c(34,39,42,51);
mytable[1,,3] = c(51,72,62,21); mytable[2,,3] = c(6,52,71,32);
mytable[3,,3] = c(35,36,48,21);
mytable[1,,4] = c(12,26,53,42); mytable[2,,4] = c(96,75,81,56);
mytable[3,,4] = c(32,65,75,63);
mytable[1,,5] = c(21,18,24,33); mytable[2,,5] = c(22,56,36,91);
mytable[3,,5] = c(32,65,63,14);
# Call of the original function works fine
loglin(mytable,list(c(1,2),c(1,3)))
# line by line does not work
table = mytable; margin = list(c(1,2),c(1,3)); start = rep(1,
length(table)); fit = FALSE; eps = 0.1;
iter = 20L; param = FALSE; print = TRUE;
rfit <- fit
dtab <- dim(table)
nvar <- length(dtab)
ncon <- length(margin)
conf <- matrix(0L, nrow = nvar, ncol = ncon)
nmar <- 0
varnames <- names(dimnames(table))
for (k in seq_along(margin)) {
tmp <- margin[[k]]
if (is.character(tmp)) {
## Rewrite margin names to numbers
tmp <- match(tmp, varnames)
margin[[k]] <- tmp
}
conf[seq_along(tmp), k] <- tmp
nmar <- nmar + prod(dtab[tmp])
}
ntab <- length(table)
if (length(start) != ntab ) stop("'start' and 'table' must be same length")
z <- .Call(C_LogLin, dtab, conf, table, start, nmar, eps, iter)
...
--
Kai Nitschke, Dipl.-Psych.
Division of Functional Brain Imaging (FBI)
Dept. of Neurology, University of Freiburg
Breisacher Str. 64, 79095 Freiburg, Germany
Phone: +49 (0) 761 270 - 50410
Email: kai.nitsc...@uniklinik-freiburg.de
URL: http://www.uniklinik-freiburg.de/fbi/people/kai-nitschke.html
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Gabriel Becker, PhD
Associate Scientist (Bioinformatics)
Genentech Research
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
