> -----Original Message-----
> From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
> Sent: Wednesday, November 04, 2009 12:19 PM
> To: Duncan Murdoch
> Cc: William Dunlap; r-de...@stat.math.ethz.ch
> Subject: Re: [Rd] error in install.packages() (PR#14042)
>
> I agree it is a good idea, but a new name seems justified to avoid
> confusion.
If you could decide on a good name for the new argument
and the format of the data in it I could implement it in
S+ and keep R & S+ compatible. The format issue seems
bigger to me. Giving a prototype of the expected return
value is very flexible but wastes a bit of space. I propose
treating it much as the value of FUN(X[[1]]) is treated.
If the prototype included names then those could become the row
names of the matrix output, instead of the names on the
actual return values. (I would ignore the row names
when asking if the expected return value sufficiently resembled
the actual one.) E.g., the current
> sapply(split(log(1:10), rep(letters[1:2],c(3,7))), quantile,
(1:2)/3)
a b
33.33333% 0.4620981 1.791759
66.66667% 0.8283022 2.079442
with THE.NEW.ARGUMENT=c(T1=0,T2=0) would return
a b
T1 0.4620981 1.791759
T2 0.8283022 2.079442
(I don't know if that behavior is needed, but it is a correlary
of using THE.NEW.ARGUMENT instead of FUN(X[[1]]) as the source
of row names and perhaps other data.)
Should THE.NEW.ARGUMENT's mode have to match exactly the mode
of FUN(X[[i]]) or should it just be possible to coerce the value
of FUN(X[[i]]) to it?
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
>
> On Wed, 4 Nov 2009, Duncan Murdoch wrote:
>
> > On 11/4/2009 12:15 PM, William Dunlap wrote:
> >>> -----Original Message-----
> >>> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org]
> >>> On Behalf Of Duncan Murdoch
> >>> Sent: Wednesday, November 04, 2009 8:47 AM
> >>> To: michael.m.spie...@gmail.com
> >>> Cc: r-b...@r-project.org; r-de...@stat.math.ethz.ch
> >>> Subject: Re: [Rd] error in install.packages() (PR#14042)
> >>>
> >>> On 11/4/2009 11:05 AM, michael.m.spie...@gmail.com wrote:
> >>> > Full_Name: Michael Spiegel
> >>> > Version: 2.10
> >>> > OS: Windows Vista
> >>> > Submission from: (NULL) (76.104.24.156)
> >>> > > > The following error is produced when attempting to call
> >>> install.packages. Here
> >>> > is the results of the traceback:
> >>> > >> source('http://openmx.psyc.virginia.edu/getOpenMx.R')
> >>> > Error in f(res) : invalid subscript type 'list'
> >>> >> traceback()
> >>> > 7: f(res)
> >>> > 6: available.packages(contriburl = contriburl, method = method)
> >>> > 5: .install.winbinary(pkgs = pkgs, lib = lib,
> contriburl = contriburl, >
> >>> method = method, available = available, destdir = destdir, >
> >>> dependencies = dependencies, ...)
> >>> > 4: install.packages(pkgs = c("OpenMx"), repos = repos)
> >>> > 3: eval.with.vis(expr, envir, enclos)
> >>> > 2: eval.with.vis(ei, envir)
> >>> > 1: source("http://openmx.psyc.virginia.edu/getOpenMx.R";)
> >>> > > I've tracked the error down to somewhere in
> available.packages defined
> >>> in
> >>> > src\library\utils\R\packages.R. I am guessing that the
> error in version
> >>> 2.10
> >>> > has something to do with the change:
> "available.packages() gains a
> >>> 'filters'
> >>> > argument for specifying the filtering operations
> performed on the
> >>> packages found
> >>> > in the repositories."
> >>>
> >>> I've found the error, and will fix and commit to R-devel
> and R-patched.
> >>>
> >>> For future reference: the problem was that it assigned
> the result of
> >>> sapply() to a subset of a vector. Normally sapply()
> simplifies its result
> >>> to a vector, but in this case the result was empty, so
> sapply() returned
> >>> an empty list; assigning a list to a vector coerced the
> vector to a list,
> >>> and then the "invalid subscript type 'list'" came soon after.
> >>
> >> I've run into this sort of problem a lot (0-long input to sapply
> >> causes it to return list()). A related problem is that
> when sapply's
> >> FUN doesn't always return the type of value you expect for some
> >> corner case then sapply won't do the expected simplication. If
> >> sapply had an argument that gave the expected form of FUN's output
> >> then sapply could (a) die if some call to FUN didn't
> return something
> >> of that form and (b) return a 0-long object of the correct form
> >> if sapply's X has length zero so FUN is never called. E.g.,
> >> sapply(2:0, function(i)(11:20)[i],
> FUN.VALUE=integer(1)) # die on
> >> third iteration
> >> sapply(integer(0), function(i)i>0,
> FUN.VALUE=logical(1)) # return
> >> logical(0)
> >>
> >> Another benefit of sapply knowing the type of FUN's return value is
> >> that it wouldn't have to waste space creating a list of
> FUN's return
> >> values but could stuff them directly into the final output
> structure.
> >> A list of n scalar doubles is 4.5 times bigger than
> double(n) and the
> >> factor is 9.0 for integers and logicals.
> >
> > That sounds like a good idea. It would be a bit of work,
> because the current
> > sapply depends on lapply while this would need its own internal
> > implementation: but it would probably be worthwhile.
> >
> > Duncan Murdoch
> >
> > ______________________________________________
> > 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, UK Fax: +44 1865 272595
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
