On Thu, Jan 29, 2015 at 5:51 AM, Martin Maechler < maech...@lynne.stat.math.ethz.ch> wrote:
> >>>>> Michael Lawrence <lawrence.mich...@gene.com> > >>>>> on Tue, 27 Jan 2015 07:59:59 -0800 writes: > > > Since the contract of ls() is to sort, there is nothing wrong with > > programmers depending on it. And there are many functions that could > be > > made 60X faster, but is it worth it? But I did notice that > > as.list.environment has a sorted=FALSE argument already, so I guess > > identical(names(x), names(as.list(x))) could be made to be TRUE, > assuming > > the order is at least persistent, if undefined, so that is a nice > property. > > I guess I'm OK it with. > > As we ended only hearing "pro"s and no real "con"s, > I've committed (a corrected version of) the code now. > > The above identity is not true in generality though, but > > identical(names(x), names(as.list(x, all.names=TRUE))) > > is now for an environment 'x'. > > One could think to change the default of 'all.names' in > as.list.environment(.) from FALSE to TRUE, > but that may break code in subtle places and I don't think we > should go there. > > Yea, but it is super weird that as.list() filters elements out of the environment during coercion. I think I'm going to look through the uses of ls() inside of the core packages, because I suspect that is usually not necessary to extract the keys, and there is a cleaner (and probably faster) way to achieve the same result. > Martin > > > > On Tue, Jan 27, 2015 at 7:44 AM, Peter Haverty < > haverty.pe...@gene.com> > > wrote: > > >> I think that the "sorted" and "all.names" arguments are really only > >> appropriate for pretty printing to the screen. I think it is a bit > >> unfortunate that environments have a names accessor that is 60X > slower > >> than all the other types. This is likely due to the history of > >> environments, which were originally just for behind-the-scenes > tasks. > >> > >> Now that users can use environments as hashes, we really need > >> something like a "keys" function. We don't want programmers > depending > >> on the sorted-ness, as Martin mentioned. Also, I think it helps > users > >> when objects share as many of the key API functions as possible. > >> "names" is natural. "ls" was certainly confusing for me when I > >> started. Having to supply two additional arguments to get the > desired > >> output doesn't help there. Think of all the perl programmers > >> struggling to switch to R. Let's help them out. > >> Pete > >> > >> ____________________ > >> Peter M. Haverty, Ph.D. > >> Genentech, Inc. > >> phave...@gene.com > >> > >> > >> On Tue, Jan 27, 2015 at 7:26 AM, Michael Lawrence > >> <lawrence.mich...@gene.com> wrote: > >> > I think ls(, sort=FALSE) would be more explicit and thus clearer. > There > >> is > >> > much precedent for having arguments that request less work to be > done > >> e.g. > >> > unlist(use.names=FALSE). Yes, the extra typing is a bit painful, > but > >> there > >> > is no intuitive reason why names() would be unsorted, while ls() > would be > >> > sorted. While it is tempting to use an existing function for > this, the > >> word > >> > "names" is somewhat loaded. For example, one might expect > >> > identical(names(env), names(as.list(env))) to be TRUE. I see no > problem > >> with > >> > making names() a simple alias of ls(), as long as the behavior is > the > >> same. > >> > Maybe a different name would be less "loaded" and imply lack of > order, > >> > something like keySet(). But do we really need this? > >> > > >> > > >> > > >> > > >> > > >> > > >> > On Tue, Jan 27, 2015 at 7:11 AM, Martin Maechler > >> > <maech...@lynne.stat.math.ethz.ch> wrote: > >> >> > >> >> >>>>> Peter Haverty <haverty.pe...@gene.com> > >> >> >>>>> on Sun, 25 Jan 2015 12:21:04 -0800 writes: > >> >> > >> >> > Hi all, > >> >> > The "ls" function wears two hats. It allows users to > inspect an > >> >> > environment interactively and also serves deeper in code > as the > >> >> > accessor for an environment's names/keys. I propose that we > >> separate > >> >> > these two conflicting goals, keeping ls for interactive > use and > >> >> adding > >> >> > names for a quick listing of the hash keys. This involves > adding > >> two > >> >> > lines to do_names in attrib.c. > >> >> > >> >> > The 'ls' function and its 'objects' synonym appear very > frequently > >> >> in > >> >> > performance-critical code like base/R/namespace.R and > throughout > >> the > >> >> > methods package. These functions are currently among the > major > >> >> > contributors to execution time in package loading. > >> >> > >> >> > This two-line addition to attrib.c gives a significant > speedup for > >> >> > listing an environment's names/keys (2-60X depending on the > >> 'sorted' > >> >> > argument). It also simplifies the environment API by > making it > >> more > >> >> > like the other basic types. We already have $ and [[ after > all. > >> >> > >> >> > Rather than sprinkling sorted=FALSE throughout the methods > and > >> base > >> >> > code, let's use names. > >> >> > >> >> as for list()s and other (generalized) vectors. > >> >> > >> >> This sounds appealing at first, and I have heard/seen others > propose > >> >> it. I see one good reason *not* to allow it (and you mention the > >> >> reason by mentioning 'sorted') : > >> >> > >> >> The contents of an environment are inherently unordered, and > >> >> even if the order stays fixed for a while, no code should rely > >> >> on the ordering of the objects, and for that reason, > >> >> <env>[1] etc do not make sense and are not allowed. > >> >> > >> >> > Would you be open to this change? > >> >> > >> >> I'm undecided currently: > >> >> "-": reason above; > >> >> "+": convenience, compacter R code using it; > >> >> very simple and natural change to src/main/attrib.c > >> >> > >> >> and waiting for other comments, not the least from other members > of R > >> core > >> >> .. > >> >> > >> >> Martin Maechler, ETH Zurich > >> >> > >> >> > >> >> > I have submitted a patch and some timings to the bug > tracker as > >> >> > https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16170 > >> >> > >> >> > Regards, > >> >> > Pete > >> >> > >> >> > ____________________ > >> >> > Peter M. Haverty, Ph.D. > >> >> > Genentech, Inc. > >> >> > phave...@gene.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 > >> > > >> > > >> > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
