[Rd] arr.ind argument to which.min and which.max
Is there a reason that 'which.min' and 'which.max' don't have an 'arr.ind' argument? The context in which I wanted that was a grid search optimization, which seems like it would be reasonably common to me. -- Patrick Burns pbu...@pburns.seanet.com http://www.burns-stat.com (home of 'Some hints for the R beginner' and 'The R Inferno') __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Attributes of 1st argument in ...
I think you have missed the use of ..1 etc: see e.g. cBind() in
package Matrix.
So x <- attr(list(...)[[1L]], "foo") can be x <- attr(..1, "foo")
As for 'extra copying', it all depends on exactly what you are doing,
but compare
foo1 <- function(...) length(..1)
foo2 <- function(...) length(list(...)[[1L]])
tracemem(x <- runif(1000))
[1] "<0x1b27800>"
foo1(x)
[1] 1000
tracemem(x <- runif(1000))
[1] "<0x1b29800>"
foo2(x)
tracemem[0x1b29800 -> 0x10a2200]: foo2
[1] 1000
On Sat, 3 Jul 2010, Daniel Murphy wrote:
Hi Hadley,
My actual goal is to have a cbind method in the mondate package that behaves
just like the base cbind function: class and shape of the result, names,
etc. Perhaps it's due to the fact that 'cbind' uses its own internal
dispatching, but I have not found a way to implement a "true" S3-style cbind
method. (This is probably ancient news to the development team.) An S4 cbind
method will utilize callNextMethod with just setGeneric("cbind"), which has
no 'x' in the formal arguments. With no 'x', there's no "first argument" on
which to dispatch a "mondate" method. I can make the cbind of mondates also
be a mondate with an all-encompassing setMethod("cbind","ANY", etc) method,
but that wrests dispatch control from cbind which makes no sense whatsoever.
So, to make a long story even longer, I settled for a "cbindmondate
function" that utilizes the speed of base::cbind and (with one exception)
gives me the hoped-for "base cbind behavior."
I can send examples of my trial-and-error attempts under separate email if
you're interested.
Best regards,
Dan
On Sat, Jul 3, 2010 at 9:17 AM, Hadley Wickham wrote:
Hi Dan,
Is there a reason you can't change the function to
f <- function(x, ...) {}
?
Hadley
On Fri, Jul 2, 2010 at 4:26 PM, Daniel Murphy
wrote:
R-Devel:
I am trying to get an attribute of the first argument in a call to a
function whose formal arguments consist of dots only and do something,
e.g.,
call 'cbind', based on the attribute
f<- function(...) {get first attribute; maybe or maybe not call 'cbind'}
I thought of (ignoring "deparse.level" for the moment)
f<-function(...) {x <- attr(list(...)[[1L]], "foo"); if (x=="bar")
cbind(...) else x}
but I feared my solution might do some extra copying, with a performance
penalty if the dotted objects in the actual call to "f' are very large.
I thought the following alternative might avoid a potential performance
hit
by evaluating the attribute in the parent.frame (and therefore avoid
extra
copying?):
f<-function(...)
{
L<-match.call(expand.dots=FALSE)[[2L]]
x <- eval(substitute(attr(x,"foo"), list(x=L[[1L]])))
if (x=="bar") cbind(...) else x
}
system.time tests showed this second form to be only marginally faster.
Is my fear about extra copying unwarranted? If not, is there a better way
to
get the "foo" attribute of the first argument other than my two
alternatives?
Thanks,
Dan Murphy
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Attributes of 1st argument in ...
Thank you, Professor, for drawing my attention to the nifty tracemem
function. I'm using the ..1 syntax to check the properties of the S4 class
at function call.
The Description at ?"cBind" tells me that I'm not alone in this predicament.
Just as Matrix needs its own cBind function, my package will need its own
cbindMondate function. Alas, subclasses of mondate will also need their own
binding functions, thus defeating one of the purposes of the class paradigm
(for binding, anyway).
As an aside, I wonder why, on around line 75, cBind uses 'rep.int("",
ncol(r))' rather than the slightly faster 'character(ncol(r))'.
Thanks again,
Dan
On Sun, Jul 4, 2010 at 4:36 AM, Prof Brian Ripley wrote:
> I think you have missed the use of ..1 etc: see e.g. cBind() in package
> Matrix.
>
> So x <- attr(list(...)[[1L]], "foo") can be x <- attr(..1, "foo")
>
> As for 'extra copying', it all depends on exactly what you are doing, but
> compare
>
> foo1 <- function(...) length(..1)
>> foo2 <- function(...) length(list(...)[[1L]])
>> tracemem(x <- runif(1000))
>>
> [1] "<0x1b27800>"
>
>> foo1(x)
>>
> [1] 1000
>
>> tracemem(x <- runif(1000))
>>
> [1] "<0x1b29800>"
>
>> foo2(x)
>>
> tracemem[0x1b29800 -> 0x10a2200]: foo2
> [1] 1000
>
>
>
>
> --
> Brian D. Ripley, rip...@stats.ox.ac.uk
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Call for suggestions
Greetings, If this is not the appropriate place to post this question please let me know where to post it. I have a package under development which fits models of the form $$ f(t)=\sum_i B_iG_i(t,\omega) $$ depending on a parameter vector $\omega$ of arbitrary dimension to data (one dimensional time series) in the general framework of the data = deterministic signal + Gaussian noise in the spirit of Bretthorst, G. Larry, 1988, "Bayesian Spectrum Analysis and Parameter Estimation," Lecture Notes in Statistics, vol. 48, Springer-Verlag, New York. The basic parametric model $$ G_i(t,\omega)=cos(\omega_i t), sin(\omega_i t) $$ corresponds to classical spectral analysis, however the model can (at least in principle) be completely general. The problem is that the models cannot be defined by the user but have to be hard coded (in C++ since the computations are substantial). I plan to include the ability to modify each model by the action of further parameters as: time changes: t -> t+omega, t -> omega*t, t -> t^omega model function change: G(t) -> sign(G(t))*|G(t)|^omega I plan to include models that can be generated by these actions from trig functions, some piecewise linear functions, monomials, and exponential function. My question is: what further parametric models are of sufficiently general interest to be included? Many thanks, Michael Meyer [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Possible bug in 2.11.x texmf makefile.in and some related things...
Hi all,
A list of some possible issues:
1. In R 2.11.x, in:
http://svn.r-project.org/R/branches/R-2-11-branch/share/texmf/
there are two files, jss.cls and jss.bst (for JSS), which appear to be new
since 2.10.x. These files are not installed when building/installing R. It
would appear that they are not included in:
https://svn.r-project.org/R/branches/R-2-11-branch/share/Makefile.in
The relevant code there is:
@for f in $(srcdir)/texmf/*.sty \
$(srcdir)/texmf/*.fd; do \
$(INSTALL_DATA) $${f} "$(DESTDIR)$(rsharedir)/texmf"; \
done
which would skip over the two jss files.
This issue came up when another useR (on F12) was building the zoo package with
its vignette, which apparently uses jss.cls. Errors were of course observed. I
thought that the error was limited to Fedora, but this is an issue in the
source.
2. On a related issue, the texmf tree appears to be modified in 2.12.x, with
the latex and bibtex files being put into separate folders:
https://svn.r-project.org/R/trunk/share/texmf/
The makefile.in:
https://svn.r-project.org/R/trunk/share/Makefile.in
appears to be modified to handle that split:
@for f in $(srcdir)/texmf/bibtex/bst/*; do \
$(INSTALL_DATA) $${f} "$(DESTDIR)$(rsharedir)/texmf/bibtex/bst"; \
done
@for f in $(srcdir)/texmf/tex/latex/*; do \
$(INSTALL_DATA) $${f} "$(DESTDIR)$(rsharedir)/texmf/tex/latex"; \
done
So there was perhaps an oversight of sorts for 2.11.x in handling these two JSS
related files.
3. A final note, which is that the NEWS file appears to be missing from R-Devel
tonight:
https://svn.r-project.org/R/trunk/
I was trying to read it to note any comments relevant to the above.
HTH,
Marc Schwartz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible bug in 2.11.x texmf makefile.in and some related things...
On Sun, 4 Jul 2010, Marc Schwartz wrote:
Hi all,
A list of some possible issues:
1. In R 2.11.x, in:
http://svn.r-project.org/R/branches/R-2-11-branch/share/texmf/
there are two files, jss.cls and jss.bst (for JSS), which appear to
be new since 2.10.x. These files are not installed when
building/installing R. It would appear that they are not included
in:
https://svn.r-project.org/R/branches/R-2-11-branch/share/Makefile.in
The relevant code there is:
@for f in $(srcdir)/texmf/*.sty \
$(srcdir)/texmf/*.fd; do \
$(INSTALL_DATA) $${f} "$(DESTDIR)$(rsharedir)/texmf"; \
done
which would skip over the two jss files.
This issue came up when another useR (on F12) was building the zoo
package with its vignette, which apparently uses jss.cls. Errors
were of course observed. I thought that the error was limited to
Fedora, but this is an issue in the source.
But there are a fair number of packages which need extra LaTeX files
to build their vignettes, and e.g. the CRAN test systems have had to
have these installed for a long time. Certainly zoo has needed them
from before 2.11.0, and many believe that a Open Source package needs
to include copies of such files (see 'Writing R Extensions').
2. On a related issue, the texmf tree appears to be modified in
2.12.x, with the latex and bibtex files being put into separate
folders:
More precisely, it is a TDS-comformant tree now.
https://svn.r-project.org/R/trunk/share/texmf/
The makefile.in:
https://svn.r-project.org/R/trunk/share/Makefile.in
appears to be modified to handle that split:
@for f in $(srcdir)/texmf/bibtex/bst/*; do \
$(INSTALL_DATA) $${f} "$(DESTDIR)$(rsharedir)/texmf/bibtex/bst"; \
done
@for f in $(srcdir)/texmf/tex/latex/*; do \
$(INSTALL_DATA) $${f} "$(DESTDIR)$(rsharedir)/texmf/tex/latex"; \
done
So there was perhaps an oversight of sorts for 2.11.x in handling
these two JSS related files.
That's a different hand. I don't know if the files were intended to
be installed in 2.11.x: they are in R-devel so eventually packages
depending on R >= 2.12.0 will be able to rely on them.
3. A final note, which is that the NEWS file appears to be missing
from R-Devel tonight:
https://svn.r-project.org/R/trunk/
I was trying to read it to note any comments relevant to the above.
Correct. You need to look in
https://svn.r-project.org/R/trunk/doc/NEWS.Rd
which says
\item File \file{NEWS} is now generated at installation with a
slightly different format: it will be in UTF-8 on platforms using
UTF-8, and otherwise in ASCII.
\item \file{NEWS} is no longer in the sources, but generated as
part of the installation. The primary source for changes is now
\file{doc/NEWS.Rd}.
A version of the NEWS file will be in the tarballs.
HTH,
Marc Schwartz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
