Re: [Rd] License status of CRAN packages
On Thu, Apr 23, 2009 at 3:08 PM, Dirk Eddelbuettel e...@debian.org wrote: (Subject: renamed as thread hijacked from the ParallelR thread --Dirk) On 23 April 2009 at 14:44, Gabor Grothendieck wrote: | Aside from R there are the add-on packages. | | A frequency table showing the licenses of the CRAN packages indicates | that the all or almost all packages have some sort of free software license | with GPL licenses being most common. (A few packages have restrictions | to noncommercial use and that may conflict with GPL, not sure.) That is | not to say that there are no other types of packages but any such packages | are not on CRAN. I fear that is not quite the case. There are quite a few packages like that. Not the case? My post included a list of all License fields from the DESCRIPTION file of every CRAN package so the list is definitive. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] License status of CRAN packages
Of the 31 packages listed: [1] BARD BayesDA CoCo ConvCalendar [5] FAiR PTAk RScaLAPACKRcsdp [9] SDDA SGP alphahull ash [13] asypowcaMassClass gpclibmapproj [17] matlabmclustmclust02 mlbench [21] optmatch rankreg realized rngwell19937 [25] rtiff rwt scagnostics sgeostat [29] spatialkernel tlnisexgobi the license fields are AGPL or GPL for 3 and specified in a separate file file LICENSE so about 30 of 1700 2% are question marks. To me that is not inconsistent with all or nearly all being free software licenses but at any rate this quantifies it a bit better. (A couple are not listed below as I got a read error when trying to access its summary from the CRAN site. Its possible those 2 are not actually on CRAN.) BARD AGPL 3.0 (with attribution) BayesDA GPL (ge; 2) CoCo file LICENSE ConvCalendar file LICENCE FAiR file LICENSE PTAk file LICENSE Rcsdp file LICENSE SDDA file LICENSE SGP file LICENSE alphahull file LICENSE ash S original available at statlib asypow file LICENSE caMassClass The caMassClass Software License, Version 1.0 (See COPYING gpclib file LICENSE mapproj Distribution and use for non-commercial purposes only. matlab file LICENSE mclust file LICENSE mclust02 file LICENSE mlbench file LICENSE optmatch file LICENSE rankreg Free for nonprofit use. realized file LICENSE rngwell19937 file LICENSE rtiff file LICENSE rwt file LICENSE scagnostics file LICENSE sgeostat Original ??, extensions GPL version 2 or newer spatialkernel file LICENSE tlnise file LICENSE 2009/4/23 Dirk Eddelbuettel e...@debian.org: On 23 April 2009 at 15:32, Gabor Grothendieck wrote: | On Thu, Apr 23, 2009 at 3:08 PM, Dirk Eddelbuettel e...@debian.org wrote: | | (Subject: renamed as thread hijacked from the ParallelR thread --Dirk) | | On 23 April 2009 at 14:44, Gabor Grothendieck wrote: | | Aside from R there are the add-on packages. | | | | A frequency table showing the licenses of the CRAN packages indicates | | that the all or almost all packages have some sort of free software license | | with GPL licenses being most common. (A few packages have restrictions | | to noncommercial use and that may conflict
Re: [Rd] License status of CRAN packages
In some other software systems there are separate repositories for free and non-free add-ons. That way its clear what you are downloading yet there are good outlets for both types of software. There has been some discussion of future features that CRAN might have that might make this even easier to do. My opinion is that R will suffer if it were not to support both types of software but at the same time its reasonable to make it clear which type you are getting before you download it. On Thu, Apr 23, 2009 at 4:35 PM, Marc Schwartz marc_schwa...@me.com wrote: On Apr 23, 2009, at 3:02 PM, Dirk Eddelbuettel wrote: On 23 April 2009 at 15:32, Gabor Grothendieck wrote: | On Thu, Apr 23, 2009 at 3:08 PM, Dirk Eddelbuettel e...@debian.org wrote: | | (Subject: renamed as thread hijacked from the ParallelR thread --Dirk) | | On 23 April 2009 at 14:44, Gabor Grothendieck wrote: | | Aside from R there are the add-on packages. | | | | A frequency table showing the licenses of the CRAN packages indicates | | that the all or almost all packages have some sort of free software license | | with GPL licenses being most common. (A few packages have restrictions | | to noncommercial use and that may conflict with GPL, not sure.) That is | | not to say that there are no other types of packages but any such packages | | are not on CRAN. | | I fear that is not quite the case. There are quite a few packages like that. | | Not the case? My post included a list of all License fields from the | DESCRIPTION file of every CRAN package so the list is definitive. Correct me if I am wrong in the paragraph you kindly left standing above, you seem to suggest that all or almost all packages have some sort of free software license and that while non-free licenses may exist, any such packages are not on CRAN. I believe this statement to be false. There are packages with restrictive licenese on CRAN. They were contained in the list of licenses you assembled, and my point is that it is overly hard to identify them (if one were to tty to avoid using these packages). As a non-exhautive list with possible misclassifications, cran2deb currently has these packasges as 'maybe not free' and does not build them: BARD,BayesDA,CoCo,ConvCalendar,FAiR,PTAk,RScaLAPACK,Rcsdp,SDDA,SGP, alphahull,ash,asypow,caMassClass,gpclib,mapproj,matlab,mclust,mclust02, mlbench,optmatch,rankreg,realized,rngwell19937,rtiff,rwt,scagnostics, sgeostat,spatialkernel,tlnise,xgobi We are missing some recently added packages, and we may yet flag several from the list above as free. Some may be listed because of non-free Depends: But to take a concrete example, 'realized' is not something I am supposed to install at work. Yet install.packages() currently has not way knowing that. Are we approximately on the same page ? Dirk There is a list of acceptable entries that are defined as part of the specs in R-exts (see page 4). Perhaps this needs to be tightened a bit, at least in so far as packages passing R CMD check for the purpose of inclusion on CRAN. That would include perhaps altering the ability to use the 'file LICENSE' option, which at present leaves the door wide open for non-standard approaches. It may also have to check for DEPENDS and whether they too are on CRAN and passed the appropriate license checks. Packages that fail this check should not be included on CRAN and the package author would then be obligated to find other distribution resources or contact the CRAN maintainers to advocate that their licensing schema should be acceptable. Then the end user can at least have some comfort in knowing that anything they get from CRAN comes under a compatible license for general use without restriction. They would have to intentionally use other sources for packages that fail the CRAN requirements. If other distribution venues, such as Debian/Ubuntu/Fedora elect to tighten those restrictions even further when making .debs or RPMs available, then that is a decision that they get to make and end users will need to be aware of those as well. Albeit I don't envision the aforementioned Linux distros including packages that should be a problem for most end users relative to usage restrictions given their own license review processes. HTH, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] License status of CRAN packages
On Thu, Apr 23, 2009 at 4:59 PM, Ben Goodrich goodr...@fas.harvard.edu wrote: Dirk Eddelbuettel edd at debian.org writes: As a non-exhautive list with possible misclassifications, cran2deb currently has these packasges as 'maybe not free' and does not build them: BARD,BayesDA,CoCo,ConvCalendar,FAiR,PTAk,RScaLAPACK,Rcsdp,SDDA,SGP, alphahull,ash,asypow,caMassClass,gpclib,mapproj,matlab,mclust,mclust02, mlbench,optmatch,rankreg,realized,rngwell19937,rtiff,rwt,scagnostics, sgeostat,spatialkernel,tlnise,xgobi Small point: FAiR is free. The file LICENSE thing just clarifies that most of the code is AGPL but a couple files can't be included under the AGPL and are plain GPL. As far as I can see, R does not give me the option of saying so in a standard way, e.g. putting License: AGPL (= 3) in the DESCRIPTION file would only be 95% accurate and putting License: AGPL (= 3) | GPL (= 3) is misleading. How about License: AGPL except for 2 GPL files __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Closed-source non-free ParallelR ?
On Thu, Apr 23, 2009 at 8:54 PM, Ted Harding ted.hard...@manchester.ac.uk wrote: On 23-Apr-09 22:21:45, Ian Fellows wrote: Assuming that the foundation does not want to deviate from the FSF interpretation, there would still be value in clarifying its position vis-à-vis how the license applies to R specifically. I think (see below) that I agree with this! For example the FSF foundation claims that linking to a library (even in an interpreted environment) makes your software derivative, and therefore must be distributed Freely. They also claim that simply executing a program in an interpreted (GPL'ed) environment is okay even though the program could not be run without it. So one question might be, where does the language end and the libraries begin? As far as I Understand these things (and I think I use language differently from lawyers), it seems to me that this view about executing a program in an interpreted environment is reasonable. For example, suppose I bought a commercial FORTRAN interpreter. I write a program (plain text, of course) in standard FORTRAN. Running this on the interpreter surely would not tie me into any licensing issues arising from the rights of the seller of the interpreter, and I feel sure I could re-distribute my raw (test) FORTRAN code as I pleased without any infringement arising from the fact that I had, myself, executed it on the interpreter. Others (and I myself) could surely compile the program on some other compiler, etc. However, if that commercial interpreter also had a 'compile' option, and I compiled my progrtam using that, then equally I feel sure that the compiled version would be subject to whatever restrictions had been placed on distirbution fo binaries so compiled. I think those things are clear enough. Typically commercial compilers have royalty-free runtime libraries so you can freely distribute software processed with the compiler. Similarly, In the free software world, gcc has the gcc Runtime Library Exception to allow commercial software to use gcc. http://www.gnu.org/licenses/gcc-exception.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Automatic Differentiation for R
Not sure if this is sufficient for your needs but R does include symbolic differentiation, see ?D, and the Ryacas and rSymPy packages interface R to the yacas and sympy computer algebra systems (CAS) and those system include symbolic differentiation. http://ryacas.googlecode.com http://rsympy.googlecode.com Note that Ryacas communicates with yacas via XML but recent versions of the XML package changed in a way that breaks Ryacas so you will likely have to use an old version of XML and Ryacas if you want to try that one -- see home page. The rsympy interface is early stage but its functional and is easier to install since it includes the entire CAS right in the R package. On Wed, Apr 15, 2009 at 9:30 AM, John C Nash nas...@uottawa.ca wrote: In efforts to improve optimization tools for R, one of my interests has been getting automatic differentiation capabilities so that analytic rather than numerical derivatives can be used. They would be helpful in several other areas besides optimization, My timings show factors of the order of 1000s in time improvements by avoiding numerical derivatives in some cases. There has been some work in this e.g., http://code.google.com/p/pbs-software/ is an R interface to ADMB (Automatic Differentiation Model Builder). However, as far as I can see, this is directed essentially to nonlinear least squares modelling, an important but not general problem. Tom Coleman of Waterloo responded favourably with some advice, but the most enthusiastic answer came from Shaun Forth, which I have included below. I read this as an opportunity to develop what could be a profitable collaboration with the AD community. Unfortunately, I cannot take up the invitation to join the AD folk in Oxford due to a pre-existing obligation. Nor am I more than a complete novice with S3 and S4 classes etc. I am, nevertheless, willing to help organize the effort e.g., do some of the communications, chasing grant money, getting Google Summer of Code applications filled in etc. Can the R community come up with a few people who can provide the AD workers with appropriate information? If so, is there a reasonable chance to generate sufficient funding for a student? I suspect the answer in both cases is yes, but that we need some form of booster cables to get things going. (In Canada, booster cables are used to get cars started in winter by connecting a running vehicle's battery to that of a dead one.) I suggest communications off-list until there is progress to report. Possibly there is a better forum for this -- suggestions welcome. John Nash included msg from Shaun Forth --- Hi John, My computational statistics colleague Trevor Ringrose has asked me to consider AD in R in the past. As you may or may not be aware AD is implemented in one of two ways: overloading using OO features of the target language, or source transformation using compiler tools (after several man years of development) to read in the target code and spit out the differentiated code. Last time I looked I didn't think the object oriented features of R were up to overloading but on checking today I can see that this might now be possible (I can see overloading of arithmetic operators and functions for example now which I didn't see last time). I'd certainly be interested in following this up particularly on the overloading side but would need to get funding for a PhD student to do the graft. It would be particularly interesting doing this in an open source language because we could then perhaps tweak some of the core language features if they didn't seamlessly support the AD (we can't do this in Matlab and that is a pain!). My immediate suggestion is that you, or some other more local (to UK) R expert talks at the next European AD workshop in Oxford http://www.autodiff.org/?module=Workshopssubmenu=EuroAD/8/main We're a very friendly group and I'm sure there are others who might like to tackle R or perhaps we could put together a multigroup project. If someone could give a talk on R, its language features including the OO aspects, and some optimisation examples with associated code, the group there would be able to give you the best feedback on the planet on the possibilities. Please do treat this as a positive response and let's keep in touch on this. Regards Shaun Dr Shaun Forth Applied Mathematics Scientific Computation Cranfield Defence and Security Cranfield University, Shrivenham Campus Swindon SN6 8LA, England tel: +44 (0)1793 785311 fax: +44 (0)1793 784196 email: s.a.fo...@cranfield.ac.uk http://www.amorg.co.uk # __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __
[Rd] suggestion: default v.names in reshape
For reshape(dir = long, varying = list(...), ...) it would be convenient if the names of the varying list, if supplied, were used as the default v.names. Currently they are ignored. Thus one would be able to write: # test data frame d - structure(list(V.1 = 1:10, V.2 = c(1L, 1L, 1L, 1L, 1L, 2L, 2L, 2L, 2L, 2L), V.3 = 101:110, V.4 = 201:210, V.5 = 301:310, V.6 = 9101:9110, V.7 = 9201:9210, V.8 = 9301:9310), row.names = c(NA, -10L ), class = data.frame, .Names = c(V.1, V.2, V.3, V.4, V.5, V.6, V.7, V.8)) # proposed reshape(d, dir = long, varying = list(A = 3:5, B = 6:8)) # as opposed to # current reshape(d, dir = long, varying = list(3:5, 6:8), v.names = c(A, B)) which eliminates the need for one argument and makes it more obvious what the correspondence is between the v.names and the varying variables. The old way could still work too so it would be backward compatible. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: optional svn-revision number tag in package DESCRIPTION file
We need to make sure we understand the implications
for packages developed under the other major version
control systems like git, bzr and hg.
On Tue, Mar 31, 2009 at 10:41 AM, Peter Ruckdeschel
peter.ruckdesc...@web.de wrote:
Hi,
just a little wish :
Could we have one (or maybe more) standardized optional tag(s)
for package DESCRIPTION files to cover svn revision info?
This would be very useful for bug reporting...
I know that any developer is already free to append corresponding lines
to DESCRIPTION files to do something of this sort --- e.g. lines like
LastChangedDate: {$LastChangedDate: 2009-03-31 $}
LastChangedRevision: {$LastChangedRevision: 447 $}
and correspondingly setting the svn keyword properties LastChangedDate
and LastChangedRevision would clearly do (even without Makefile /
configure ...)
But as package development under svn (especially under r-forge)
is just so frequent, it would be nice to have a recommended
format that could be read out in a standardized form, say
by a function like packageDescription from package 'utils':-)
I would vote for optional extra tags LastChangedDate
and LastChangedRevision.
I have attached a commented and correspondingly
modified version of packageDescription() --- if you find it
helpful feel free to integrate it to package 'utils'.
Best,
Peter
# File src/library/utils/R/indices.R
# Part of the R package, http://www.R-project.org
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# A copy of the GNU General Public License is available at
# http://www.r-project.org/Licenses/
packageDescription - function(pkg, lib.loc=NULL, fields=NULL, drop=TRUE,
encoding = )
{
retval - list()
if(!is.null(fields)){
fields - as.character(fields)
retval[fields] - NA
}
pkgpath -
## If the NULL default for lib.loc is used, the loaded packages are
## searched before the libraries.
if(is.null(lib.loc)) {
if(pkg == base)
pkgpath - file.path(.Library, base)
else if((envname - paste(package:, pkg, sep = ))
%in% search()) {
pkgpath - attr(as.environment(envname), path)
## could be NULL if a perverse user has been naming environmnents
## to look like packages.
if(is.null(pkgpath)) pkgpath -
}
}
if(pkgpath == ) {
libs - if(is.null(lib.loc)) .libPaths() else lib.loc
for(lib in libs)
if(file.access(file.path(lib, pkg), 5) == 0L) {
pkgpath - file.path(lib, pkg)
break
}
}
if(pkgpath == ) {
## This is slow and does a lot of checking we do here,
## but is needed for versioned installs
pkgpath - system.file(package = pkg, lib.loc = lib.loc)
if(pkgpath == ) {
warning(gettextf(no package '%s' was found, pkg), domain = NA)
return(NA)
}
}
## New in 2.7.0: look for installed metadata first.
if(file.exists(file - file.path(pkgpath, Meta, package.rds))) {
desc - .readRDS(file)$DESCRIPTION
if(length(desc) 1)
stop(gettextf(metadata of package '%s' is corrupt, pkg),
domain = NA)
desc - as.list(desc)
} else if(file.exists(file - file.path(pkgpath,DESCRIPTION))) {
dcf - read.dcf(file=file)
if(NROW(dcf) 1L)
stop(gettextf(DESCRIPTION file of package '%s' is corrupt, pkg),
domain = NA)
desc - as.list(dcf[1,])
} else file -
if(file != ) {
## read the Encoding field if any
enc - desc[[Encoding]]
if(!is.null(enc) !is.na(encoding)) {
## Determine encoding and re-encode if necessary and possible.
if((encoding != || Sys.getlocale(LC_CTYPE) != C)
capabilities(iconv)) {
## might have an invalid encoding ...
newdesc - try(lapply(desc, iconv, from=enc, to=encoding))
if(!inherits(newdesc, try-error)) desc - newdesc
else
warning('DESCRIPTION' file has 'Encoding' field and
re-encoding is not possible, call. = FALSE)
} else
warning('DESCRIPTION' file has 'Encoding' field and
re-encoding is not possible, call. = FALSE)
}
## Peter Ruckdeschel: 31-03-09: set ok even if fields is NULL
ok - NULL
if(length(names(desc)))
ok - 1:length(names(desc))
Re: [Rd] what is the preferred method to create a package local variable?
Look at the zzz.R file in the lattice package and the .LatticeEnv
variable in particular.
Also, when running lattice try this and look for .LatticeEnv in the output:
ls(asNamespace(lattice), all = TRUE)
On Tue, Mar 31, 2009 at 11:45 AM, Whit Armstrong
armstrong.w...@gmail.com wrote:
for the moment, I'm using:
.onAttach - function(libname, pkgname) {
.bbg.db.conn - dbConnect(dbDriver(PostgreSQL), user=blah,blah)
}
.onUnload - function(libpath) {
dbDisconnect(.bbg.db.conn)
}
which results in a hidden global variable in the global environment.
I would prefer to make the assignment only in the package namespace.
I've looked at assignInNamespace, but I can't seem to make it work.
Is there a preferred method for doing this?
When I try adding an assignment directly in the source file, I get the
cannot change value of locked binding error.
What am I missing?
Thanks,
Whit
__
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] Is aggregate() function changing?
On Tue, Mar 24, 2009 at 7:07 AM, Duncan Murdoch murd...@stats.uwo.ca wrote: On 24/03/2009 12:44 AM, Kenneth Roy Cabrera Torres wrote: Hi R developers and debian users: Finally I found how to work with aggregate() function on the last patched version fo R. I you use this command it fails: aggregate(state.x77, list(Region = state.region), mean) But if you modify it in this way, it works!: aggregate(state.x77, list(Region = state.region), function(x) mean(x) ) Is it necesary to change the example? What is changing in aggregate() function? I get identical results from those, but if I had a local variable (not a function) named mean, the first one would not work: mean - 2 aggregate(state.x77, list(Region = state.region), mean) Error in FUN(X[[1L]], ...) : element 1 is empty; the part of the args list of 'is.list' being evaluated was: (INDEX) I suspect that is what is going wrong for you. although mean in quotes works even then: mean - 1 aggregate(state.x77, list(Region = state.region), mean) Region Population Income Illiteracy Life ExpMurder HS Grad 1 Northeast 5495.111 4570.222 1.00 71.26444 4.72 53.96667 2 South 4208.125 4011.938 1.737500 69.70625 10.581250 44.34375 3 North Central 4803.000 4611.083 0.70 71.76667 5.275000 54.51667 4 West 2915.308 4702.615 1.023077 71.23462 7.215385 62.0 Frost Area 1 132.7778 18141.00 2 64.6250 54605.12 3 138.8333 62652.00 4 102.1538 134463.00 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] matplot and lend=butt
It looks to be a bug. Here is the code and notice that ... is passed to
plot (which plots the first series) but not to lines (which plots the rest):
if (!add) {
ii - ii[-1]
plot(x[, 1], y[, 1], type = type[1], xlab = xlab, ylab = ylab,
xlim = xlim, ylim = ylim, lty = lty[1], lwd = lwd[1],
pch = pch[1], col = col[1], cex = cex[1], bg = bg[1],
...)
}
for (i in ii) {
lines(x[, i], y[, i], type = type[i], lty = lty[i], lwd = lwd[i],
pch = pch[i], col = col[i], cex = cex[i], bg = bg[i])
}
This is from 2.8.1 patched but I noticed the same thing in
R version 2.9.0 Under development (unstable) (2009-03-02 r48041)
On Mon, Mar 23, 2009 at 6:25 PM, Christophe Genolini
cgeno...@u-paris10.fr wrote:
Hi the list,
I am using matplot with the option lend=butt, but only the first line (the
black) is printed correctly :
matplot(matrix(1:9,3),type=c,lwd=10,lty=1,lend=butt)
Is it a bug ?
I am using R2.8.1 under windows XP pack3.
Christophe
__
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] Summer of Code, LLVM, parallelization and R
In addition to the work Luke is doing there is Ra: http://www.milbo.users.sonic.net/ra On Sun, Mar 15, 2009 at 11:25 AM, Florian Gross florian.s.gr...@web.de wrote: Hi everybody, I'm currently working towards my Master's degree as a student of Computer Science at the University of Saarbrücken and highly interested in compiler construction, interpretation techniques, optimization, programming languages and more. :) Two professors of my university approached me about an interesting project just a few days ago: Developing a LLVM-based JIT compilation back-end for R. The primary goal would be the generation of parallel / vectorized code, but other ways of increasing performance might be very interesting as well. I've thought a bit about this and am now wondering if this would make sense as a project for Google's Summer of Code program -- I have seen that the R foundation was accepted as a mentoring organization in 2008 and has applied to be one again in this year. I've already taken part in the SoC program thrice (working on Novell's JScript.NET compiler and run-time environment in 2005, writing a debugger for the Ruby programming language in 2006 and working on a detailed specification for the Ruby programming language in 2007) and it has always been a lot of fun and a great experience. One thing that was particularly helpful was getting into contact with the development communities so easily. What do you folks think? Would this be of benefit to the R community? Would it be a good candidate for this year's SoC installment? :) Also, if some thinking in this direction has already been done or if you have any other pointers, please don't hesitate to reply! Thanks a lot in advance! Kind regards, Florian Gross __ 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] question
Why? Can you demonstrate any situations where its useful? Despite
having my own facility for this I've found that over the years I
have never used it.
On Sat, Mar 7, 2009 at 9:23 AM, ivo...@gmail.com wrote:
Gentlemen---these are all very clever workarounds, but please forgive me for
voicing my own opinion: IMHO, returning multiple values in a statistical
language should really be part of the language itself. there should be a
standard syntax of some sort, whatever it may be, that everyone should be
able to use and which easily transfers from one local computer to another.
It should not rely on clever hacks in the .Rprofile that are different from
user to user, and which leave a reader of end user R code baffled at first
by all the magic that is going on. Even the R tutorials for beginners should
show a multiple-value return example right at the point where function calls
and return values are first explained.
I really do not understand why the earlier implementation of multiple-value
returns was deprecated. then again, I am a naive end user, not a computer
language expert. I probably would not even understand the nuances of syntax
ambiguities that may have arisen. (this is my shortcoming.)
regards,
/iaw
On Mar 7, 2009 4:34am, Wacek Kusnierczyk
waclaw.marcin.kusnierc...@idi.ntnu.no wrote:
mark.braving...@csiro.au wrote:
The syntax for returning multiple arguments does not strike me as
particularly appealing. would it not possible to allow syntax like:
f= function() { return( rnorm(10), rnorm(20) ) }
(a,d$b) = f()
FWIW, my own solution is to define a multi-assign operator:
'%
# a must be of the form '{thing1;thing2;...}'
a
e
stopifnot( length( b) == length( a))
for( i in seq_along( a))
eval( call( '
NULL
}
you might want to have the check less stringent, so that rhs may consist
of more values that the lhs has variables. or even skip the check and
assign NULL to a[i] for i length(b). another idea is to allow %
be used with just one variable on the lhs.
here's a modified version:
'%
a
if (length(a) 1)
a
if (length(a) length(b))
b
e
for( i in seq_along( a))
eval( call( '
NULL }
{a; b} %
# a = 1; b = 2
a %
# a = 3
{a; b} %
# a = 5; b = NULL
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
On Sat, Mar 7, 2009 at 9:38 AM, ivo welch ivo...@gmail.com wrote:
hi gabor: this would be difficult to do. I don't think you want to
read my programs. it would give you an appreciation of what ugly
horror programs end users can write in the beautiful R language ;-).
clearly, one can work around the lack of such a feature.
multiple-return values are syntax sugar. but maybe it helps to
explain how I got to my own view. I had to send an R program to
someone who had never used it before. without knowing R, he could
literally read the entire program. the only thing that stumped him
was the multiple return values. In my program, he saw
f= function() { return(list(a=myvector1, b=myvector2)) }
result=f()
a= result$a
b= result$a
rm(result)
I had picked this method up over the years reading r-help. of course,
I had 10 return values, not two, each return value with its own long
name. I think it would have been a whole lot nicer if I could have
written FOR HIM simply
f= function() { return(myvector1,myvector2); }
(a,b)= f()
The function would be better written
f - function() list(a = myvector1, b = myvector2)
and then called:
L - f()
again, its syntax sugar. I would find such syntax a whole lot more
appealing. and I often write functions that pass back a main program,
but also some debug or other information. maybe I am the only one...
regards,
/iaw
On Sat, Mar 7, 2009 at 9:28 AM, Gabor Grothendieck
ggrothendi...@gmail.com wrote:
Why? Can you demonstrate any situations where its useful? Despite
having my own facility for this I've found that over the years I
have never used it.
On Sat, Mar 7, 2009 at 9:23 AM, ivo...@gmail.com wrote:
Gentlemen---these are all very clever workarounds, but please forgive me for
voicing my own opinion: IMHO, returning multiple values in a statistical
language should really be part of the language itself. there should be a
standard syntax of some sort, whatever it may be, that everyone should be
able to use and which easily transfers from one local computer to another.
It should not rely on clever hacks in the .Rprofile that are different from
user to user, and which leave a reader of end user R code baffled at first
by all the magic that is going on. Even the R tutorials for beginners should
show a multiple-value return example right at the point where function calls
and return values are first explained.
I really do not understand why the earlier implementation of multiple-value
returns was deprecated. then again, I am a naive end user, not a computer
language expert. I probably would not even understand the nuances of syntax
ambiguities that may have arisen. (this is my shortcoming.)
regards,
/iaw
On Mar 7, 2009 4:34am, Wacek Kusnierczyk
waclaw.marcin.kusnierc...@idi.ntnu.no wrote:
mark.braving...@csiro.au wrote:
The syntax for returning multiple arguments does not strike me as
particularly appealing. would it not possible to allow syntax like:
f= function() { return( rnorm(10), rnorm(20) ) }
(a,d$b) = f()
FWIW, my own solution is to define a multi-assign operator:
'%
# a must be of the form '{thing1;thing2;...}'
a
e
stopifnot( length( b) == length( a))
for( i in seq_along( a))
eval( call( '
NULL
}
you might want to have the check less stringent, so that rhs may consist
of more values that the lhs has variables. or even skip the check and
assign NULL to a[i] for i length(b). another idea is to allow %
be used with just one variable on the lhs.
here's a modified version:
'%
a
if (length(a) 1)
a
if (length(a) length(b))
b
e
for( i in seq_along( a))
eval( call( '
NULL }
{a; b} %
# a = 1; b = 2
a %
# a = 3
{a; b} %
# a = 5; b = NULL
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
On Sat, Mar 7, 2009 at 10:26 AM, Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: ivo...@gmail.com wrote: Gentlemen---these are all very clever workarounds, hacks around the lack of a feature but please forgive me for voicing my own opinion: IMHO, returning multiple values in a statistical language should really be part of the language itself. returning multiple values is supported by many programming languages, in particular scripting languages. while in r you can use the %-% hack or have functions return lists of values, it could indeed be useful to have such a feature in a statistical language like r. there should be a standard syntax of some sort, if you mean that r should have such a syntax, you're likely to learn more about saying 'should' soon. whatever it may be, that everyone should be able to use and which easily transfers from one local computer to another. It should not rely on clever hacks in the .Rprofile that are different from user to user, and which leave a reader of end user R code baffled at first by all the magic that is going on. Even the R tutorials for beginners should show a multiple-value return example right at the point where function calls and return values are first explained. as gabor says in another post, you probably should first show why having multiple value returns would be useful in r. however, i don't think there are good counterarguments anyway, and putting on you the burden of proving a relatively obvious (or not so?) thing is a weak escape. to call for a reference, sec. 9.2.3, p. 450+ in [1] provides some discussion and examples. The fact that other languages is an argument for further consideration but not a definitive argument for it. I have had this feature for years via my workaround yet I never use it which seems a good argument against it. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
On Sat, Mar 7, 2009 at 11:37 AM, Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no wrote: Gabor Grothendieck wrote: as gabor says in another post, you probably should first show why having multiple value returns would be useful in r. however, i don't think there are good counterarguments anyway, and putting on you the burden of proving a relatively obvious (or not so?) thing is a weak escape. to call for a reference, sec. 9.2.3, p. 450+ in [1] provides some discussion and examples. The fact that other languages is an argument for further consideration but not a definitive argument for it. of course! I have had this feature for years via my workaround yet I never use it which seems a good argument against it. the fact that another programmer is an argument for further consideration but not a definitive argument against it. I've provided an argument against it and no one has provided one for it. The so-called identical code Ivo showed was not identical and, in fact, was flawed. Your first/last example could be written: f - function() letters L - structure(f()[1:2], names = c(first, last)) or one could define a function to do that without having to modify the language. Given the relative infrequency of this it hardly seems to merit a language feature. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
I posted this a few years ago (but found I never really had a
need for it):
http://tolstoy.newcastle.edu.au/R/help/04/06/1430.html
On Thu, Mar 5, 2009 at 9:22 AM, ivo welch ivo...@gmail.com wrote:
dear R developers: it is of course easy for a third party to make
suggestions if this third party is both clueless and does not put in
any work. with these caveats, let me suggest something.
The syntax for returning multiple arguments does not strike me as
particularly appealing. would it not possible to allow syntax like:
f= function() { return( rnorm(10), rnorm(20) ) }
(a,d$b) = f()
this would just hide the list conversion and unconversion. yes, I
know how to accomplish this with lists, but it does not seem pretty or
natural.
regards,
/ivo
__
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] Two documentation questions
Perhaps you could just place the output in comments.
print(5) # 5
head(BOD, 2)
# Time demand
# 118.3
# 22 10.3
On Wed, Mar 4, 2009 at 8:38 PM, Terry Therneau thern...@mayo.edu wrote:
1. I often like to put bits of the output into the manual pages. (We can
have a discussion of the value of this elsewhere -- I think it is sometimes
a good thing.)
In R I need to surround these with \dontrun{} for the sake of the tester,
which is fine. But the printed output contains
## Not run
and
## End (not run)
comments, which defeats the purpose of the lines by breaking them off from
the their context. How do I turn these off? For printing \dontrun should
be a no-op. Or at least I should have the option of making it so -- I'm
rather
opinionated about the format of things I prepare for teaching purposes.
You can assume medium Tex skills in answering; my book is in Latex but I
don't create my own formats.
2. In the pdf for the survival package, or at least the one generated by R CMD
check, the entries are in a random order. Can I fix this? It makes reading
the document to look for errors rather challenging. (That is, when I'm
looking at a particular Rd file, and want to see what it turned out to be.)
Terry Therneau
__
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] vignette compilation times
Thanks for the inventive workaround. On Fri, Feb 20, 2009 at 1:37 PM, Berwin A Turlach ber...@maths.uwa.edu.au wrote: G'day Gabor, On Thu, 19 Feb 2009 17:47:53 -0500 Gabor Grothendieck ggrothendi...@gmail.com wrote: [...] Unless this has changed recently,I've tried including a PDF but it does not appear in library(help = myPackage) nor on the CRAN site on http://cran.r-project.org/package=myPackage while Sweave'd PDFs do. If you want a PDF file to appear in library(help=myPackage), then you can write a vignette that just includes that PDF file via \includepdf from the LaTeX package(?) pdfpages. You will, of course, end up with two PDF files that are practically identical. So you might want to exclude the original PDF file from the build package via .Rbuildignore. If you do so, the next problem is that since R 2.6.0 R CMD check is trying to latex the vignette and not just checks the code in the vignette. And in current TeX systems latex will hang if \includepdf does not find the specified PDF file; latex does not stop with an error, it hangs. So the vignette has to be written smart enough to try to include the PDF file via \includepdf only if the file really exists, but that can easily be done. See the package lasso2 for an example. If you follow this set up, your PDF file will show up in library(help=myPackage) and your package will pass R CMD check on CRAN. HTH. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette compilation times
On Thu, Feb 19, 2009 at 5:36 PM, Friedrich Leisch friedrich.lei...@stat.uni-muenchen.de wrote: On Thu, 19 Feb 2009 11:47:12 +, Robin Hankin (RH) wrote: thanks for this clarification Uwe Could I include the r_env_cache/ directory in the package and then assume that the CRAN checks use Sweave( , driver=weaver()) in which case the process takes about 10 seconds? That makes no sense, because then there are no checks done at all: if the code in your vignette does not change, weaver will not recompute anything, hence the cached results are used. But in that case you could as well include only the PDF (or the generated .tex if you like that better) ... Unless this has changed recently,I've tried including a PDF but it does not appear in library(help = myPackage) nor on the CRAN site on http://cran.r-project.org/package=myPackage while Sweave'd PDFs do. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] getGraphicsEvent in an example
Also any demos in the demo directory will be skipped by
the automated checks.
On Tue, Feb 17, 2009 at 12:01 PM, Greg Snow greg.s...@imail.org wrote:
Just wrap the example in either \dontrun{} or
if(interactive()){
}
That way that example will be skipped when the automatic tests are done, but
will still be available for a reader to run by copy/paste or the examples
function (2nd case above).
This has worked for me, examples using these are playSudoku in the sudoku
package and dynIdentify in TeachingDemos.
Hope this helps,
--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
project.org] On Behalf Of Christophe Genolini
Sent: Tuesday, February 17, 2009 5:07 AM
To: r-devel@r-project.org
Subject: [Rd] getGraphicsEvent in an example
Hi the list,
Is there a way to include a function using a getGraphicsEvent in the
\examples section?
Christophe
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning for dropped text with devices that don't support clipping (in text attachments)
On Sat, Jan 24, 2009 at 9:45 PM, Sebastian Fischmeister sfisc...@uwaterloo.ca wrote: Apparently, the mail program doesn't like attachments. Here's the patch and the script again. The attachment does appear to have made to the archives: https://stat.ethz.ch/pipermail/r-devel/2009-January/051917.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 2009 Wish list for R
2009 Wish list for R (no particular order): - some way of placing backslashes in literal strings without escaping them. Useful for latex, regular expressions and Windows file paths. This seems to come up from time to time on the lists. Ruby, python, Perl and other scripting languages have various ways to handle this which might be used as a model. - in Windows, some way to tell Packages | Install menu to use dependencies = TRUE (vs. dependencies = NA now). NB. utils:::menuInstallPkgs is the R routine invoked - self-contained R executables - default origin in Date. as.numeric.Date and as.Date.numeric are asymmetric in this respect. - here documents in sourced input - read.table(textConnection(Lines)) later gives annoying warning message about closing connection. If too hard to fix add an asText= arg, e.g. read.table(Lines, asText=TRUE) - View() buttons to copy to clipboard. (print and save might also be nice.) - allow library() command to determine what is imported like python's import ... from ... - Lag function(x, k, ...) lag(x, -k, ...) lag is regarded by many as confusing and this would give a second option while keeping lag for compatability. - generic filter() - add executable for filefind.cc in docs.miktex.org to R bin directory on Windows to give an easy way to locate MiKTeX. Alternately put it in Rtools. - real subclassing of environments - ability to conditionally emit portions of a Sweave document even if they represent both text and code portions without using crude workarounds. For example if all the data for a certain figure is missing that figure and the associated paragraphs describing it and the R code shown associated with it could all be suppressed dynamically. - pfg TeX driver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Documentation suggestions for vignettes
On Wed, Jan 14, 2009 at 2:53 PM, Perry de Valpine pdevalp...@berkeley.edu wrote: Dear R-devel, I am putting together a package vignette for the first time (R 2.8.1, OS X) and had some bumps from section 1.4 (Writing package vignettes) of the Writing R Extensions document. Here are suggestions to clean up a few small documentation bugs (I think) and omissions. This is assuming that R is performing as intended and the only gaps are in the documentation, not vice-versa. The statement Pointers from package help indices to the installed documents are automatically created made me think I could put a pdf in inst/doc and it would automatically be treated as a vignette. When I did R CMD BUILD and R CMD INSTALL, an index.html was created in inst/doc (and my pdf was copied there) but it stated there are no vignettes for this package, and R indeed could not find the vignette. How about stating that index.html is needed and sticking in an example? I eventually figured it out by looking at the grid package source. Could you please clarify this comment. I could not find an index.html file in the grid package source (R revision 47606 synced today): C:\\R\src\library\griddir/s index.html File Not Found __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Documentation suggestions for vignettes
The source tree is at: https://svn.r-project.org/R/trunk and the src/library/grid subdirectory holds grid. To check out a copy using svn see the svn checkout ... command described here: http://developer.r-project.org/ On Thu, Jan 15, 2009 at 12:24 PM, Perry de Valpine pdevalp...@berkeley.edu wrote: I am looking at the 2.8.1 source code in R-2.8.1/src/library/grid/inst/doc, where there is an index.html (I am not at daily syncing level and hope that is not an issue in this case). In this case the Snw files contain the %\VignetteIndexEntry and associated commands, so the index.html could have been generated by the package build (I see the pdfs, so I assume they were generated from the Snws by building the package. Should be I able to access a pre-build package source? That is not what is in R-2.8.1.tar.gz but may be what you have?). To clarify: if I attempt to include a vignette by putting a pdf directly in inst/doc, then R CMD BUILD does copy the pdf to the built package but generates an index.html that says there are no vignettes, so R is blind to the vignette. After seeing a correctly built index.html, I made a leap to think that if I include/modify the index.html to treat the pdf as a vignette, that might make R see it. However, I did not test this, and instead moved on to the Rnw method with %\VignetteIndexEntry. For the direct pdf method, I don't know if R CMD BUILD is intended to generate an index.html that recognizes any pdfs present (i.e. the documentation is fine), or alternatively if the documentation should state more completely how to include a pdf directly as a vignette. The latter was the premise of my earlier post. Please let me know if that is confused or still not specific enough. Thanks. Perry On Jan 15, 2009, at 7:10 AM, Gabor Grothendieck wrote: On Wed, Jan 14, 2009 at 2:53 PM, Perry de Valpine pdevalp...@berkeley.edu wrote: Dear R-devel, I am putting together a package vignette for the first time (R 2.8.1, OS X) and had some bumps from section 1.4 (Writing package vignettes) of the Writing R Extensions document. Here are suggestions to clean up a few small documentation bugs (I think) and omissions. This is assuming that R is performing as intended and the only gaps are in the documentation, not vice-versa. The statement Pointers from package help indices to the installed documents are automatically created made me think I could put a pdf in inst/doc and it would automatically be treated as a vignette. When I did R CMD BUILD and R CMD INSTALL, an index.html was created in inst/doc (and my pdf was copied there) but it stated there are no vignettes for this package, and R indeed could not find the vignette. How about stating that index.html is needed and sticking in an example? I eventually figured it out by looking at the grid package source. Could you please clarify this comment. I could not find an index.html file in the grid package source (R revision 47606 synced today): C:\\R\src\library\griddir/s index.html File Not Found __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Documentation suggestions for vignettes
I find this very confusing too. I would also sometimes like to include pdf's that were not generated from Sweave and have them included in the package and listed in library(help = mypackage) output as well as with clickable links on the package's CRAN web page like vignettes are. On Thu, Jan 15, 2009 at 1:27 PM, Simon Urbanek simon.urba...@r-project.org wrote: On Jan 15, 2009, at 12:24 , Perry de Valpine wrote: I am looking at the 2.8.1 source code in R-2.8.1/src/library/grid/ inst/doc, where there is an index.html (I am not at daily syncing level and hope that is not an issue in this case). In this case the Snw files contain the %\VignetteIndexEntry and associated commands, so the index.html could have been generated by the package build (I see the pdfs, so I assume they were generated from the Snws by building the package. Should be I able to access a pre-build package source? That is not what is in R-2.8.1.tar.gz but may be what you have?). To clarify: if I attempt to include a vignette by putting a pdf directly in inst/doc, then R CMD BUILD does copy the pdf to the built package but generates an index.html that says there are no vignettes, so R is blind to the vignette. That statement is wrong in the first place. R doesn't care about index.html when looking for package vignettes - it's generated for the HTML help system only (from vignettes, really). Please read 1.4 Writing package vignettes in R-exts manual. Vignettes are only documents created with Sweave. Although you can add arbitrary documents to your package, those are not considered vignettes. If you have custom documents in inst/doc, you have to supply your own index.html (unless the default look in . makes you happy), because R creates an index file only for vignettes. To address your original post: Pointers from package help indices to the installed documents are automatically created has nothing to do with vignettes (note that it's talking about documents, not vignettes). However, AFAICT it's no longer true (at least 00Index.dcf seems to be ignored), so that may need some clarification. Cheers, Simon After seeing a correctly built index.html, I made a leap to think that if I include/modify the index.html to treat the pdf as a vignette, that might make R see it. However, I did not test this, and instead moved on to the Rnw method with %\VignetteIndexEntry. For the direct pdf method, I don't know if R CMD BUILD is intended to generate an index.html that recognizes any pdfs present (i.e. the documentation is fine), or alternatively if the documentation should state more completely how to include a pdf directly as a vignette. The latter was the premise of my earlier post. Please let me know if that is confused or still not specific enough. Thanks. Perry On Jan 15, 2009, at 7:10 AM, Gabor Grothendieck wrote: On Wed, Jan 14, 2009 at 2:53 PM, Perry de Valpine pdevalp...@berkeley.edu wrote: Dear R-devel, I am putting together a package vignette for the first time (R 2.8.1, OS X) and had some bumps from section 1.4 (Writing package vignettes) of the Writing R Extensions document. Here are suggestions to clean up a few small documentation bugs (I think) and omissions. This is assuming that R is performing as intended and the only gaps are in the documentation, not vice-versa. The statement Pointers from package help indices to the installed documents are automatically created made me think I could put a pdf in inst/doc and it would automatically be treated as a vignette. When I did R CMD BUILD and R CMD INSTALL, an index.html was created in inst/doc (and my pdf was copied there) but it stated there are no vignettes for this package, and R indeed could not find the vignette. How about stating that index.html is needed and sticking in an example? I eventually figured it out by looking at the grid package source. Could you please clarify this comment. I could not find an index.html file in the grid package source (R revision 47606 synced today): C:\\R\src\library\griddir/s index.html File Not Found [[alternative HTML version deleted]] __ 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] irrelevant warning message
On Tue, Jan 13, 2009 at 8:28 AM, Terry Therneau thern...@mayo.edu wrote: Thanks for the replies: Duncan: and got a warning in all R versions I tried back to 2.4.1. In 2.3.1 this was an error. It seems I have egg on my face wrt this point. A more true synopsis of what I saw should have been that 1. I've never noticed this in R before and 2. Until recently I did all my modeling in Splus or Bell S, and character vectors always worked there. (My survival routines were always more up to date in Splus because that's what I use for the source code. But conversion from a local cvs archive to Rforge is nearly done -- just a survexp.us ratetable issue remains -- so R will become my most current version in another day or two.) Possibly I don't have any character variables as covariates in the survival test suite. Hadley: I think R's handling of character vectors has progressed to the point where they should be the norm, not the exception. Maybe others will have different views. Factors are very useful when there is a small discrete number of levels, and I use them moderately often. For that case, most of the default behavior of factors makes perfect sense, e.g., retention of levels. I'm very sure that adding stringsAsFactors to the system options was a good thing, not as sure that defaulting it to FALSE is the best thing for all users. In my world most of the data comes from formal processes: clinical trials, data bases, large studies that use dedicated keyed entry, etc. The most common character variables are things like id, name, and address for which the factor paradym doesn't work, and most of the variables I get that are actually 'factors' come to me as small integers; I turn them into factors using both the levels and labels arguments. Thus autoconversion is just a PITA. But my world is not everyone's. My main complaint with factors has always been the assumption that everything should be turned into one. I fought that battle with Splus. Defaults behavior See the stringsAsFactors option in ?options to change the global default. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R as a scripting engine
On Sun, Jan 11, 2009 at 3:18 PM, Prof Brian Ripley rip...@stats.ox.ac.uk wrote: Those of you tracking R development will have noticed that we are moving towards using R as a scripting engine. (It is often overlooked as such.) ... In due course we see phasing out the use of Perl, at least at run time (and that might even be for 2.9.0). That's great news. I for one will not be sorry to see it and the shell scripts go. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Acessing pdf help files (PR#13419)
From the Windows (not R) command line try this (the input you type is after the and the output is on the next line). Modify the ftype line appropriately if the output of assoc is different for you. C:\tmp2assoc .pdf .pdf=AcroExch.Document C:\tmp2ftype AcroExch.Document AcroExch.Document=C:\Program Files\Adobe\Reader 8.0\Reader\AcroRd32.exe %1 On Wed, Dec 24, 2008 at 8:50 PM, marcthiba...@tanda.on.ca wrote: Full_Name: Marc Thibault Version: 2.8.1 OS: Windows XP Pro SP2 Submission from: (NULL) (216.104.125.106) I had Adobe Acrobat 5 and Adobe Reader 9 installed. The .pdf open association is to Reader. When I selected Help | Manuals(in pdf) | An Introduction to R, it brought up the file in Acrobat instead of Reader. After making sure the default associations were correctly pointing to Reader, I took the extreme step of uninstalling Acrobat. Now when I try the same thing, R responds with Error: access to 'doc\manual\R-intro.pdf' denied. Outside of R, double clicking the file brings it up in Reader as it should. Asking for HTML help works fine, so access to doc\ hasn't really been lost. It seems that R picks up a reference to the pdf reader at installation time, doesn't do it right, and refuses to let go. On the other hand, reinstalling R didn't fix the problem. __ 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
[Rd] read.table with fill = TRUE
There seems to be a problem with read.table when fill = TRUE in this case. In the example below, note that: - there should be 4 columns, not 3 - some rows like row 6 are cut off at the end - others like row 7 seem completely wrong Lines - x 1 b + x 1 a + x 2 b + x 2 a + x 2 + y 1 a 1 + y 10 a 2 + y 10 a 10 + y 10 a 1 + y 2 + var 10 a 2 + var 2 + y 10 read.table(textConnection(Lines), fill = TRUE) V1 V2 V3 1x 1 b 2x 1 a 3x 2 b 4x 2 a 5x 2 6y 1 a 71 NA 8y 10 a 92 NA 10 y 10 a 11 10 NA 12 y 10 a 13 1 NA 14 y 2 15 var 10 a 16 2 NA 17 var 2 18 y 10 R.version.string [1] R version 2.8.1 RC (2008-12-17 r47235) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package development
Perhaps it would be sufficient as a first step to just display the version that will be downloaded. That would still only let you pick one but at least you would know which one. On Mon, Dec 15, 2008 at 11:43 AM, Duncan Murdoch murd...@stats.uwo.ca wrote: On 12/15/2008 10:58 AM, Kevin R. Coombes wrote: I knew that (but forgot to include it in my statement of the question). Thanks for pointing it out. Is there any way to convince the selection box (or its developers) to include the version information that is already available? The selection box is adamant that it will only display one thing. The developers would like to have a grid display component, and then would be happy to display more information about each package, but are unlikely to write one, due to competing priorities. If you wanted to contribute one... Duncan Murdoch Kevin Duncan Murdoch wrote: On 12/15/2008 10:31 AM, Kevin R. Coombes wrote: Hi, Terry Therneau's question about package development reminded me of a different issue. I maintain several packages along with a repository for them at http://bioinformatics.mdanderson.org/OOMPA/;. Several people are working on adding features or testing the packages. So, I often want to have both the latest official release and the currently testable build of the package available in the repository. I tried putting both versions in the same repository, but this leads to a problem for some of the testers, who are not familiar with the intricacies of building packages. (Thus, I cannot just tell them to get the source tarball and compile it; they will have no clue as to what I am talking about. And their Windows machines will not have the required tools installed in any event.) The underlying problem is that when you run the command install.packages(repos=http://bioinformatics.mdanderson.org/OOMPA;) inside the R Windows GUI, the selection box that appears only lists the name of the package, _not_ the version number. Thus, the testers cannot tell which of two packages with the same name should be installed. Is there any way around this problem other than to maintain two different repositories? available.packages() reports version numbers, e.g. available.packages(contrib.url(http://bioinformatics.mdanderson.org/OOMPA;)) You'll need to write a user interface to make use of this. 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] install.packages and dependency version checking
On Mon, Dec 15, 2008 at 12:35 PM, Prof Brian Ripley rip...@stats.ox.ac.uk wrote: (D) We can really only handle = dependencies on package versions (but then I can see no other ops in use). install.packages() will find the latest Ryacas works with XML 1.96-0; however, after Ryacas was released newer versions of XML break Ryacas so a new release of Ryacas would, at the moment, need XML (= 1.96-0). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gregexpr - match overlap mishandled (PR#13391)
On Fri, Dec 12, 2008 at 4:35 PM, greg.s...@imail.org wrote: do extra to specify otherwise. One of the standard references for regular = expressions if you really want to understand what is going on is Mastering= Regular Expressions by Jeffrey Friedl. You should really read through th= There are also regular expression links in the Links box of the gsubfn home page: http://gsubfn.googlecode.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in R CMD INSTALL on Windows XP using Rtools28
On Sat, Dec 6, 2008 at 8:08 AM, Duncan Murdoch [EMAIL PROTECTED] wrote: cstrato wrote: Prof Brian Ripley wrote: On Fri, 5 Dec 2008, cstrato wrote: Dear Duncan Thank you for this explicit explanation, you are right: When setting the system variable Path (as administrator) in addition to setting the user variable PATH (as user), now everything works fine. Interestingly, setting the system variable Path on my laptop with Rtools27 seems not to be necessary. May I suggest that this could be clarified in R Installation and Administration since there only the user variable PATH is mentioned (as far as I see). In a shell there is only one PATH, so the manual is correct. I did not say that the manual is not correct, I only suggested to clarify the issue, since when running R CMD INSTALL from the Command Console I need to set also the system variable Path. I'd be reluctant to do this, for the same reason Brian was: the documentation is correct. You need to set the PATH environment variable correctly, and that's what we say. The fact that doing this is complicated and confusing on Windows is a problem with the Windows design and documentation, not the R documentation, and Microsoft certainly has more resources than we do to address it. What was their response when you asked them to improve their documentation? Duncan Murdoch The http://batchfiles.googlecode.com home page does give some tips for setting paths just in case. Of course if you are using the batchfiles you won't have to set any paths in the first place. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in R CMD INSTALL on Windows XP using Rtools28
You could leave your path at: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;c:\Programme\Microsoft SQL Server\90\Tools\binn\ and then use Rcmd.bat or rtools.bat to add the rest. Also there are still two problems: 1. one of the dangers of your setup is that Rtools has a conflict with Windows since it has its own find which takes over from Windows' find and can cause Windows batch files not related to R to fail. As a result its not a good idea to permanently set your path to include the rtools but better to do it session by session so that non-R sessions are unaffected. 2. Also you still don't seem to have MiKTeX on your path so I don't think its correct yet. Rcmd.bat or rtools.bat would add the path to MiKTeX too (if you have it in a standard location). On Sat, Dec 6, 2008 at 9:41 AM, cstrato [EMAIL PROTECTED] wrote: Dear Duncan, dear Gabor, Thank you for this additional information and all these great tips. Setting the system path in the following way solved my problem: c:\Rtools\bin;c:\Rtools\perl\bin;c:\Rtools\MinGW\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;c:\Programme\Microsoft SQL Server\90\Tools\binn\ Luckily this solves also the problem with potential conflicts between R tools, Microsoft tools and ROOT, so that I do not have to rename any tools (which I would be reluctant to do). Since at the moment everything seems to work fine, and I am no Windows expert (I do all my development on my Mac), I will keep the current setting, however, the next time I have to set up everything, I will try to take advantage of Rcmd.bat since Gabor mentions that it will not override any of my settings. Regarding the R installation documentation, I understand now that this seems to be a problem of my complicated setup and not a general problem, so adding this information may confuse other people. Best regards Christian Gabor Grothendieck wrote: On Sat, Dec 6, 2008 at 8:08 AM, Duncan Murdoch [EMAIL PROTECTED] wrote: cstrato wrote: Prof Brian Ripley wrote: On Fri, 5 Dec 2008, cstrato wrote: Dear Duncan Thank you for this explicit explanation, you are right: When setting the system variable Path (as administrator) in addition to setting the user variable PATH (as user), now everything works fine. Interestingly, setting the system variable Path on my laptop with Rtools27 seems not to be necessary. May I suggest that this could be clarified in R Installation and Administration since there only the user variable PATH is mentioned (as far as I see). In a shell there is only one PATH, so the manual is correct. I did not say that the manual is not correct, I only suggested to clarify the issue, since when running R CMD INSTALL from the Command Console I need to set also the system variable Path. I'd be reluctant to do this, for the same reason Brian was: the documentation is correct. You need to set the PATH environment variable correctly, and that's what we say. The fact that doing this is complicated and confusing on Windows is a problem with the Windows design and documentation, not the R documentation, and Microsoft certainly has more resources than we do to address it. What was their response when you asked them to improve their documentation? Duncan Murdoch The http://batchfiles.googlecode.com home page does give some tips for setting paths just in case. Of course if you are using the batchfiles you won't have to set any paths in the first place. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in R CMD INSTALL on Windows XP using Rtools28
Any Windows batch script that uses the Windows find command. On Sat, Dec 6, 2008 at 1:08 PM, cstrato [EMAIL PROTECTED] wrote: Dear Gabor, Sorry, my mistake, here are my correct path settings: System Path: C:\Rtools\bin;C:\Rtools\perl\bin;C:\Rtools\MinGW\bin;C:\Programme\MiKTeX 2.7\miktex\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem User PATH: C:\Rtools\bin;C:\Rtools\perl\bin;C:\Rtools\MinGW\bin;C:\Programme\HTML Help Workshop;C:\Programme\R\R-2.8.0\bin;C:\root\bin; I have just tested again that: - R CMD check is ok and produces the vignettes - I can compile my C++ source code with VC++ independently of R Thus at the moment there seem to be no conflicts, however, this could be the case in the future. Do you have any examples, where the Rtools find can cause conflicts with Windows? Best regards Christian Gabor Grothendieck wrote: You could leave your path at: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;c:\Programme\Microsoft SQL Server\90\Tools\binn\ and then use Rcmd.bat or rtools.bat to add the rest. Also there are still two problems: 1. one of the dangers of your setup is that Rtools has a conflict with Windows since it has its own find which takes over from Windows' find and can cause Windows batch files not related to R to fail. As a result its not a good idea to permanently set your path to include the rtools but better to do it session by session so that non-R sessions are unaffected. 2. Also you still don't seem to have MiKTeX on your path so I don't think its correct yet. Rcmd.bat or rtools.bat would add the path to MiKTeX too (if you have it in a standard location). On Sat, Dec 6, 2008 at 9:41 AM, cstrato [EMAIL PROTECTED] wrote: Dear Duncan, dear Gabor, Thank you for this additional information and all these great tips. Setting the system path in the following way solved my problem: c:\Rtools\bin;c:\Rtools\perl\bin;c:\Rtools\MinGW\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;c:\Programme\Microsoft SQL Server\90\Tools\binn\ Luckily this solves also the problem with potential conflicts between R tools, Microsoft tools and ROOT, so that I do not have to rename any tools (which I would be reluctant to do). Since at the moment everything seems to work fine, and I am no Windows expert (I do all my development on my Mac), I will keep the current setting, however, the next time I have to set up everything, I will try to take advantage of Rcmd.bat since Gabor mentions that it will not override any of my settings. Regarding the R installation documentation, I understand now that this seems to be a problem of my complicated setup and not a general problem, so adding this information may confuse other people. Best regards Christian Gabor Grothendieck wrote: On Sat, Dec 6, 2008 at 8:08 AM, Duncan Murdoch [EMAIL PROTECTED] wrote: cstrato wrote: Prof Brian Ripley wrote: On Fri, 5 Dec 2008, cstrato wrote: Dear Duncan Thank you for this explicit explanation, you are right: When setting the system variable Path (as administrator) in addition to setting the user variable PATH (as user), now everything works fine. Interestingly, setting the system variable Path on my laptop with Rtools27 seems not to be necessary. May I suggest that this could be clarified in R Installation and Administration since there only the user variable PATH is mentioned (as far as I see). In a shell there is only one PATH, so the manual is correct. I did not say that the manual is not correct, I only suggested to clarify the issue, since when running R CMD INSTALL from the Command Console I need to set also the system variable Path. I'd be reluctant to do this, for the same reason Brian was: the documentation is correct. You need to set the PATH environment variable correctly, and that's what we say. The fact that doing this is complicated and confusing on Windows is a problem with the Windows design and documentation, not the R documentation, and Microsoft certainly has more resources than we do to address it. What was their response when you asked them to improve their documentation? Duncan Murdoch The http://batchfiles.googlecode.com home page does give some tips for setting paths just in case. Of course if you are using the batchfiles you won't have to set any paths in the first place. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in R CMD INSTALL on Windows XP using Rtools28
One difference between rtools27.exe and rtools28.exe is that the latter sets a value in the registry to where rtools is located whereas the former does not. On Fri, Dec 5, 2008 at 2:49 PM, cstrato [EMAIL PROTECTED] wrote: Dear all When trying to install my package on Windows XP on my Mac, I get the following error: -- Making package xps ... ... xpsDict.cxx C:\Programme\Microsoft Visual Studio 9.0\VC\bin/link /dll /def:xps.def /out:xps.dll fp10.obj -opt:noref -nologo -include:_G__cpp_setupG__Hist -include:_G__cpp_setupG__Graf1 -include:_G__cpp_setupG__G3D -include:_G__cpp_setupG__GPad -include:_G__cpp_setupG__Tree -include:_G__cpp_setupG__Rint -include:_G__cpp_setupG__PostScript -include:_G__cpp_setupG__Matrix -include:_G__cpp_setupG__Physics -include:_G__cpp_setupG__Ged C:\root/lib/libCore.lib C:\root/lib/libCint.lib C:\root/lib/libHist.lib C:\root/lib/libGraf.lib C:\root/lib/libGraf3d.lib C:\root/lib/libGpad.lib C:\root/lib/libTree.lib C:\root/lib/libRint.lib C:\root/lib/libPostscript.lib C:\root/lib/libMatrix.lib C:\root/lib/libPhysics.lib C:\root/lib/libNet.lib C:\root/lib/libRIO.lib C:\root/lib/libMathCore.lib C:\root/lib/libGui.lib C:\root/lib/libGraf.lib C:\root/lib/libGpad.lib C:\root/lib/libGed.lib C:\root/lib/libTreePlayer.lib C:\root/lib/libTreeViewer.lib *.obj Creating library xps.lib and object xps.exp ... done installing DLL installing R files installing inst files FIND: Parameterformat falsch make[2]: *** [C:/home/Rabbitus/CRAN/xps.Rcheck/xps/inst] Error 2 make[1]: *** [all] Error 2 make: *** [pkg-xps] Error 2 *** Installation of xps failed *** However, when I install my package on my Windows XP laptop, everything is ok: -- Making package xps ... ... xpsDict.cxx C:\Programme\Microsoft Visual Studio 9.0\VC\bin/link /dll /def:xps.def /out:xps.dll fp10.obj -opt:noref -nologo -include:_G__cpp_setupG__Hist -include:_G__cpp_setupG__Graf1 -include:_G__cpp_setupG__G3D -include:_G__cpp_setupG__GPad -include:_G__cpp_setupG__Tree -include:_G__cpp_setupG__Rint -include:_G__cpp_setupG__PostScript -include:_G__cpp_setupG__Matrix -include:_G__cpp_setupG__Physics -include:_G__cpp_setupG__Ged C:\root/lib/libCore.lib C:\root/lib/libCint.lib C:\root/lib/libHist.lib C:\root/lib/libGraf.lib C:\root/lib/libGraf3d.lib C:\root/lib/libGpad.lib C:\root/lib/libTree.lib C:\root/lib/libRint.lib C:\root/lib/libPostscript.lib C:\root/lib/libMatrix.lib C:\root/lib/libPhysics.lib C:\root/lib/libNet.lib C:\root/lib/libRIO.lib C:\root/lib/libMathCore.lib C:\root/lib/libGui.lib C:\root/lib/libGraf.lib C:\root/lib/libGpad.lib C:\root/lib/libGed.lib C:\root/lib/libTreePlayer.lib C:\root/lib/libTreeViewer.lib *.obj Creating library xps.lib and object xps.exp ... done installing DLL installing R files installing inst files preparing package xps for lazy loading installing man source files installing indices Warning messages: 1: In file.create(f.tg) : kann Datei 'c:/Programme/R/R-2.8.0/doc/html/packages.html' nicht erzeugen. Grund 'Permission denied' 2: In tools:::win.packages.html(.Library) : kann HTML Paketindex nicht aktualisieren installing help Building/Updating help pages for package 'xps' ... To my knowledge I have only made one difference when installing everything necessary to build my package: On my laptop I have installed Rtools27.exe, while on WinXP on my Mac I have installed Rtools28.exe. Do you know what the reason for the error might be? Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ 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] Error in R CMD INSTALL on Windows XP using Rtools28
Note that there is an Rcmd.bat batch file in http://batchfiles.googlecode.com which automatically sets all environment variables for you including the PATH making it unnecessary to set your PATH or any environment variables. On Fri, Dec 5, 2008 at 4:06 PM, cstrato [EMAIL PROTECTED] wrote: Dear Duncan Thank you for this explicit explanation, you are right: When setting the system variable Path (as administrator) in addition to setting the user variable PATH (as user), now everything works fine. Interestingly, setting the system variable Path on my laptop with Rtools27 seems not to be necessary. May I suggest that this could be clarified in R Installation and Administration since there only the user variable PATH is mentioned (as far as I see). Thank you all one more time. Best regards Christian Duncan Murdoch wrote: cstrato wrote: Dear all Thank you all for you fast reply. As I said, everything on my laptop and Mac is identical, here are my user defined environment variables: HOME: c:\home\Rabbitus INCLUDE: C:\Programme\Microsoft Visual Studio 9.0\VC\include;C:\Programme\Microsoft SDKs\Windows\v6.0A\Include LIB: C:\Programme\Microsoft Visual Studio 9.0\VC\lib;C:\Programme\Microsoft SDKs\Windows\v6.0A\Lib;C:\root\lib PATH: C:\Rtools\bin;C:\Rtools\perl\bin;C:\Rtools\MinGW\bin;C:\Programme\HTML Help Workshop;C:\Programme\R\R-2.8.0\bin;C:\root\bin; MSVSPATH: C:\Programme\Microsoft Visual Studio 9.0\VC\bin ROOTSYS: c:\root R_LIBS: cd C:\home\Rabbitus\CRAN TMPDIR: c:\home\Rabbitus\temp I think Brian was right, your PATH is not what is shown above. (That doesn't include the Windows directories, for instance.) Were you running Rcmd INSTALL from a shell? Which shell? What does the shell report as your PATH just before running it? On Windows, the PATH is handled in a fairly complicated way. I believe this description is correct, but it may not apply to all Windows versions: The thing you set from within the Control Panel only applies to the currently running copy of Explorer. Other applications that are currently running (e.g. an existing CMD shell) do not have their path updated. There are both system and user level PATH settings. Explorer combines them by putting the system settings *first*. Within a CMD shell, you can override the PATH completely, just by setting it to a new set of directories. So it looks as though your problem is that your are showing us the user settings for the PATH, but not the system settings, and the system settings are messing you up. Duncan Murdoch I have just checked again, all variables are identical on both systems. Could there be another reason? What about the registry setting mentioned by Gabor Grothendieck? Best regaards Christian Prof Brian Ripley wrote: This is a PATH error: you must have Rtools/bin before Windows system directories in your path. As the R-admin manual tells you explicitly fortune(WTFM) applies. On Fri, 5 Dec 2008, cstrato wrote: Dear all When trying to install my package on Windows XP on my Mac, I get the following error: -- Making package xps ... ... xpsDict.cxx C:\Programme\Microsoft Visual Studio 9.0\VC\bin/link /dll /def:xps.def /out:xps.dll fp10.obj -opt:noref -nologo -include:_G__cpp_setupG__Hist -include:_G__cpp_setupG__Graf1 -include:_G__cpp_setupG__G3D -include:_G__cpp_setupG__GPad -include:_G__cpp_setupG__Tree -include:_G__cpp_setupG__Rint -include:_G__cpp_setupG__PostScript -include:_G__cpp_setupG__Matrix -include:_G__cpp_setupG__Physics -include:_G__cpp_setupG__Ged C:\root/lib/libCore.lib C:\root/lib/libCint.lib C:\root/lib/libHist.lib C:\root/lib/libGraf.lib C:\root/lib/libGraf3d.lib C:\root/lib/libGpad.lib C:\root/lib/libTree.lib C:\root/lib/libRint.lib C:\root/lib/libPostscript.lib C:\root/lib/libMatrix.lib C:\root/lib/libPhysics.lib C:\root/lib/libNet.lib C:\root/lib/libRIO.lib C:\root/lib/libMathCore.lib C:\root/lib/libGui.lib C:\root/lib/libGraf.lib C:\root/lib/libGpad.lib C:\root/lib/libGed.lib C:\root/lib/libTreePlayer.lib C:\root/lib/libTreeViewer.lib *.obj Creating library xps.lib and object xps.exp ... done installing DLL installing R files installing inst files FIND: Parameterformat falsch make[2]: *** [C:/home/Rabbitus/CRAN/xps.Rcheck/xps/inst] Error 2 make[1]: *** [all] Error 2 make: *** [pkg-xps] Error 2 *** Installation of xps failed *** However, when I install my package on my Windows XP laptop, everything is ok: -- Making package xps ... ... xpsDict.cxx C:\Programme\Microsoft Visual Studio 9.0\VC\bin/link /dll /def:xps.def /out:xps.dll fp10.obj -opt:noref -nologo -include:_G__cpp_setupG__Hist -include:_G__cpp_setupG__Graf1 -include:_G__cpp_setupG__G3D -include:_G__cpp_setupG__GPad -include:_G__cpp_setupG__Tree -include:_G__cpp_setupG__Rint -include:_G__cpp_setupG__PostScript -include:_G__cpp_setupG__Matrix -include
Re: [Rd] Error in R CMD INSTALL on Windows XP using Rtools28
On Fri, Dec 5, 2008 at 4:28 PM, cstrato [EMAIL PROTECTED] wrote: Dear Gabor Thank you for this interesting link. Since I have also to set the PATH and LIB for Visual Studio AND for ROOT, I am not sure if this would be an option for me. Rcmd.bat will not override settings you make yourself. It basically defines R_HOME, R_MIKTEX and R_TOOLS environment variables by looking at the registry or using heuristics but in each case it only sets the environment variable if its not already set. Then it uses those to set up an environment for running R. If you do want to set them yourself but don't want to muck with the system Rcmd.bat can look into special files where they can be defined. There is more info on features and limitations on the homepage and README. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] names generated in list indexing
Also note the behavior is the same for a non-list vector:
c(b=1)[c('a','b')]
NAb
NA1
but differs for a data frame:
data.frame(b=1)[c('a','b')]
Error in `[.data.frame`(data.frame(b = 1), c(a, b)) :
undefined columns selected
On Fri, Nov 28, 2008 at 2:03 PM, Vadim Ogranovich
[EMAIL PROTECTED] wrote:
Dear R-devel,
When a character vector is used to subscript a list and when some of the
subscripts are not present in the list names R returns NULL for those
subscripts and generate NA names for each of them:
list(b=1)[c('a','b')]
$NA -- generated name
NULL
$b
[1] 1
Wouldn't it be more intuitive to use the subscript name rather than to
generate an NA? Something like this (not real result):
list(b=1)[c('a','b')]
$a-- more intuitive name
NULL
$b
[1] 1
version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 7.1
year 2008
month 06
day23
svn rev45970
language R
version.string R version 2.7.1 (2008-06-23)
Thanks,
Vadim
Note: This email is for the confidential use of the named addressee(s) only
and may contain proprietary, confidential or privileged information. If you
are not the intended recipient, you are hereby notified that any review,
dissemination or copying of this email is strictly prohibited, and to please
notify the sender immediately and destroy this email and any attachments.
Email transmission cannot be guaranteed to be secure or error-free. Jump
Trading, therefore, does not make any guarantees as to the completeness or
accuracy of this email or any attachments. This email is for informational
purposes only and does not constitute a recommendation, offer, request or
solicitation of any kind to buy, sell, subscribe, redeem or perform any type
of transaction of a financial product.
[[alternative HTML version deleted]]
__
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] cex.lab etc. ignored in plot.ts for multiple plots (PR#13315)
As a workaround you could use plot.zoo: library(zoo) tt - ts(cbind(a = 1:10, b = 1:10)) plot(as.zoo(tt), plot.type=multiple, cex.lab = 0.5, col.lab = red) On Fri, Nov 21, 2008 at 8:50 AM, [EMAIL PROTECTED] wrote: Full_Name: Yan Wong Version: 2.8.0 OS: Mac OS X 10.4 Submission from: (NULL) (78.149.183.231) When plotting multiple time series in a single plot, via plot.ts(plot.type=multiple), the cex.lab, col.lab, and font.lab arguments are ignored plot(ts(data.frame(a=1:10, b=1:10)), plot.type=single, cex.lab=0.5, col.lab=red) #tiny red axis labels plot(ts(data.frame(a=1:10, b=1:10)), plot.type=multiple, cex.lab=0.5, col.lab=red) #should have tiny red axis labels, but does not. I think this a problem with lines 54-57 of plot.ts. In particular, the mtext functions should also be called with 'cex=cex.lab, col=col.lab, font=font.lab', and the argument list of the plotts function should also contain 'cex.lab=par(cex.lab), col.lab=par(col.lab), font.lab=par(font.lab)' __ 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] Computing minimal detectable differences for general ANOVA models
They will be built for you. You only upload the .tar.gz file. See section 1.5 of the Writing Extensions manual. On Sat, Nov 22, 2008 at 5:35 PM, Ali Baharev [EMAIL PROTECTED] wrote: Ooops, sorry. Just one more question. Do i have to make a binary package for Win32 and Mac OS X? Or is it done by some server side scripts? For Win32 it seems to me http://win-builder.r-project.org/ can build it for me. Sorry for the dumb questions. Ali __ 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] R license: GPL v2 or v3?
There is an analysis of the R license here:
http://www.ohloh.net/projects/rproject/analyses/latest
On Tue, Nov 18, 2008 at 5:24 PM, Gabriel Gellner [EMAIL PROTECTED] wrote:
For a project I am porting some of R's source code, and I want to
get the license for my project correct, but the top level COPYING file
for R's source states GPL v2, but when using:
license()
(which also states GPL version 2) points me towards:
RShowDoc('COPYING')
which states GPL v3. Which is correct?
Thanks for clarification (and the amazing amount of code!).
Gabriel
__
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] anyone familiar with this error?
Don't really know but you could see if the info in Avoiding R Bugs
section on the http:/r-proto.googlecode.com page applies, particularly
the first point on Lazy Loading.
On Tue, Nov 18, 2008 at 5:07 PM, Whit Armstrong
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] R.packages]$ sudo R CMD INSTALL portfolio.construction
* Installing to library '/usr/local/lib64/R/library'
* Installing *source* package 'portfolio.construction' ...
** R
** preparing package for lazy loading
Loading required package: fts
Loading required package: quadprog
Loading required package: Rexcelpoi
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct NULL not valid
/usr/local/lib64/R/bin/INSTALL: line 455: 25001 Done
( echo options(warn=1); invisible(.libPaths(c(\${lib}\,
.libPaths(; .getRequiredPackages();
tools:::makeLazyLoading(\${R_PACKAGE_NAME}\, \${lib}\) )
25002 Aborted (core dumped) | R_DEFAULT_PACKAGES=
LC_ALL=C ${R_EXE} --vanilla --slave
ERROR: lazy loading failed for package 'portfolio.construction'
** Removing '/usr/local/lib64/R/library/portfolio.construction'
** Restoring previous '/usr/local/lib64/R/library/portfolio.construction'
[EMAIL PROTECTED] R.packages]$
I've tried a few things, but can't seem to track down the problem.
it's leaving core files in my package directory. (not in the .Rcheck
directory, directly in the package dir)
Thanks,
Whit
__
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] anyone familiar with this error?
There was a slash missing. It should be
http://r-proto.googlecode.com
On Tue, Nov 18, 2008 at 6:31 PM, Gabor Grothendieck
[EMAIL PROTECTED] wrote:
Don't really know but you could see if the info in Avoiding R Bugs
section on the http:/r-proto.googlecode.com page applies, particularly
the first point on Lazy Loading.
On Tue, Nov 18, 2008 at 5:07 PM, Whit Armstrong
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] R.packages]$ sudo R CMD INSTALL portfolio.construction
* Installing to library '/usr/local/lib64/R/library'
* Installing *source* package 'portfolio.construction' ...
** R
** preparing package for lazy loading
Loading required package: fts
Loading required package: quadprog
Loading required package: Rexcelpoi
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct NULL not valid
/usr/local/lib64/R/bin/INSTALL: line 455: 25001 Done
( echo options(warn=1); invisible(.libPaths(c(\${lib}\,
.libPaths(; .getRequiredPackages();
tools:::makeLazyLoading(\${R_PACKAGE_NAME}\, \${lib}\) )
25002 Aborted (core dumped) | R_DEFAULT_PACKAGES=
LC_ALL=C ${R_EXE} --vanilla --slave
ERROR: lazy loading failed for package 'portfolio.construction'
** Removing '/usr/local/lib64/R/library/portfolio.construction'
** Restoring previous '/usr/local/lib64/R/library/portfolio.construction'
[EMAIL PROTECTED] R.packages]$
I've tried a few things, but can't seem to track down the problem.
it's leaving core files in my package directory. (not in the .Rcheck
directory, directly in the package dir)
Thanks,
Whit
__
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] Locating MiKTeX
On Mon, Nov 10, 2008 at 10:13 PM, Spencer Graves [EMAIL PROTECTED] wrote: Thanks. What should I have done to obtain the information you just provided? Google for MiKTeX Manual and look at the R batch utilities and info at: http://batchfiles.googlecode.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Locating MiKTeX
I came across this program to locate MiKTeX file: http://docs.miktex.org/2.7/sdk/findfile_8cpp-example.html If the exe of this were included with R then it seems it might provide a reliable way to locate MiKTeX which we don't currently have since AFAIK there is no adequate registry key for MiKTeX. Since its a tiny program it would not substantially affect the R download. (There is also a perl version of the same program there although it relies on certain perl packages which would also have to be present complicating things.) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Locating MiKTeX
MiKTeX automatically downloads additional required packages that your *.tex files use. Something is wrong with your installation if it did not try to do that automatically for you. Although the following should not be necessary, if you do want to download and install additional MiKTeX packages yourself without a massive download just invoke the MiKTeX package manager by entering at the Windows command line: mpm or, if you don't have MiKTeX on your path you can run rtools.bat mpm where rtools.bat, which is from http://batchfiles.googlecode.com , will temporarily add MiKTeX to your path so that you can run mpm and other MiKTeX tools. On Sun, Nov 9, 2008 at 11:41 AM, Spencer Graves [EMAIL PROTECTED] wrote: Hi, Gabor, et al.: Could you also please ensure 'plflatex wrapper.tex' work with whatever MikTeX installation you include, for 'wrapper.tex' mentioned in the Submissions instructions for R News? This bombed for me when I tried it recently, because I was missing multiple LaTeX packages: When I found one, it asked for another that I couldn't easily find. So I did a maximal install of the latest version of MiKTeX. That involved downloading more that a gigabyte of stuff, then cleaning space on my hard drive so I could actually install it. The whole process took several days, in between my other work. It would help if it were all part of the standard install. Thanks, Spencer Gabor Grothendieck wrote: I came across this program to locate MiKTeX file: http://docs.miktex.org/2.7/sdk/findfile_8cpp-example.html If the exe of this were included with R then it seems it might provide a reliable way to locate MiKTeX which we don't currently have since AFAIK there is no adequate registry key for MiKTeX. Since its a tiny program it would not substantially affect the R download. (There is also a perl version of the same program there although it relies on certain perl packages which would also have to be present complicating things.) __ 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
[Rd] Problem with Axis
If we run the code below we get an error message but if we replace Axis with axis then we get no error message. I don't think Axis' error message is a good idea since one can't know ahead of time whether there is a tick at January or not since R can automatically adjust plot ranges in a complex way. For example, plot(d-13, 1:12) has a tick at Jan even though d-13 starts at jan 2nd. I think Axis should act the same as axis in this case. d - seq(as.Date(2008-1-15), as.Date(2008-12-15), by = month) plot(d, 1:12, xaxt = n) Axis(side = 1, at = d[2:12], labels = substr(month.abb[2:12], 1, 1)) Axis(side = 1, at = as.Date(2008-1-1), labels = '07) Error in axis(side, at = z, labels = labels, ...) : 'at' and 'labels' lengths differ, 0 != 1 # no error axis(side = 1, at = as.Date(2008-1-1), labels = '07) R.version.string # Vista [1] R version 2.8.0 Patched (2008-10-21 r46766) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Wishlist: pass args from demo() to source()
Currently demo calls source with a hard coded max.deparse.length = 250 so you can't really see the demo properly in some cases. Note the [TRUNCATED] below. (1) It would be nice if demo passed max.deparse.length (and other args to source). (2) Also a larger max.deparse.length default would be nice to make it less likely one would have to set it in the first place. R.version.string # Vista [1] R version 2.8.0 Patched (2008-10-21 r46766) demo(gsubfn-si) demo(gsubfn-si) ~ Type Return to start : # given number possibly followed by SI letter (e.g. 32.5k where k means 1000) # replace letter with e followed by appropriate digits. # (see formatEng2R by Hans-Joerg Bibiko in the R Wiki) conv - list(y = e-24, z = e-21, a = e-18, f [TRUNCATED] gsubfn(.$, conv, c(19, 32.5M)) [1] 19 32.5e6 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] conditionally import a namespace?
I noticed there is also an experimental interface that can be used
from R (as opposed to the NAMESPACE file). Can't tell from docs
whether it allows conditionals:
?.Import
On Thu, Oct 30, 2008 at 10:44 AM, Duncan Murdoch [EMAIL PROTECTED] wrote:
On 10/30/2008 10:15 AM, Martin Maechler wrote:
FA == Felix Andrews [EMAIL PROTECTED]
on Thu, 30 Oct 2008 17:40:17 +1100 writes:
FA Dear R-devel,
FA I have a problem defining the dependencies for a package.
FA My package (latticist, not yet released) Suggests RGtk2, but
FA specifically does not require it. If RGtk2 is available, the user
can
FA call a function that builds a GUI with RGtk2. However, I do not
want
FA to attach the RGtk2 namespace, because it is irrelevant to the user
FA and exports about 7500 symbols.
FA Last time I asked a similar question to this, Professor Ripley
noted
FA that the usual method to get around this situation is the use an
FA explicit package prefix to function calls (the `::` operator). But
FA this is not so easy with non-standard functions. Take this chunk of
FA code:
FA widg - gtkComboBoxEntryNewText()
FA widg$show()
FA widg[width-request] - 100
FA The first call is easy to prefix, as
RGtk2::gtkComboBoxEntryNewText()
FA but the others, `$.RGtkObject` and `[-.RGtkObject` are not.
indeed.
FA While I *could* rewrite all the code to use explicit functions, I
FA think, the resulting code would be much less clear.
FA Essentially what I want to do is conditionally import the RGtk2
namespace.
FA Any suggestions?
Maybe something along the line of
if(is.function(try(RGtk2::gtkComboBoxEntryNewText))) {
library(RGtk2)
}
??
I think the problem is that that puts the namespace on the user's search
list, which is what Felix wanted to avoid. He would like to import(RGtk2),
but only if it exists.
There are conditionals allowed in NAMESPACE files, but I don't know if they
are allowed to be used to control imports. They are not well documented --
they were called experimental when introduced in 1.9.0.
If this is allowed, then something like
if( RGtk2 %in% rownames(installed.packages()) ) {
import(RGtk2)
}
should work.
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] Errors in R CMD check for R 2.8.0
You could go to \Users\JoeDoe\Documents\R\win-library and rename 2.8 to 2.8x, say, reinstall R, grab movedir.bat from http://batchfiles.googlecode.com placing it in \Users\JoeDoe\Documents\R\win-library (or anywhere on your path) and then check that it created a \Users\JoeDoe\Documents\R\win-library\2.8 and run this in the Windows console cd \Users\JoeDoe\Documents\R\win-library movedir 2.8x 2.8 Then start R and choose Packages | Update movedir.bat is a small batch file (with no dependencies) that can be used to move your packages from one library to another with the safety feature that it will not overwrite packages that are already in the target library. On Tue, Oct 28, 2008 at 5:07 AM, Uwe Ligges [EMAIL PROTECTED] wrote: dxc13 wrote: When I type library(tcltk) under R 2.8.0 I get the error message: Loading Tcl/Tk interface ...Error in inDL(x, as.logical(local), as.logical(now), ...) : unable to load shared library 'C:/PROGRA~1/R/R-28~1.0/library/tcltk/libs/tcltk.dll': LoadLibrary failure: The specified procedure could not be found. Error : .onLoad failed in 'loadNamespace' for 'tcltk' Error: package/namespace load failed for 'tcltk' I do not get this error when I run R 2.7.0. When I upgraded to R 2.8.0 I just copied my library from 2.7.0 to the library folder of 2.8.0. Is this troublesome? Yes, it is. You may have overwritten your new tcltk installation by an outdated one. You need to do now: 1. Re-intsall R (in the same folder as before is fine) 2. run update.package(checkBuilt=TRUE) Uwe Ligges Uwe Ligges-3 wrote: dxc13 wrote: useR's, I get these 2 errors when I run R CMD check on my package, and I cannot figure out how to get around them. Does anyone have any ideas? If it is of any help, I use Windows XP. ... * checking replacement functions OK * checking foreign function calls ... OK * checking R code for possible problems ... NOTE Error in inDL(x, as.logical(local), as.logical(now), ...): unable to load shared library 'c:/Progra~1/R/R-2.8.0/library/tcltk/libs/tcltk.dll': LoadLibrary failure: The specified procedure could not be found. Do you have tcltk installed at that location? Do you get any message from Windows? What happens if you type library(tcltk)? Error: .onLoad failed in 'loadNamespace' for 'tcltk' * Checking .Rd files ... OK * checking data for non-ASCII characters ... OK * creating kzs-Ex.R ... OK * checking examples ... ERROR Running examples in 'kzs-Ex.R' failed. See the log file (kzs-Ex.Rout). Uwe Ligges I have no idea how to solve the first problem with references the tcltk package and I do not know why my examples won't run. Any help is appreciated. dxc13 __ 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible uninstall problem on windows.
Note that Rversions.hta in http://batchfiles.googlecode.com is a Vista javascript script that will present you with a drop down list based on the R registry entries (and also allow you to change which version is current). Its a single file with no dependencies so just put it in your current directory (or anywhere in your path) and enter its name at the Windows command line to run it (or double click it from Windows Explorer). (There is an XP version in batchfiles 0.3-2.) On Sun, Oct 26, 2008 at 9:50 AM, Erich Neuwirth [EMAIL PROTECTED] wrote: I just uninstalled R 2.7.2 on Windows XP after having installed R 2.8.0 The uninstaller removed the String values HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\Current Version HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\InstallPath despite the fact that they pointed to R 2.8.0 The uninstaller did not remove the key HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\2.7.2 (and all the values in that key) I think the uninstaller should only remove the Current Version entry if it points to its own version. In a second attempt, the 2.7.2 uninstaller removed the key HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\2.7.2 (which is what it should do) but it still removed the HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\Current Version HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\InstallPath values. It should not have removed these keys. Sometimes this does not happen, and I have not found a consistent explanation when it happens and when not. Sometimes also running RSetReg.exe creates a second entry like HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\2.7.2 which has identical content with the first one. The registry really looks like having 2 identical entries. Is this something which I should file as a bug? -- Erich Neuwirth, University of Vienna Faculty of Computer Science Computer Supported Didactics Working Group Visit our SunSITE at http://sunsite.univie.ac.at Phone: +43-1-4277-39464 Fax: +43-1-4277-39459 __ 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] changed behaviour of 'get' in 2.8.0: request for unchange
On Fri, Oct 24, 2008 at 6:53 AM, Luke Tierney [EMAIL PROTECTED] wrote: There is already sone desire to have a way of checking whether a binding contains a delayed evaluation, so maybe something like a function bindingStatus that returns one of active, missing, delayed or evaluated makes sense. The other item that might have a relationship to this is the ability to a copy an object without evaluating it. This can't be done entirely in R but can be done in C code from R: http://tolstoy.newcastle.edu.au/R/e2/devel/07/09/.html For me, copying is even more important than inspecting and that seems to be for Mark's case too. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.8.0 qqnorm produces error with object of class zoo?
Based on the quote that Peter gave: o New generic function xtfrm() as an auxiliary helper for sort(), order() and rank(). This should return a numeric vector that sorts in the same way as its input. The default method supports any class with ==, and is.na() methods but specific methods can be much faster. As a side-effect, rank() will now work better on classed objects, although possibly rather slowly. it seems that it was the intention to have rank(x) use x only via xtfrm(x) but that is not, in fact, how it works as defining xtfrm.zoo still results in the discussed error. On Thu, Oct 23, 2008 at 5:13 AM, Pfaff, Bernhard Dr. [EMAIL PROTECTED] wrote: Dear Achim, Gabor, Jeff, Peter and remaining list-subscribers, first, please accept my apologies for having started this thread. Given the avalanche of responses (some off-list) and the associated time stamps, some of you have almost pulled an all-nighter about this topic. I might have not have started this thread in the first place, if I would have known this. I agree with Achim's view that a not working for zoo objects strategy is preferable compared to a half-working for zoo objects strategy. I do not have either a problem by employing coredata(z) when necessary. Now, Gabor, you pointed out nicely that the culprit, namely that order() resides on top of xtfrm whereas rank() does not (this was voiced by you in an email to Peter and R-Devel, hence I inlucde these recipients again in this thread and the reason for doing this is also motivated by the following proposition): You further pointed out that the problems wrt to rank and zoo-objects could be solved if rank() would, like order() does, reside on top of xtfrm. My question/proposal would then be to follow this approach, i.e. use xtfrm in rank. Now, I am not that deep into R nor an expert to judge whether this would cause problems/breaking existing R code in other instances; hence I appreciate feedback if this would be a feasible/desirable change in R-Devel. Best, Bernhard -Ursprüngliche Nachricht- Von: Gabor Grothendieck [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 23. Oktober 2008 02:36 An: Peter Dalgaard Cc: Pfaff, Bernhard Dr.; [EMAIL PROTECTED] Betreff: Re: [Rd] R 2.8.0 qqnorm produces error with object of class zoo? I don't think its hopeless. order works ok provided the underlying class defines an xtfrm method. I think rank should follow that route too. Its arguably the inconsistency between rank and order (order but not the rank uses xtfrm) that causes the inconsistent behavior between the two. If rank were also built on top of xtfrm then it would work as desired as well. On Wed, Oct 22, 2008 at 5:03 PM, Peter Dalgaard [EMAIL PROTECTED] wrote: Gabor Grothendieck wrote: And one other point. z - zoo(1:4) .gt(z, 1, 2) fails because z[1] and z[2] are at different time points so z[1] == z[2] is logical(0) because when zoo compares objects it aligns them first. Yes, that was the point that I was trying to make. Well, arguably it doesn't fail, it just does what it is supposed to do. Things would work with [[ or a preceding unclass(z), but that would break comparisons involving, say, POSIXlt objects. So you're sort of stuck between a rock and a hard place. On Wed, Oct 22, 2008 at 2:19 PM, Gabor Grothendieck [EMAIL PROTECTED] wrote: Yes, I noticed that but rank is not generic. An xtfrm.zoo method has been added to zoo on R-Forge but rank still fails: R.version.string [1] R version 2.8.0 Patched (2008-10-21 r46766) packageDescription(zoo)$Version [1] 1.5-3 library(zoo) # next line adds xtfrm zoo method xtfrm.zoo - coredata z - zoo(1:4) order(z) # ok [1] 1 2 3 4 qqnorm(z) # ok rank(z) # error Error in if (xi == xj) 0L else if (xi xj) 1L else -1L : argument is of length zero (If the MIME type is wrong, then that will happen.) Anyways, the root cause seems to be the new function .gt() which is related to o New generic function xtfrm() as an auxiliary helper for sort(), order() and rank(). This should return a numeric vector that sorts in the same way as its input. The default method supports any class with ==, and is.na() methods but specific methods can be much faster. As a side-effect, rank() will now work better on classed objects, although possibly rather slowly. Here, better may be in the eyes of the beholder, for dax[3]==dax[6] Data: logical(0) Index: integer(0) and accordingly rank(dax) Error in if (xi == xj) 0L else if (xi xj) 1L else -1L : argument is of length zero which is the error that you are seeing. What to do about it is a bit dubious. Obviously, we don't want to fix .gt() so that it automatically unclasses objects, and I assume that zoo has its reasons for not wanting to compare series with different indices. So I suppose that either the user must
Re: [Rd] R 2.8.0 qqnorm produces error with object of class zoo?
xtfrm.zoo has been added to the development version of zoo and should address this. It is available on R-Forge or in the meantime you can just add this line to your code: xtfrm.zoo - coredata On Wed, Oct 22, 2008 at 8:49 AM, Peter Dalgaard [EMAIL PROTECTED] wrote: Pfaff, Bernhard Dr. wrote: It seems, that in my previous emails the attached output files got deleted, hence these are now copied below: (If the MIME type is wrong, then that will happen.) Anyways, the root cause seems to be the new function .gt() which is related to o New generic function xtfrm() as an auxiliary helper for sort(), order() and rank(). This should return a numeric vector that sorts in the same way as its input. The default method supports any class with ==, and is.na() methods but specific methods can be much faster. As a side-effect, rank() will now work better on classed objects, although possibly rather slowly. Here, better may be in the eyes of the beholder, for dax[3]==dax[6] Data: logical(0) Index: integer(0) and accordingly rank(dax) Error in if (xi == xj) 0L else if (xi xj) 1L else -1L : argument is of length zero which is the error that you are seeing. What to do about it is a bit dubious. Obviously, we don't want to fix .gt() so that it automatically unclasses objects, and I assume that zoo has its reasons for not wanting to compare series with different indices. So I suppose that either the user must unclass, or zoo define rank.zoo. For R version 2.7.2: R version 2.7.2 (2008-08-25) Copyright (C) 2008 The R Foundation for Statistical Computing ISBN 3-900051-07-0 R ist freie Software und kommt OHNE JEGLICHE GARANTIE. Sie sind eingeladen, es unter bestimmten Bedingungen weiter zu verbreiten. Tippen Sie 'license()' or 'licence()' für Details dazu. R ist ein Gemeinschaftsprojekt mit vielen Beitragenden. Tippen Sie 'contributors()' für mehr Information und 'citation()', um zu erfahren, wie R oder R packages in Publikationen zitiert werden können. Tippen Sie 'demo()' für einige Demos, 'help()' für on-line Hilfe, oder 'help.start()' für eine HTML Browserschnittstelle zur Hilfe. Tippen Sie 'q()', um R zu verlassen. Invesco colors have been created! Usage: col = invcolor[1], or col = invcolor['blue'] etc. Type: 'invcolor' to see its definition. [Vorher gesicherter Workspace wiederhergestellt] library(zoo) Attache Paket: 'zoo' The following object(s) are masked from package:base : as.Date.numeric Warning message: Paket 'zoo' wurde unter R Version 2.8.0 gebaut sessionInfo() R version 2.7.2 (2008-08-25) i386-pc-mingw32 locale: LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY=German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252 attached base packages: [1] stats graphics utils datasets grDevices methods base other attached packages: [1] zoo_1.5-4 loaded via a namespace (and not attached): [1] grid_2.7.2 lattice_0.17-13 search() [1] .GlobalEnvpackage:zoo package:stats [4] package:graphics package:utils package:datasets [7] package:grDevices package:methods Autoloads [10] package:base packageDescription(zoo) Package: zoo Version: 1.5-4 Date: 2008-07-09 Title: Z's ordered observations Author: Achim Zeileis, Gabor Grothendieck Maintainer: Achim Zeileis [EMAIL PROTECTED] Description: An S3 class with methods for totally ordered indexed observations. It is particularly aimed at irregular time series of numeric vectors/matrices and factors. zoo's key design goals are independence of a particular index/date/time class and consistency with with ts and base R by providing methods to extend standard generics. Depends: R (= 2.4.1), stats Suggests: chron, fCalendar, fSeries, its, tseries, lattice, strucchange, DAAG, xts Imports: stats, utils, graphics, grDevices, lattice LazyLoad: yes License: GPL-2 URL: http://R-Forge.R-project.org/projects/zoo/ Packaged: Wed Jul 9 18:28:07 2008; zeileis Built: R 2.8.0; ; 2008-10-16 00:01:11; windows -- File: C:/R/package/zoo/Meta/package.rds data(EuStockMarkets) dax - as.zoo(EuStockMarkets[1:10, DAX]) daxr - diff(log(dax)) identical(as.vector(qnorm(daxr)), qnorm(coredata(daxr))) [1] TRUE Warning messages: 1: In qnorm(p, mean, sd, lower.tail, log.p) : NaNs wurden erzeugt 2: In qnorm(p, mean, sd, lower.tail, log.p) : NaNs wurden erzeugt qqnorm(coredata(daxr)) qqnorm(daxr) proc.time() User System verstrichen 1.650.132.97 For R version 2.8.0: version 2.8.0 (2008-10-20) Copyright (C) 2008 The R Foundation for Statistical Computing ISBN 3-900051-07-0 R ist freie Software und kommt OHNE JEGLICHE GARANTIE. Sie sind eingeladen, es unter bestimmten Bedingungen weiter zu verbreiten. Tippen Sie 'license
Re: [Rd] R 2.8.0 qqnorm produces error with object of class zoo?
On Wed, Oct 22, 2008 at 8:49 AM, Peter Dalgaard [EMAIL PROTECTED] wrote: Pfaff, Bernhard Dr. wrote: It seems, that in my previous emails the attached output files got deleted, hence these are now copied below: (If the MIME type is wrong, then that will happen.) Anyways, the root cause seems to be the new function .gt() which is related to o New generic function xtfrm() as an auxiliary helper for sort(), order() and rank(). This should return a numeric vector that sorts in the same way as its input. The default method supports any class with ==, and is.na() methods but specific methods can be much faster. As a side-effect, rank() will now work better on classed objects, although possibly rather slowly. Here, better may be in the eyes of the beholder, for dax[3]==dax[6] Data: logical(0) Index: integer(0) and accordingly rank(dax) Error in if (xi == xj) 0L else if (xi xj) 1L else -1L : argument is of length zero which is the error that you are seeing. What to do about it is a bit dubious. Obviously, we don't want to fix .gt() so that it automatically unclasses objects, and I assume that zoo has its reasons for not wanting to compare series with different indices. So I suppose that either the user must unclass, or zoo define rank.zoo. Actually qqnorm does not use rank but it does use order and with the xtfrm.zoo method I mentioned qqnorm works with zoo; however, I think rank needs to be fixed in R to make use of xtfrm as well since I would have expected that supplying an xtfrm method for zoo would be sufficient to get both order and rank to work without giving errors. Also note that rank is not generic. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.8.0 qqnorm produces error with object of class zoo?
Yes, I noticed that but rank is not generic. An xtfrm.zoo method has been added to zoo on R-Forge but rank still fails: R.version.string [1] R version 2.8.0 Patched (2008-10-21 r46766) packageDescription(zoo)$Version [1] 1.5-3 library(zoo) # next line adds xtfrm zoo method xtfrm.zoo - coredata z - zoo(1:4) order(z) # ok [1] 1 2 3 4 qqnorm(z) # ok rank(z) # error Error in if (xi == xj) 0L else if (xi xj) 1L else -1L : argument is of length zero (If the MIME type is wrong, then that will happen.) Anyways, the root cause seems to be the new function .gt() which is related to o New generic function xtfrm() as an auxiliary helper for sort(), order() and rank(). This should return a numeric vector that sorts in the same way as its input. The default method supports any class with ==, and is.na() methods but specific methods can be much faster. As a side-effect, rank() will now work better on classed objects, although possibly rather slowly. Here, better may be in the eyes of the beholder, for dax[3]==dax[6] Data: logical(0) Index: integer(0) and accordingly rank(dax) Error in if (xi == xj) 0L else if (xi xj) 1L else -1L : argument is of length zero which is the error that you are seeing. What to do about it is a bit dubious. Obviously, we don't want to fix .gt() so that it automatically unclasses objects, and I assume that zoo has its reasons for not wanting to compare series with different indices. So I suppose that either the user must unclass, or zoo define rank.zoo. Actually qqnorm does not use rank but it does use order and with the xtfrm.zoo method I mentioned qqnorm works with zoo; however, I think rank needs to be fixed in R to make use of xtfrm as well since I would have expected that supplying an xtfrm method for zoo would be sufficient to get both order and rank to work without giving errors. Also note that rank is not generic. Notice that xtfrm.default() uses rank() -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.8.0 qqnorm produces error with object of class zoo?
And one other point. z - zoo(1:4) .gt(z, 1, 2) fails because z[1] and z[2] are at different time points so z[1] == z[2] is logical(0) because when zoo compares objects it aligns them first. On Wed, Oct 22, 2008 at 2:19 PM, Gabor Grothendieck [EMAIL PROTECTED] wrote: Yes, I noticed that but rank is not generic. An xtfrm.zoo method has been added to zoo on R-Forge but rank still fails: R.version.string [1] R version 2.8.0 Patched (2008-10-21 r46766) packageDescription(zoo)$Version [1] 1.5-3 library(zoo) # next line adds xtfrm zoo method xtfrm.zoo - coredata z - zoo(1:4) order(z) # ok [1] 1 2 3 4 qqnorm(z) # ok rank(z) # error Error in if (xi == xj) 0L else if (xi xj) 1L else -1L : argument is of length zero (If the MIME type is wrong, then that will happen.) Anyways, the root cause seems to be the new function .gt() which is related to o New generic function xtfrm() as an auxiliary helper for sort(), order() and rank(). This should return a numeric vector that sorts in the same way as its input. The default method supports any class with ==, and is.na() methods but specific methods can be much faster. As a side-effect, rank() will now work better on classed objects, although possibly rather slowly. Here, better may be in the eyes of the beholder, for dax[3]==dax[6] Data: logical(0) Index: integer(0) and accordingly rank(dax) Error in if (xi == xj) 0L else if (xi xj) 1L else -1L : argument is of length zero which is the error that you are seeing. What to do about it is a bit dubious. Obviously, we don't want to fix .gt() so that it automatically unclasses objects, and I assume that zoo has its reasons for not wanting to compare series with different indices. So I suppose that either the user must unclass, or zoo define rank.zoo. Actually qqnorm does not use rank but it does use order and with the xtfrm.zoo method I mentioned qqnorm works with zoo; however, I think rank needs to be fixed in R to make use of xtfrm as well since I would have expected that supplying an xtfrm method for zoo would be sufficient to get both order and rank to work without giving errors. Also note that rank is not generic. Notice that xtfrm.default() uses rank() -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.8.0 qqnorm produces error with object of class zoo?
I don't think its hopeless. order works ok provided the underlying class defines an xtfrm method. I think rank should follow that route too. Its arguably the inconsistency between rank and order (order but not the rank uses xtfrm) that causes the inconsistent behavior between the two. If rank were also built on top of xtfrm then it would work as desired as well. On Wed, Oct 22, 2008 at 5:03 PM, Peter Dalgaard [EMAIL PROTECTED] wrote: Gabor Grothendieck wrote: And one other point. z - zoo(1:4) .gt(z, 1, 2) fails because z[1] and z[2] are at different time points so z[1] == z[2] is logical(0) because when zoo compares objects it aligns them first. Yes, that was the point that I was trying to make. Well, arguably it doesn't fail, it just does what it is supposed to do. Things would work with [[ or a preceding unclass(z), but that would break comparisons involving, say, POSIXlt objects. So you're sort of stuck between a rock and a hard place. On Wed, Oct 22, 2008 at 2:19 PM, Gabor Grothendieck [EMAIL PROTECTED] wrote: Yes, I noticed that but rank is not generic. An xtfrm.zoo method has been added to zoo on R-Forge but rank still fails: R.version.string [1] R version 2.8.0 Patched (2008-10-21 r46766) packageDescription(zoo)$Version [1] 1.5-3 library(zoo) # next line adds xtfrm zoo method xtfrm.zoo - coredata z - zoo(1:4) order(z) # ok [1] 1 2 3 4 qqnorm(z) # ok rank(z) # error Error in if (xi == xj) 0L else if (xi xj) 1L else -1L : argument is of length zero (If the MIME type is wrong, then that will happen.) Anyways, the root cause seems to be the new function .gt() which is related to o New generic function xtfrm() as an auxiliary helper for sort(), order() and rank(). This should return a numeric vector that sorts in the same way as its input. The default method supports any class with ==, and is.na() methods but specific methods can be much faster. As a side-effect, rank() will now work better on classed objects, although possibly rather slowly. Here, better may be in the eyes of the beholder, for dax[3]==dax[6] Data: logical(0) Index: integer(0) and accordingly rank(dax) Error in if (xi == xj) 0L else if (xi xj) 1L else -1L : argument is of length zero which is the error that you are seeing. What to do about it is a bit dubious. Obviously, we don't want to fix .gt() so that it automatically unclasses objects, and I assume that zoo has its reasons for not wanting to compare series with different indices. So I suppose that either the user must unclass, or zoo define rank.zoo. Actually qqnorm does not use rank but it does use order and with the xtfrm.zoo method I mentioned qqnorm works with zoo; however, I think rank needs to be fixed in R to make use of xtfrm as well since I would have expected that supplying an xtfrm method for zoo would be sufficient to get both order and rank to work without giving errors. Also note that rank is not generic. Notice that xtfrm.default() uses rank() -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build on Vista
Check what drives you have available on your system and what file system each uses. Click on Start button and type in System Information and then choose Components / Storage / Drives in the left side panel. That will report all your drives and their file system and other information. Try running the build on a drive with a different file system and see if that helps. If you are able to remove the drive that seems to be the problem you might want to do that to ensure that its not being used for temporary files during the build. On Sun, Oct 19, 2008 at 12:56 PM, Ollivier TARAMASCO [EMAIL PROTECTED] wrote: Hello, I have R 2.7.2 and RTools 2.8 on a vista pro computer. On my computer R CMD build changes the file names : all capital letters are transformed into lowercase letters (for instance the DESCRIPTION file is changed in 'description'). What can I do to correct this problem? Tank you, Ollivier TARAMASCO [[alternative HTML version deleted]] __ 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] relative path to source files in vignette
See ?system.file with the package= argument.
On Fri, Oct 10, 2008 at 2:19 PM, Peter Ruckdeschel
[EMAIL PROTECTED] wrote:
Hi,
this may be slightly off-topic, but as you are the experts:
we have written a small vignette, in which we want to refer to
.R, .Rd source files by means of relative paths.
More specifically, we want to use TeX package listings to include
source code,
[which btw in the mean time works pretty well together with fancyvrb
so can be used
with Sweave without problems...]
To avoid redundancy we would like to use
\lstinputlisting[firstline=n1,lastline=n2]{r-source-file.R}
and to do so we somehow need path information.
This is /not/ a listings issue, as we might also have used
\input{r-source-file.R}, only is \lstinputlisting a bit more
flexible...
Using relative paths, i.e. as the vignette resides in subfolder inst/doc
something like
../../../mypkg/R/myR.Ror ../../../mypkg/man/myRd.Rd
does the job for both R CMD build and R CMD check ,
--- in standard configurations.
However, as you may change the location of the check folder with
the -o option of R CMD check, (and possibly other things, we have
not yet thought of ...), our solution is not quite satisfactory,
so we have been wondering whether there is a (platform-independent)
way to access the package source folder (under check) from within
TeX.
--- or if you prefer to solve it from R-side:
We would appreciate an Sweave-chunk to do the following:
+have three arguments firstline, lastline, filename
[where filename is relative to the package source folder]
+read out the information about the path to the package
source folder [from the env-variable?]
+with this information read in the part of the source file
between firstline and lastline
and places this content ---without wrapping it to
\begin{Schunk} ... \end{Schunk}--- into the .tex file
---preferrably already into a \begin{listing}\end{listing}
environment...
Any suggestions how to resolve this?
Thank you already,
Peter
__
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] relative path to source files in vignette
Try placing a copy of the files in the inst directory and then accessing them via system.files(myfile.R, package = mypackage) or place them in the same directory as the Sweave file and then access them without a directory path at all: readLines(myfile.R) On Fri, Oct 10, 2008 at 2:48 PM, Peter Ruckdeschel [EMAIL PROTECTED] wrote: Gabor Grothendieck schrieb: See ?system.file with the package= argument. Thank you Gabor, but this refers to the /installed/ package, while we are needing path information about the not-yet-built source code of the package during R CMD check / build. Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] relative path to source files in vignette
On Fri, Oct 10, 2008 at 7:06 PM, Peter Ruckdeschel
[EMAIL PROTECTED] wrote:
Thanks again Gabor, for your quick reply,
Try placing a copy of the files in the inst directory and then
accessing them via system.files(myfile.R, package = mypackage)
you mean I should do this in an S-chunk in the .Rnw file?
I.e., running Sweave on it would then produce the copy into my Sweave file
I need?
This could indeed be an opition, but as noted in my reply to Robert, my
guess
is that in the library where you install your packages to and which is
found with
system.file(), you will no longer find the R source files but rather
some .rdb
or .rdx file. At least this is what I found --- or is there some magic trick
to get back the source files from this?
Yes, that is what occurs. That's why it was suggested to copy it.
or place them in the same directory as the Sweave file
and then access them without a directory path at all:
readLines(myfile.R)
If I put the sources statically into the same directory as the Sweave file
(i.e. in [...]/myRsources/myPkg/inst/doc),
of course everything works fine;
The issue is that I want to dynamically include parts of the source
R code itself (without unnecessary static copying the source R code
due to consistency traps, when changing the R code but not
the copy) from the R directory of the package into the Sweave
file by something like
\input{[Path]/myRfile.R}
so that once I change the R code, I do not have to change
the .Rnw file.
[I do not include the whole .R file but only certain lines of it, of course]
As already said, in a standard configuration something like
\input{../../../myPkg/R/myRfile.R}
% goes from [...]/myRSources/myPkg/inst/src to [...]/myRSources/myPkg/R
% in R CMD build
% resp. from [...]/myRSources/myPkg.Rcheck/inst/src to
[...]/myRSources/myPkg/R
% in R CMD check
does the job.
Now if I am in [...]/myRSources and say something like
R CMD build myPkg ### still works
R CMD check myPkg -o /yetAnotherPath/myCheck
## does not work as /yetAnotherPath/myPkg/R need not be [...]/myPkg/R
So what I was looking for was something like defining an environment
variable
$myRSources (in a platform-independent way)
which may be accessed (in a platform-independent way) from
the TeX command \input{...} --- perhaps with something like
\input{$myRSources/myPkg/R/myRfile.R}
but I cannot figure out how to do this...
Thank you once again
Peter
Perhaps you should just preprocess your Sweave files prior to the build.
The brew package could be used, for example.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] why is \alias{anRpackage} not mandatory?
Some examples are: - be able to use brew package or similar alternative in place of Sweave - provide a pdf regardless how it was generated without ugly workarounds and still let the user get a list of all pdf documents in one place, e.g. library(help = mypackage) should list the vignettes and other pdfs too so its all together and there should be some facility similar to vignettes() to easily access them. On Mon, Oct 6, 2008 at 10:22 AM, Duncan Murdoch [EMAIL PROTECTED] wrote: On 10/6/2008 9:55 AM, hadley wickham wrote: It may not be much work for you, but I find any additional requirements to the package format to be a real pain. I have ~10 packages on CRAN and having to go through and add this extra information all at once is a big hassle. R releases tend to happen in the middle of the US academic semester when I have a lot of other things on my plate. O.K., but the discussion with Duncan shows: - the required information is already available (in DESCRIPTION), - one can think about ways to generate the page automatically for existing packages, - the intro can be short and should link to other pages or PDFs, - one should avoid doubling and inconsistency. I'm obviously not going to object if it's done automatically, and I already strive to avoid doubling and inconsistency by producing most my documentation algorithmically. I think you are being cavalier by not caring about the extra work you want package authors to do. Additionally, I find that rdoc is the wrong format for lengthy explanation and exposition - a pdf is much better - and I think that the packages already have a abstract: the description field in DESCRIPTION. o.k., but abstract may be (technically) in the wrong format and does not point to the other relevant parts of the package documentation. Then I don't think you should call what you want an abstract. The main problem with vignettes at the moment is that they must be sweave, a format which I don't really like. I wish I could supply my own pdf + R code file produced using whatever tools I choose. I like Sweave, and it is also possible to include your own PDFs and R files and then to reference them in anRpackage.Rd. Yes, but they're not vignettes - which means they're not listed under vignette() and it's yet another place for people to look for documentation. Vignettes have R code in them and a way to extract it, so it's misleading to call something that's just a .pdf file a vignette. But I imagine there could be other ways to mix R code with documentation besides the existing Sweave formats. The most obvious way to add another one is to write another Sweave driver. I think it would require changes to the base of R to allow for Sweave drivers in packages, working with files that don't have extensions (R|r|S|s)(nw|tex), but in principle I don't see any real objection to adding that. The change I would like to see in Sweave would be the ability to include or exclude R and latex sections based on the results of the R code. That would allow it to be used in conditional report generation and not just documentation. I know there are workarounds but they are ugly and not satisfactory in my opinion. Also passing arguments to R CMD Sweave would be nice. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Attributes of top level environments clobbered (was Re: [R] possible bug in function 'var' in R 2.7.2?)
On Sat, Oct 4, 2008 at 10:45 AM, laurent [EMAIL PROTECTED] wrote: On Sat, 2008-10-04 at 12:00 +0200, [EMAIL PROTECTED] wrote: Message: 18 Date: Fri, 3 Oct 2008 15:35:18 -0500 (CDT) From: Luke Tierney [EMAIL PROTECTED] Subject: Re: [Rd] Attributes of top level environments clobbered (was Re: [R] possible bug in function 'var' in R 2.7.2?) To: Gabor Grothendieck [EMAIL PROTECTED] Cc: r-devel@r-project.org r-devel@r-project.org, Martin Maechler [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Fri, 3 Oct 2008, Gabor Grothendieck wrote: On Fri, Oct 3, 2008 at 12:46 PM, Luke Tierney [EMAIL PROTECTED] wrote: On Fri, 3 Oct 2008, Gabor Grothendieck wrote: On Fri, Oct 3, 2008 at 11:43 AM, Luke Tierney [EMAIL PROTECTED] wrote: [...] I do appreciate the excellent R software; however, there are a few points like those addressed on the proto home page which do need to be addressed in R for it to be fully functional. There are some interesting poins on that page that are worth looking into. Over time I suspect all but the current 3. will be addressed, but 3., which is a variant on the unclass issue, is not likely to be. You can call this a deficiency in R if you like, and I would agree in the sense that I think it is inappropriate to allow attributes to be set but not in a reliable way because they can be inadvertenly removed. We should have done this differently. THere were/are two choices: Make reference values, including environments, special in that they may not have attributes. This woud have been fairly easy (modulo one use made in decorating the frames on the search path) and could be done now to clean things up. Make R-visible environments in two parts--a wrapper that is passed by value like standard R objects and could have attributes, and an internal part that is essentially the current environment object. This is analogous to the way that character vectors, even of length 1, consist of an STRSXP wrapper containing CHARSXPs that hold the string. The STRSXP's are visible at the R level, the CHARSXPs are not. This would have been messier to implement, and unfortunately would be very messy to retro-fit at this point, so it isn't likely to happen unless there is some other compelling reason to do so. Couldn't the two options be merged into one for a start ? - Make reference values either attribute-free entities (seems important, as the poor reliability of assigning attributes to environment is probably not widely known), or generate warnings upon assignment of attributes. Some specifics need to be added to the poor reliability phrase relating to of attributed environments. The proto package changes the class attribute of environments (but no other attribute of environments) and proto in turn underlies large widely used packages which likely exercise it thoroughly yet through this experience the only places where this was noticeable were points #1 and #3 of the Avoiding R Bugs section of the proto home page at http://r-proto.googlecode.com Neither of these are two points are deal breakers as - #1 has an easy workaround (just change one line in your DESCRIPTION file) and if the promised fix is made even this won't be necesary, - #3 mostly seems mostly harmless in the context of proto as the only attribute change is from a class of enviornment to c(proto, environment). Artificial examples can be constructed where this is a problem but substantial experience with it suggests that it is not a problem in practice. (The remaining R problems listed are all related to promises, not environments.) - Create an R-level class that contains an environment (Environment ?, envobj ?) and implements an environment-like interface by delegation (somehow like your option 2. above). Gabor could certainly create his own class, but having this administered at the R-core level would have the following potential benefits: - Anyone with similar needs will think twice before starting to implement his own solution. - That one class can be moved to a lower level in the internals (C-level, with a new given SEXPTYPE) if it proves a working solution, and as time permits. Just a thought, Actually, I see the main benefit of this or other approach as providing the missing elements of S3 support to environments thereby potentially streamlining the implementation of every package that needs it (proto, tcltk, R.oo, ...) or more perhaps more accurately allowing tcltk and R.oo and other such packages to become as streamlined as proto already is. Each of these packages could then use inheritance rather than containment thereby leveraging the S3 OO facilities that one really expects R to provide. It would be important that the new class whose objects contain environments is sufficiently indistinguishable in terms of its
Re: [Rd] Attributes of top level environments clobbered (was Re: [R] possible bug in function 'var' in R 2.7.2?)
On Fri, Oct 3, 2008 at 11:43 AM, Luke Tierney [EMAIL PROTECTED] wrote: I will look into fixing it sometime if no one else feels like doing it. The environment aspect is not high priority; some other related issues are more so (locking and active bindings as I recall). But even thoughs may not make it to the top of my queue any time soon. The issue of placing attributes on environments has come up before, many times. It is routinely advised against. For better or worse, the way environments were exposed to the R level is not designed to support this properly. Fixing this so that attributes are supported reliably is non-trivial, and it is hard to justify the effort given that there are standard work-arounds (such as putting the environment in a list and attaching attributes to the list). An alternative way of removing the issues associated with attributes on environments, in line with the way NULL works, is to disable placing attributes on environments, at least from the R level. This option is looking increasingly attractive. These are not good options: - the workaround does not allow one to inherit methods. This implies tediously rewriting or writing wrappers every inherited method in any such subclass. Its really tantamount to eliminating OO for environments which is not a reasonable solution for a language that is supposed to be OO. - eliminating attributes on environments is even worse since widely used packages such as proto, ggplot2 and other packages would suffer. Maintaining reasonable compatiblity should be a goal of the core development. It would be better to document the current situation than to make such a retrograde change. - if time is a problem perhaps the core group needs to add resources to reasonably address the problems in R. Traditional economics do not apply to an open source project. There is no monetary cost to adding additional developers. luke On Fri, 3 Oct 2008, Gabor Grothendieck wrote: On Fri, Oct 3, 2008 at 3:23 AM, Martin Maechler [EMAIL PROTECTED] wrote: a much better (and much less error-prone) idea would be to install R 2.8.0 alpha even now. It will become 'beta' early next week. We are asking the R community to please install and use pre-release versions of R (if you can / are allowed to) at least from beta onwards, and report problems you see early on *before* the final release. The bug discussed in the following year-old post suggested that the problem of clobbering attributes of top level environment objects would be fixed for 2.7 but its still in R version 2.7.2 (2008-08-25) and also still in R version 2.8.0 alpha (2008-10-01 r46589) https://stat.ethz.ch/pipermail/r-devel/2007-October/047184.html The Avoiding R Bugs section of this page: http://r-proto.googlecode.com has more discussion as well as a list of some other R bugs. This can be tested by creating a package with these two files only: ---DESCRIPTION--- Package: testlazy Version: 1.0-0 Date: 2008-10-03 Title: Test lazy loading Author: G Grothendieck Maintainer: G Grothendieck [EMAIL PROTECTED] Description: Test lazy loading with top level objects. Depends: proto LazyLoad: yes License: GPL-2 ---R/testlazy.R--- TopLevel - proto() --- And then testing it: library(testlazy) class(TopLevel) If its class is environment only then the class attribute was stripped. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Attributes of top level environments clobbered (was Re: [R] possible bug in function 'var' in R 2.7.2?)
On Fri, Oct 3, 2008 at 12:46 PM, Luke Tierney [EMAIL PROTECTED] wrote: On Fri, 3 Oct 2008, Gabor Grothendieck wrote: On Fri, Oct 3, 2008 at 11:43 AM, Luke Tierney [EMAIL PROTECTED] wrote: I will look into fixing it sometime if no one else feels like doing it. The environment aspect is not high priority; some other related issues are more so (locking and active bindings as I recall). But even thoughs may not make it to the top of my queue any time soon. The issue of placing attributes on environments has come up before, many times. It is routinely advised against. For better or worse, the way environments were exposed to the R level is not designed to support this properly. Fixing this so that attributes are supported reliably is non-trivial, and it is hard to justify the effort given that there are standard work-arounds (such as putting the environment in a list and attaching attributes to the list). An alternative way of removing the issues associated with attributes on environments, in line with the way NULL works, is to disable placing attributes on environments, at least from the R level. This option is looking increasingly attractive. These are not good options: - the workaround does not allow one to inherit methods. This implies tediously rewriting or writing wrappers every inherited method in any such subclass. Its really tantamount to eliminating OO for environments which is not a reasonable solution for a language that is supposed to be OO. It would mean sealing environments, making them final, pick your favorite OO terminology. Standard thing to do in many OO languages when it is wararanted. I don't think this really addresses the problem. The S3 model is in principle capable of handling environments and almost does so fully now. - eliminating attributes on environments is even worse since widely used packages such as proto, ggplot2 and other packages would suffer. Maintaining reasonable compatiblity should be a goal of the core development. It would be better to document the current situation than to make such a retrograde change. The authors of proto would finally need to bite the bullet and address this issue. This would make proto more reliable in the end. The fact that environment attributes get clobbered at top level when defined in packages with lazy loading (but not outside packages nor in packages without lazy loading) is clearly a deficiency of R, not proto. Furthermore, the suggstion that this deficiency in R somehow reflects any unreliably in proto is likewise not accurate. proto is extremely reliable, particularly in comparison to R. In fact there are no known bugs in the development version of proto and large widely used packages use proto. (If you are aware of any bugs let me know.) The fact that it is so solid is quite understandable because even if some of its code is necessarily complex the code is so short that its readily possible to accomplish this apprent bug-free status with reasonble effort. Furthermore, the proto home page documents the problems -- mostly problems with R itself, not proto. I do appreciate the excellent R software; however, there are a few points like those addressed on the proto home page which do need to be addressed in R for it to be fully functional. luke - if time is a problem perhaps the core group needs to add resources to reasonably address the problems in R. Traditional economics do not apply to an open source project. There is no monetary cost to adding additional developers. luke On Fri, 3 Oct 2008, Gabor Grothendieck wrote: On Fri, Oct 3, 2008 at 3:23 AM, Martin Maechler [EMAIL PROTECTED] wrote: a much better (and much less error-prone) idea would be to install R 2.8.0 alpha even now. It will become 'beta' early next week. We are asking the R community to please install and use pre-release versions of R (if you can / are allowed to) at least from beta onwards, and report problems you see early on *before* the final release. The bug discussed in the following year-old post suggested that the problem of clobbering attributes of top level environment objects would be fixed for 2.7 but its still in R version 2.7.2 (2008-08-25) and also still in R version 2.8.0 alpha (2008-10-01 r46589) https://stat.ethz.ch/pipermail/r-devel/2007-October/047184.html The Avoiding R Bugs section of this page: http://r-proto.googlecode.com has more discussion as well as a list of some other R bugs. This can be tested by creating a package with these two files only: ---DESCRIPTION--- Package: testlazy Version: 1.0-0 Date: 2008-10-03 Title: Test lazy loading Author: G Grothendieck Maintainer: G Grothendieck [EMAIL PROTECTED] Description: Test lazy loading with top level objects. Depends: proto LazyLoad: yes License: GPL-2 ---R/testlazy.R--- TopLevel - proto() --- And then testing it: library(testlazy) class(TopLevel) If its class
Re: [Rd] splitting strings efficiently
Also one can create a text connection and read it using read.table, scan, etc.
s - c(12;13;14, 15;16;17)
read.table(textConnection(s), sep = ;)
# or
scan(textConnection(s), sep = ;)
On Wed, Sep 24, 2008 at 12:20 PM, Mark Kimpel [EMAIL PROTECTED] wrote:
I knew there HAD to be a basic function, but 'help.search(split string)'
and 'help(string) did not find it. Thanks for the help on this elementary
question.
Mark
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine
15032 Hunter Court, Westfield, IN 46074
(317) 490-5129 Work, Mobile VoiceMail
(317) 399-1219 Home
Skype: mkimpel
**
On Wed, Sep 24, 2008 at 12:17 PM, Erik Iverson [EMAIL PROTECTED]wrote:
?strsplit
Mark Kimpel wrote:
I have a very long list of strings. Each string actually contains multiple
values separated by a semi-colon. I need to turn each string into a vector
of the values delimited by the semi-colons. I know I can do this very
laboriously by using loops, nchar, and substr, but it is terribly slow. Is
there a basic R function that handles this situation? If not, is there
perhaps a faster way to do it than I currently am, which is to lapply the
following function? Thanks, Mark
###
string.tokenizer.func-function(string, separator){
new.vec- NULL
newString-
if(is.null(string)) {new.vec-} else {
for(i in 1:(nchar(string) + 1)){
if(substr(string, i, i) == separator){
new.vec-c(new.vec,newString)
newString -
} else {
newString-paste(newString, substr(string, i, i), sep=)
}
}
new.vec-c(new.vec,newString)
}
new.vec
}
Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
Indiana University School of Medicine
15032 Hunter Court, Westfield, IN 46074
(317) 490-5129 Work, Mobile VoiceMail
(317) 399-1219 Home
Skype: mkimpel
**
[[alternative HTML version deleted]]
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Dates in C api
The chron package does: library(chron) times(12:34:56) Internally times are represented as a faction of a day. On Mon, Sep 22, 2008 at 3:41 PM, Lee, Philip (IT) [EMAIL PROTECTED] wrote: r-devel, One other question just occurred to me - does R have any concept of times alone? I can see that there's dates, and datetimes (POSIXct etc), but how should I represent 12:34:56 as just a time? Thanks, Phil -Original Message- From: Jeff Ryan [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2008 4:19 PM To: Lee, Philip (IT) Cc: r-devel@r-project.org Subject: Re: [Rd] Dates in C api If you are looking for examples of handling dates/times (specifically POSIXct) within C code, the dev branch of xts has quite a bit of code now. http://r-forge.r- project.org/plugins/scmsvn/viewcvs.php/dev/pkg/src/?root=xts Assigning the class (or any attribute) within the C code will be much faster than doing it outside of C, at least in my experience with larger data. setAttrib(ans, R_ClassSymbol, mkString(Date)) HTH Jeff On Wed, Sep 17, 2008 at 12:24 PM, Lee, Philip (IT) [EMAIL PROTECTED] wrote: r-devel, I've been trying to write a C plugin for R, and I'm struggling to understand how dates are represented. I can create a date in R: mydate-as.Date(1, origin=1900-01-01) mydate [1] 1900-01-02 When I pass my date to a plugin, though, it's type is that of a real. There doesn't seem to be a date type in Rinternals.h, is there a way to recognize that a value is a date rather than a real? Equally, does anyone know if it's possible to create date values in the C api? Thanks, Phil Lee Philip Lee Morgan Stanley | Technology 750 Seventh Avenue, 12th Floor | New York, NY 10019 [EMAIL PROTECTED] NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan [EMAIL PROTECTED] ia: insight algorithmics www.insightalgo.com NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. __ 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] aggregate() does not return POSIXct object correctly (PR#12887)
On Tue, Sep 16, 2008 at 11:22 AM, Peter Dalgaard [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Full_Name: Rene Locher Version: 2.7.2 Patched (2008-09-12 r46541) OS: XP Submission from: (NULL) (160.85.231.40) dat - data.frame(event=factor(c(A,A,B)), time=as.POSIXct(c(2008-01-10,2008-01-01,2008-01-04))) min(dat$time) ## 2008-01-01 CET ## as expected aggregate(dat$time,by=list(event=dat$event),min) ## results in ##event x ## 1 A 1199142000 ## 2 B 1199401200 ## I expected: ##eventx ## 1 A 2008-01-01 CET ## 2 B 2008-01-04 CET This is as documented, possibly annoying, but not a bug. aggregate() is documented to build on tapply() for which the discarding of class is documented on ?tapply. The root cause is unlist(): tapply(dat[[time]],dat$event,min,simplify=FALSE) $A [1] 2008-01-01 CET $B [1] 2008-01-04 CET unlist(tapply(dat[[time]],dat$event,min,simplify=FALSE)) A B 1199142000 1199401200 and a partial rationale is that unlist() wouldn't know what to do if the arguments had different classes. The workaround is, of course, just to stick the class back on. Another workaround is: https://stat.ethz.ch/pipermail/r-help/2008-September/173139.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in package chron (PR#12599)
chron represents times as a fraction of a day using doubles so seconds cannot necessarily be represented exactly thus this is an example of FAQ 7.31: http://cran.r-project.org/doc/manuals/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f Try this: library(chron) tt - c(09:45:00, 09:45:01, 09:45:04, 09:45:05, 09:45:06, 09:45:08, 09:45:11, 09:45:12, 09:45:14) tt - times(tt) trunc(tt[3] + times(00:00:01), sec) == tt[4] [1] TRUE See R News 4/1. On Tue, Aug 26, 2008 at 2:05 AM, [EMAIL PROTECTED] wrote: Full_Name: Zeng, zhenxing Version: 2.7.1 (2008-06-23) OS: windows XP Submission from: (NULL) (158.182.1.30) Dear Author I have run into a trouble in using chron package The data frame: a date time_fut expiry_day bid ask trade_day 1 2004-09-01 09:45:002004-10 12860 1288938 2 2004-09-01 09:45:012004-10 12885 1289038 3 2004-09-01 09:45:042004-10 12883 1288738 4 2004-09-01 09:45:052004-10 12878 1288638 5 2004-09-01 09:45:062004-10 12881 1288738 6 2004-09-01 09:45:082004-10 12881 1288238 7 2004-09-01 09:45:112004-10 12881 1288438 8 2004-09-01 09:45:122004-10 12882 1288438 9 2004-09-01 09:45:142004-10 12882 1288338 I use the package chron a$time_fut-times(a$time_fut) a$date-as.Date(a$date) a$expiry_day-as.character(a$expiry_day) any(am$time_fut[2]==(am$time_fut[1]+times(00:00:01))) the answer: True any(a$time_fut[5]==(a$time_fut[4]+times(00:00:01))) [1] TRUE any(am$time_fut[4]==(am$time_fut[3]+times(00:00:01))) the answer: False But, the right answer should be true I don't know why, I am using the R version: 2.7.1 attached please find the data. Thank you Best wishes __ 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] name conflicts
Use two colons, not three. On Mon, Aug 25, 2008 at 3:05 PM, Max Kuhn [EMAIL PROTECTED] wrote: Everyone, I've got code in my package that uses LogitBoost from the caTools package. caTools does not have a namespace. My package also uses loads RWeka, which has a namespace, and also has a function called LogitBoost. After loading both packages, how can I be specific about running the version from caTools (since caTools:::LogitBoost won't work)? Thanks, Max __ 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] extending the derivs table/fools rushing in
While you are at it could you add { to the
table so that this works:
# this is ok
f - function(x) x*x
D(body(f), x)
x + x
# but not g which is same as f
# except it has { ... } surrounding its body
g - function(x) { x*x }
D(body(g), x)
Error in D(body(g), x) : Function '`{`' is not in the derivatives table
2008/8/14 Ben Bolker [EMAIL PROTECTED]:
I added plogis to the derivative table in the
development version of R; the patch against yesterday's
R-devel src/deriv/main.c is available at
http://www.zoology.ufl.edu/bolker/deriv_patch.txt .
I pretty much followed the framework of the other symbols;
here was my incantation
- } else if (CAR(expr) == PlogisSymbol) {
- ans = simplify(TimesSymbol,
- PP_S(TimesSymbol,
- PP_S2(ExpSymbol,
- PP_S2(MinusSymbol,CADR(expr))),
- PP_S(PowerSymbol,
-PP_S(PlusSymbol,
- Constant(1.),
- PP_S2(ExpSymbol,
-PP_S2(MinusSymbol,CADR(expr,
-Constant(-2.))),
- PP(D(CADR(expr),var)));
- UNPROTECT(8);
It seems to work:
D(quote(plogis(a)),a)
exp(-a) * (1 + exp(-a))^-2
D(quote(plogis(a+b*x)),x)
exp(-(a + b * x)) * (1 + exp(-(a + b * x)))^-2 * b
Any thoughts? I'm sure there's a cleverer way to do this ...
Ben Bolker
PS I get a minor build error at the end of the compilation
(on Ubuntu 8.10):
make[2]: *** No rule to make target `VR.ts', needed by
`stamp-recommended'. Stop.
make[2]: Leaving directory
`/usr/local/src/R/R-devel/src/library/Recommended'
make[1]: *** [recommended-packages] Error 2
make[1]: Leaving directory
`/usr/local/src/R/R-devel/src/library/Recommended'
make: *** [stamp-recommended] Error 2
... don't know if that is important or not.
__
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] extending the derivs table/fools rushing in
You could see if Ryacas package can do what you want: http://ryacas.googlecode.com 2008/8/14 Ben Bolker [EMAIL PROTECTED]: Prof Brian Ripley wrote: The derivative of plogis is surely dlogis. (And yes, there is a good reason why we have such a function: take a look at its C code.) Doh. That means we would need an entry for dlogis too, I guess. I am not convinced that there is a real need for these (and where does this stop?) What would be much more useful is to make this user-extensible (as Bill Venables pointed out a decade ago). [pd]norm were added in 2002 to support MASS, the ability to do all of MASS in R being a goal at the time. I agree it would be great to make this user-extensible, but it's probably a bit beyond me ... I found a web-reference of Venables saying There is a detailed example towards the end of Ch. 9 of VR on how to extend D() and make.call(), which are the work horses for deriv(), to handle new functions. The new functions handled there are dnorm() and pnorm(), but I() would be even easier, of course. http://www.math.yorku.ca/Who/Faculty/Monette/pub/s-old/0690.html ... but this is from 1997 therefore presumably MASS3? or MASS2? -- I can't find my copy of MASS3 at the moment, and don't own MASS2 ... The reason behind this is that I was trying to write a simple analytic derivative calculator for formulae of the form (e.g.) y ~ dbinom(prob=plogis(a+b*x),size=N) Obviously in this case I could just tell people to write the formula out as y ~ dbinom(prob=1/(1+exp(-(a+b*x))),size=N) ... Ben Bolker __ 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] matrix name
Try this: matrix(1:9, 3, dim = list(x = letters[1:3], y = LETTERS[1:3])) y x A B C a 1 4 7 b 2 5 8 c 3 6 9 On Sat, Aug 9, 2008 at 12:34 PM, mel [EMAIL PROTECTED] wrote: Hello, Presently, we are able to add additionnal info to a matrix thanks to the nice comment() and attr() functions. Maybe I miss some other functions ? Since there is a always a little remaining place on the top left when one print a matrix, I was wondering if it won't be interesting to offer the possibility to show some information here, I'm thinking on something like : attr(M, 'topleft') = 'city\prms'; M city\prms abc seattle135 vancouver 246 I don't know if it's easily feasible and even if it seems interesting enough ... so sorry if it is a silly idea. All the best Vincent __ 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
[Rd] Name clashes among packages
To handle name clashes among packages I wonder if we could have a namespace setting between exported and not-exported which is exported but you have to use :: (two dots) to access its objects. The difference between mandatory two dot and three dots in this case is that the exported objects are intended to be accessed whereas the three dot ones are not and it may be important to retain that distinction even though you have to explicitly preface both. If the package uses this intermediate form of exporting then it could be guaranteed that there are no name clashes. Perhaps it should be possible to specify this on an object by object basis within the package. This could be useful for larger projects made up of many packages. Of course one can already just have the convention that one uses two dots to access package objects but this would enforce it for certain packages and allow those package to avoid the annoying name clash warnings when loaded. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] License Conflict?
Is this a true problem? Artistic License may conflict with GPL The source code for R contains references to both the GNU General Public License 2.0 (GPL) and to the Artistic License. These two licenses include some contradictory restrictions. The Ohloh source code parser is exhaustive, and can reveal licensing requirements which the developers themselves may have overlooked or forgotten. This message is merely a warning. There may not actually be any conflict, because the two licenses may not apply to the exact same sections of code or the code in question may be available under multiple licenses. You should review the license requirements for this project carefully, especially if you are using this code for commercial purposes. The GNU Project maintains a guide to GPL compatibility at their web site. Above is at this page: http://www.ohloh.net/projects/3926/factoids/632981 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Windows: adding R/bin folder to the PATH variable
On Fri, Jul 18, 2008 at 4:18 AM, Prof Brian Ripley [EMAIL PROTECTED] wrote: On Fri, 18 Jul 2008, Gorjanc Gregor wrote: Hi! Under Windows R is installed, but its bin folder is not added to the system PATH variable. I know that this is handled properly under *nix like systems and I wonder, why this is not the default also for the MS Windows? I guess that for most users a shortcut on the desktop or anywhere else is sufficient, but there are occasions when one expects to able to lunch R from anywhere - say the Command prompt. This is the normal behaviour of Windows applications. There are several reasons, including length limits on the Windows PATH (which are version-specific) and that shells are not normally used -- most Unix shells hash the path contents so lookup is (almost) independent of the number of applications on the path. If you run a shell (e.g. the Command prompt) you can set the path for that shell, and indeed I have my system setup to use a different path in shells than used from the desktop). Finally, those Windows installers that do add to the PATH frequently fail to uninstall correctly. There are two other problems, as well: - you might want to use two different versions of R on the same computer - the directory that normally resides at c:\rtools\bin contains a find command which conflicts with the Windows find command so if you keep rtools\bin in your path it can cause other Windows scripts to fail. At any rate, note that batchfiles at http://batchfiles.googlecode.com has Rcmd.bat, R.bat, Rgui.bat, etc. that you just place anywhere in your path and they will automatically find R and rtools from the registry and MiKTeX via a heuristic and then launch the corresponding R .exe . Just place one of them or all of them anywhere in your path in which case no path changes are required to run R or to build R packages at all. They also have the advantage that if you use them you can be sure that the temporary PATH that they set up and remove on the fly gets set properly which is an advantage since, based on messages on r-help or r-devel, wrong setting of PATH is a frequent problem. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [[ vs. .subset2
In the code below test2() gives an error message: Error in .subset2(x, i, exact = exact) : attempt to select less than one element even though test(), which is nearly the same, gives the expected result. BOD is a data set that comes with R. Is this a bug? idx - 2 # returns expected result test - function(pf = parent.frame()) .subset2(BOD, pf$idx) test() # gives error message !!! test2 - function(pf = parent.frame()) BOD[[pf$idx]] test2() I tried this on Windows Vista under: R.version.string [1] R version 2.7.1 RC (2008-06-16 r45949) and R.version.string [1] R version 2.8.0 Under development (unstable) (2008-06-28 r46012) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [[ vs. .subset2
Not really. The point of this is that promises seem to be screwing up in conjunction with [[ but in light of the fact that .subset2 works it suggests that there might be a better implementation of [[. Also some insight into what is really driving this problem so one can more easily recognize it in other places would be helpful. This a simplification of an actual problem I had in a large program and it took some time to track this one down. Also, I am not entirely happy with the workarounds which are to use .subset2, as shown, or force(pf) since it seems more natural to me that it should just work out of the box. On Fri, Jul 4, 2008 at 8:42 PM, Spencer Graves [EMAIL PROTECTED] wrote: Dear Gabor: Does the following answer your question: tst - list(a=1, b=2) tst[numeric(0)] list() tst[[numeric(0)]] Error in tst[[numeric(0)]] : attempt to select less than one element Spencer Gabor Grothendieck wrote: In the code below test2() gives an error message: Error in .subset2(x, i, exact = exact) : attempt to select less than one element even though test(), which is nearly the same, gives the expected result. BOD is a data set that comes with R. Is this a bug? idx - 2 # returns expected result test - function(pf = parent.frame()) .subset2(BOD, pf$idx) test() # gives error message !!! test2 - function(pf = parent.frame()) BOD[[pf$idx]] test2() I tried this on Windows Vista under: R.version.string [1] R version 2.7.1 RC (2008-06-16 r45949) and R.version.string [1] R version 2.8.0 Under development (unstable) (2008-06-28 r46012) __ 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] get ...
If access is removed it would be important to provide
an alternative first -- removing access and only providing
an alternative some time later does not seem prudent.
On Wed, Jul 2, 2008 at 10:57 AM, Luke Tierney [EMAIL PROTECTED] wrote:
On Tue, 1 Jul 2008, Duncan Murdoch wrote:
On 30/06/2008 10:56 AM, Luke Tierney wrote:
On Sat, 28 Jun 2008, Peter Dalgaard wrote:
Gabor Grothendieck wrote:
Suppose we do this:
f - function(...) environment()
e - f(a = 1, b = 2)
ls(e, all = TRUE)
[1] ...
e$...
...
class(e$...)
[1] ...
Is there any way of getting a and b given e without
modifying f?
evalq(list(...),e)
$a
[1] 1
$b
[1] 2
I'm wondering though whether we should allow the internal DOTSXP value
of ... to escape to the user level. Might be more appropriate for
get(e,...), e$... (and as.list.environment and maybe a few other
things) to give the Error: '...' used in an incorrect context error
if the value is a DOTSXP.
On the other hand, what Gabor sees in e is what he would see inside f:
f - function(...) { ls(all=T) }
f(a=1, b=2)
[1] ...
I don't think we should distinguish between user level in .GlobalEnv and
what a user sees inside a function he writes. Stopping a user from seeing
... inside a function would break all sorts of things.
Huh??
Noone is proposing that ls or exist, for example change. ... is a
special variable that can only be used in special contexts. Just
evaluating ... gives an error; get(...) used in the same context
probably ought to as well. What we do now is clearly wrong: return an
undocumented object that can't be used for anyting useful (and
reflects an internal implementation we might want to change). We need
to either prevent the R_DOTSXP values from leaking out or document
them , define [ methods and figure out what they should do, etc.
Preventing them from leaking out is the sensible thing to do.
luke
Duncan Murdoch
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] get ...
Suppose we do this: f - function(...) environment() e - f(a = 1, b = 2) ls(e, all = TRUE) [1] ... e$... ... class(e$...) [1] ... Is there any way of getting a and b given e without modifying f? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Posting Guide - help.request() function?
))
change - readline(paste(Would you like to change your subject line:\n,
subject, \nto something more meaningful? (y/n)
))
if (yes(change))
subject - readline(Enter subject: \n)
methods - c(mailx, gnudoit, none, ess)
method - if (is.null(method))
none
else methods[pmatch(method, methods)]
body - paste(\\nWrite your query here, using your example code to
illustrate,
\\nEnd with your name and affiliation\\n\\n\\n\\n,
--please do not edit the information below--\\n\\n,
Version:\\n , paste(names(R.version), R.version, sep =
= ,
collapse = \\n ), if
(nzchar(Sys.getenv(R_GUI_APP_VERSION)))
paste(\\n\\nGUI:\\n R-GUI ,
Sys.getenv(R_GUI_APP_VERSION),
(, Sys.getenv(R_GUI_APP_REVISION), ),
sep = )
else , \\n\\n, Locale:\\n,
Sys.getlocale(), \\n\\n,
Search Path:\\n , paste(search(), collapse = , ),
\\n, sep = , collapse = )
if (method == gnudoit) {
cmd - paste(gnudoit -q ', (mail nil \, address,
\), (insert \, body, \), (search-backward
\Subject:\),
(end-of-line)', sep = )
system(cmd)
}
else if (method == none) {
disclaimer - paste(# Your mailer is set to \none\ (default on
Windows),\n,
# hence we cannot send the help request directly from R.\n,
# Please copy the help request (after finishing it) to\n,
# your favorite email program and send it to\n#\n,
# , address, \n#\n,
##\n,
\n\n, sep = )
cat(disclaimer, file = file)
body - gsub(n, \n, body)
cat(body, file = file, append = TRUE)
cat(Please edit the help request.\n)
system(paste(getOption(editor), file))
cat(The unsent help request can be found in file, file,
\n)
}
else if (method == mailx) {
if (missing(subject))
stop('subject' missing)
body - gsub(n, \n, body)
cat(body, file = file, append = FALSE)
cat(Please edit the help request.\n)
system(paste(getOption(editor), file))
if (is.character(ccaddress) nzchar(ccaddress)) {
cmdargs - paste(-s ', subject, ' -c, ccaddress,
address, , file, 2/dev/null)
}
else cmdargs - paste(-s ', subject, ', address,
, file, 2/dev/null)
status - 1
cat(Submit the help request? )
answer - readline()
answer - grep(y, answer, ignore.case = TRUE)
if (length(answer) 0) {
cat(Sending email ...\n)
status - system(paste(mailx, cmdargs))
if (status 0)
status - system(paste(Mail, cmdargs))
if (status 0)
status - system(paste(/usr/ucb/mail, cmdargs))
if (status == 0)
unlink(file)
else {
cat(Sending email failed!\n)
cat(The unsent help request can be found in file,
file, \n)
}
}
else cat(The unsent help request can be found in file,
file, \n)
}
else if (method == ess) {
body - gsub(n, \n, body)
cat(body)
}
}
---
Gabor Grothendieck wrote:
Here is another update. I have added the following:
- info about using a fresh R session. (In that case ls() output is less
essential; however, the developers of sessionInfo() might consider
adding that as a default or as an option.)
- questioner should consider use of functions.
- for data use dump(x, file = ) to reproducibly display data or use
builtin datasets listed by data()
- minimal versions of slow code should be presented in cases where
questioner is looking for faster code.
- we still need to add links to illustrative sample questions in r-help
The following were not added for the reason cited:
- guide is not just for questioners. Important to distinguish roles
of questioner, responder and reader.
- what is to be provided ought to be given a name to make it easier
to refer to. An unlabelled set of points is too vague. Test
framework seems appropriately descriptive. By giving it a name
one can request that a questioner provide a test framework as
defined in the posting guide summary.
- self contained is not implied by reproducible. Reproducible
only means that info is available somewhere -- not that its all
available right in the questioner's post and all in a manner that
is readily accessible.
- focus should be on making data minimal. Don't like attachments
since responder must save them and read them
Re: [Rd] Posting Guide
Here is a second version of the summary. Its been rearranged to place most important info at top. Also shortened it a bit. It still needs links to example posts, as suggested. Anyone? Summary Surprisingly, the main problem for responders is not to answer the posted questions but to quickly figure out what the question is, reproduce it in their own R session and test their answer. Test Framework. To faciliate that provide a test framework of: (1) reproducible self-contained minimal code and data. That means responders can copy it from the questioner's post and paste it into their session to see the same output without having to enter even one R command. NB. dput(mydata) produces mydata in reproducible form. (2) comments/explanations of what the code is intended to produce and (3) versions of all software used, e.g. sessionInfo(). Without self-contained reproducible code the responder must not only understand the question but must also create a test framework and that typically takes more time than answering the question! Its not fair to ask the responder to provide all that on top of answering the question. Do NOT assume the problem is so simple that it is not necessary. Effort. The effort taken to reduce the problem to its essentials and produce a test framework often solves the problem avoiding the need for a post in the first place. It at the least shows that the questioner tried to solve it themself. Subscribers. The questioner should ensure that the thread is complete and that it has an appropriate Subject. The purpose of the post is not only to help the questioner but also the other list subscribers and those later searching the archives. On Fri, Jun 6, 2008 at 1:30 PM, Gabor Grothendieck [EMAIL PROTECTED] wrote: People read the posting guide yet they are still unable to create an acceptable post. e.g. https://stat.ethz.ch/pipermail/r-help/2008-June/164092.html I think the problem is that the guide is not clear or concise enough. I suggest we add a summary at the beginning which gets to the heart of what a poster is expected to provide: Summary To maximize your change of getting a response when posting provide (1) commented, (2) minimal, (3) self-contained and (4) reproducible code. (This one line summary also appears at the end of each message to r-help.) Self-contained and reproducible mean that a responder can copy the questioner's code to the clipboard, paste it into their R session and see the same problem you as the questioner see. Note that dput(mydata) will display mydata in a reproducible way. Self-contained and reproducible are needed because: (1) Self-Effort. It shows that the questioner tried to solve the problem by themself first. (2) Test framework. Often the responder needs to play with the code a bit in order to respond or at least to give the best answer. They can't do that without a test framework that includes the data and the code to run it and its not fair to ask them to not only answer the question but also to come up with test data and to complete incomplete code. (3) Archives. Questions and answers go into the archives so they are not only for the benefit of of the questioner but also for the benefit of all future searchers of the archive. That means that its not finished if you have solved the problem for yourself. You still need to ensure that the thread has a complete solution. (For that reason its also important to give a meaningful subject to each post.) Commented and minimal also reduce the time it takes to understand the problem. Don't just dump your code as is into the message since you are just wasting your own time. Its not likely anyone will answer a message if the questioner has not taken the time to reduce it to its essential elements. Surprisingly, quite often understanding what the problem is takes the responder most of the time -- not solving the problem. Once the question is actually understood its often quite fast to answer. Thus in addition to posting it in a minimal form, comment on it sufficiently so that the responder knows what the code does and is intended to produce. It may be obvious to the questioner who is embroiled in the problem but that does not mean its obvious to others. Introduction rest of posting guide ... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Posting Guide
Here is another update. I have added the following: - info about using a fresh R session. (In that case ls() output is less essential; however, the developers of sessionInfo() might consider adding that as a default or as an option.) - questioner should consider use of functions. - for data use dump(x, file = ) to reproducibly display data or use builtin datasets listed by data() - minimal versions of slow code should be presented in cases where questioner is looking for faster code. - we still need to add links to illustrative sample questions in r-help The following were not added for the reason cited: - guide is not just for questioners. Important to distinguish roles of questioner, responder and reader. - what is to be provided ought to be given a name to make it easier to refer to. An unlabelled set of points is too vague. Test framework seems appropriately descriptive. By giving it a name one can request that a questioner provide a test framework as defined in the posting guide summary. - self contained is not implied by reproducible. Reproducible only means that info is available somewhere -- not that its all available right in the questioner's post and all in a manner that is readily accessible. - focus should be on making data minimal. Don't like attachments since responder must save them and read them in. It encourages use of large rather than minimal data sets. Summary Surprisingly, the main problem for responders is not to answer the question but to quickly figure out what the question is, reproduce it in their own R session and test their answer. Test Framework. To faciliate this provide a test framework of: (1) minimal reproducible self-contained commented code and data that has been run in a fresh R session. That means code and data have been cut down as far as possible to the essentials needed to illustrate the problem and were run are just after starting up R. Also it means that its possible for responders to just copy the code and data section from the questioner's post to the clipboard and paste it into their session to see the same output without having to enter even one R command. In some cases there may be an advantage to present the code as a function and in the case of needing a speedup be sure to post a minimal version of the slow code. Use builtin data sets such as those listed by data() to illustrate problem or reduce your data to a minimum and present it reproducibly by using: dump(mydata, file = ) (2) comments/explanation of what the code is intended to produce -- Don't assume its obvious! (3) versions of all software used, e.g. sessionInfo(), or R.version.string; packageDescription(zoo)$Version Without self-contained reproducible code the responder must not only understand the question but must also create a test framework and that typically takes more time than answering the question! Its not fair to ask the responder to provide all that on top of answering the question. Do NOT assume the problem is so simple that it is not necessary. Effort. The effort taken to reduce the problem to its essentials and produce a test framework often solves the problem avoiding the need for a post in the first place. It at the least shows that the questioner tried to solve it themself. Subscribers. The questioner should ensure that the thread is complete and that it has an appropriate Subject. The purpose of the post is not only to help the questioner but also the other list subscribers and those later searching the archives. On Sat, Jun 7, 2008 at 9:38 AM, Gabor Grothendieck [EMAIL PROTECTED] wrote: Here is a second version of the summary. Its been rearranged to place most important info at top. Also shortened it a bit. It still needs links to example posts, as suggested. Anyone? Summary Surprisingly, the main problem for responders is not to answer the posted questions but to quickly figure out what the question is, reproduce it in their own R session and test their answer. Test Framework. To faciliate that provide a test framework of: (1) reproducible self-contained minimal code and data. That means responders can copy it from the questioner's post and paste it into their session to see the same output without having to enter even one R command. NB. dput(mydata) produces mydata in reproducible form. (2) comments/explanations of what the code is intended to produce and (3) versions of all software used, e.g. sessionInfo(). Without self-contained reproducible code the responder must not only understand the question but must also create a test framework and that typically takes more time than answering the question! Its not fair to ask the responder to provide all that on top of answering the question. Do NOT assume the problem is so simple
Re: [Rd] savePlot() no longer automatically adds an extension to the filename.
Not sure if this is sufficient but note that if you leave the filename
off entirely then the extension does default to the type.
savePlot() # wmf
savePlot(type = jpg)
args(savePlot)
function (filename = paste(Rplot, type, sep = .), type = c(wmf,
emf, png, jpg, jpeg, bmp, tif, tiff, ps,
eps, pdf), device = dev.cur(), restoreConsole = TRUE)
https://svn.r-project.org/R/trunk/src/library/grDevices/R/windows/windows.R
On Tue, Jun 3, 2008 at 11:22 AM, S Ellison [EMAIL PROTECTED] wrote:
Plaintive squeak: Why the change?
Some OS's and desktops use the extension, so forgetting it causes
trouble. The new default filename keeps a filetype (as before) but the
user now has to type a filetype twice (once as the type, once as
extension) to get the same effect fo rtheir own filenames. And the
extension isn't then checked for consistency with valid file types, so
it can be mistyped and saved with no warning. Hard to see the advantage
of doing away with it...
Suggestion: Revert to the previous default (extension as type) and
include an 'extension' in the parameter list so that folk who don't want
it can change it and folk who did want it get it automatically.
The code would then look something like
savePlot-function (filename = Rplot,
type = c(wmf, emf, png, jpg, jpeg, bmp, tif,
tiff, ps, eps, pdf),
device = dev.cur(),
restoreConsole = TRUE,
extension) #Added extension
{
type - match.arg(type)
if(missing(extension))
extension - type ##added
devlist - dev.list()
devcur - match(device, devlist, NA)
if (is.na(devcur))
stop(no such device)
devname - names(devlist)[devcur]
if (devname != windows)
stop(can only copy from 'windows' devices)
if (filename == clipboard type == wmf)
filename -
else
fullname - paste(filename, extension,
sep=ifelse(extension==,,.) ) ##added
invisible(.External(CsavePlot, device, fullname, type,
restoreConsole))##Modded
}
Steve E
PS Yes, I took a while to upgrade from 2.6.x. Otherwise I'd have
squeaked the day I upgraded - like I just did - 'cos I use savePlot a
LOT.
***
This email and any attachments are confidential. Any use...{{dropped:8}}
__
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] savePlot() no longer automatically adds an extension to the filename.
On Tue, Jun 3, 2008 at 10:36 PM, Simon Urbanek [EMAIL PROTECTED] wrote: On Jun 3, 2008, at 8:40 PM, Duncan Murdoch wrote: On 03/06/2008 2:35 PM, Mike Prager wrote: S Ellison [EMAIL PROTECTED] wrote: Plaintive squeak: Why the change? Some OS's and desktops use the extension, so forgetting it causes trouble. The new default filename keeps a filetype (as before) but the user now has to type a filetype twice (once as the type, once as extension) to get the same effect fo rtheir own filenames. And the extension isn't then checked for consistency with valid file types, so it can be mistyped and saved with no warning. Hard to see the advantage of doing away with it... Just for the record. . . This change broke a *lot* of my code, including code used by others. Windows depends on file extensions. Fortunately, fixes using getRversion are not too difficult. Then you'll be happy to hear that Steve put together a patch and it's already committed, so it should make it into 2.7.1. The patch adds the extension if there's no dot in the name, leaves the filename as-is if it sees one. So this should be compatible with the majority of uses, only messing up cases where people really don't want an extension (now they'll have to add a dot at the end of their filename), or where they want an automatic one, but have another dot in the name. AFAICS the savePlot() behavior is now (as of r45830) inconsistent across platforms due to the patch (r458229). The inconsistency is IMHO a bad thing - you shouldn't expect the same function to behave differently across platforms. I'd strongly recommend against this change for several reasons: it changes the behavior of the function between 2.7.0 and 2.7.1, so that now you have to special-case three different versions (pre 2.7.0, 2.7.0 and 2.7.1), there is now no way to specify a file without a dot (which is quite common in non-Windows world) and the behavior is incompatible with other similar functions. I think the change of behavior in 2.7.0 was deliberate and in favor of consistency, because a filename specification should not be randomly mangled by the function (I have made that mistake myself before, so I know the pitfalls ;)). Extension is part of the filename, it's not a separate concept (also note that .foo is a valid filename that doesn't have an extension). The argument about typos is moot since you can always define functions like saveFoo - function(prefix) savePlot(filename = paste(prefix, foo, sep=.), type=foo) At any rate I don't see how this can realistically be part of 2.7.1 since it's not a bugfix and it changes the meaning of a function parameter. (And I usually don't mind disguising small features as bugfixes ;P) Whether the change in 2.7.0 could be done differently (e.g. using another parameter for a full file name) is a different story, but I suspect that it should have been discussed before the 2.7.0 release... One way to fix this so that the filename is a complete name is to derive the default type from the filename rather than the default filename from the type. That is if type is not specified and the last four characters of the file name are .wmf, .jpg, ..., etc. then the type would be set to that. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] scoping problem when calling lm(precomputed formula, weights) from function (PR#11540)
Try replacing the last line in g with:
lmout - do.call(lm, list(Formula, data = data, weights = w))
coef(lmout)
or replace w with environment()$w thereby explicitly telling it where to look.
On Fri, May 30, 2008 at 11:40 AM, [EMAIL PROTECTED] wrote:
I've run into a scoping problem in R.
I'm calling a function that
* creates a formula
* calculates a weight vector
* calls lm with that formula and weights
This fails.
Here's a simplified reproduce example:
# f works, g doesn't, h is a workaround
rm(w)
data - data.frame(y=runif(20), x=runif(20), z=runif(20))
f - function(k){
w - data$z^k
coef(lm(y~x, data = data, weights = w))
}
g - function(k){
w - data$z^k
Formula - parse(text=y~x)[[1]]
coef(lm(Formula, data = data, weights = w))
}
h - function(k){
w - data$z^k
Formula - parse(text=y~x)[[1]]
# Following line fails due to scoping bug. Use workaround.
# coef(lm(Formula, data = data, weights = w))
Call - paste(coef(lm(, deparse(Formula), , data=data, weights=w)))
eval(parse(text=Call)[[1]])
}
f(2)
(Intercept) x
0.7452512 -0.3413998
g(2)
Error in eval(expr, envir, enclos) : object w not found
traceback()
9: eval(expr, envir, enclos)
8: eval(extras, data, env)
7: model.frame.default(formula = Formula, data = data, weights = w,
drop.unused.levels = TRUE)
6: model.frame(formula = Formula, data = data, weights = w,
drop.unused.levels = TRUE)
5: eval(expr, envir, enclos)
4: eval(mf, parent.frame())
3: lm(Formula, data = data, weights = w)
2: coef(lm(Formula, data = data, weights = w))
1: g(2)
h(2)
(Intercept) x
0.7452512 -0.3413998
--please do not edit the information below--
Version:
platform = i486-pc-linux-gnu
arch = i486
os = linux-gnu
system = i486, linux-gnu
status =
major = 2
minor = 7.0
year = 2008
month = 04
day = 22
svn rev = 45424
language = R
version.string = R version 2.7.0 (2008-04-22)
Locale:
LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:showStructure, package:Rcode,
package:splus2R, package:methods, Autoloads, package:base
__
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] Small request.
As of a few weeks ago, rtools does store the current version in the registry but its only a gross figure such as 2.7 or 2.8 and that would not be enough to identify the build. On Tue, May 27, 2008 at 4:45 PM, [EMAIL PROTECTED] wrote: This is (hopefully) a small request. I routinely build (and test) both R versions from sources on my system (WinXP). I would like to be sure that I have the current version of Rtools. I always go to Robert Murdoch's site Building R for Windows and check the latest news. Everything I need is explained there, except I never know if I have the most recent version of Rtools.exe. I see Rtools28.exe but my understanding is that this file is refreshed quite frequently. Is so, would it be possible to include some version numbering scheme in its name? Perhaps a build date stamp can be included instead? Thanks in advance, Andy __ Andy Jaworski 518-1-01 Process Laboratory 3M Corporate Research Laboratory - E-mail: [EMAIL PROTECTED] Tel: (651) 733-6092 Fax: (651) 736-3122 __ 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] (PR#11484) On WinXP, R CMD config needs sh (and breaks without it)
Note that if you place Rcmd.bat andor R.bat from http://batchfiles.googlecode.com anywhere in your path and install the latest rtools from http://www.murdoch-sutherland.com/Rtools/ then you don't have to change your PATH. On Mon, May 19, 2008 at 5:40 AM, [EMAIL PROTECTED] wrote: 2008/5/19 Prof Brian Ripley [EMAIL PROTECTED]: Where is the bug here? It also does on a Unix-alike. Then R CMD config --help could at least spit out an error stating what should be installed (rather than die with an execution error straight from the DOS). Setting an sh in the %Path% (sh coming from cygwin) does not seem to lead to something working under winXP (various error messages). Anything involving R CMD potentially needs the Rtools set in the path. I guess that I have been lucky with the potential aspect of the requirements so far. Is there a documentation of what is needed by the respective R CMD flavors ? R CMD config is primarily intended to be used in configure scripts in packages. On Sun, 18 May 2008, [EMAIL PROTECTED] wrote: Full_Name: Laurent Gautier Version: R-2.7.0patched (r45712) OS: WinXP Submission from: (NULL) (90.15.141.247) On a WinXP box (that does not has sh in the %Path%, R CMD config appears to break: C:\R CMD config 'sh' is not recognized as an internal or external command, operable program or batch file. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in building library - R CMD build mypkg.
What does your DESCRIPTION file look like? Have you edited it to specify the required information? Read the Writing R Extensions manual. On Mon, May 19, 2008 at 4:11 PM, Ajay DAS [EMAIL PROTECTED] wrote: - Forwarded by Ajay DAS/US/BMNA01 on 05/19/2008 03:11 PM - Ajay DAS To: [EMAIL PROTECTED] 05/19/2008 01:00 cc: PM Subject: Error in building library - R CMD build mypkg. Hi, I am getting an error when I am trying to build a library in R for windows . I am using R 2.7.0 in windows. I am following the instructions listed in the R Help for package creation. require(stats) ## two functions and two data sets : f - function(x,y) x+y g - function(x,y) x-y d - data.frame(a=1, b=2) e - rnorm(1000) package.skeleton(list=c(f,g,d,e), name=mypkg) Then in the command prompt I executed the following command: R CMD build mypkg I am getting the following error : * checking for file 'mypkg/DESCRIPTION' ... OK * preparing 'mypkg': * checking DESCRIPTION meta-information ... ERROR During startup - Warning messages: 1: In library(package, lib.loc = lib.loc, character.only = TRUE, logical.return = TRUE, : ' there is no package called 'NULL in options(defaultPackages) was not found What is it that I am not doing right ? Thanks, Ajay. - AVIS : Ce courrier et ses pieces jointes sont destines a leur seul destinataire et peuvent contenir des informations confidentielles appartenant a bioMerieux. Si vous n'etes pas destinataire, vous etes informe que toute lecture, divulgation, ou reproduction de ce message et des pieces jointes est strictement interdite. Si vous avez recu ce message par erreur merci d'en prevenir l'expediteur et de le detruire, ainsi que ses pieces jointes. NOTICE: This message and attachments are intended only for the use of their addressee and may contain confidential information belonging to bioMerieux. If you are not the intended recipient, you are hereby notified that any reading, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this message in error, please notify the original sender immediately and delete this message, along with any attachments. __ 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] apply and monthly time series (PR#11352)
See ?apply If X is not an array but has a dimension attribute, apply attempts to coerce it to an array via as.matrix if it is two-dimensional (e.g., data frames) or via as.array. So for example, try this noting that time is 1, 2, 3, ... apply(monthly, 2, time) Try lm(monthly ~ time(monthly)) On Wed, Apr 30, 2008 at 9:00 AM, [EMAIL PROTECTED] wrote: Full_Name: Stephen McIntyre Version: 2.7 OS: Windows XP Submission from: (NULL) (99.231.2.44) When I use the apply function to calculate a trend for a matrix of monthly time series, it yields a different answer than when the trend is calculated one at a time (by a factor of 12) rather than the identical answer as it should. Here's an example: download.file(http://www.climateaudit.org/data/models/monthly.tab,temp.dat,mode=wb;) load(temp.dat) trend= function(x) lm(x~c(time(x)))$coef[2] b= apply(monthly,2,trend) a= c(trend(monthly[,1]),trend(monthly[,2]),trend(monthly[,3])) a/b #12 12 12 __ 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] build packages with vignettes in Windows
You can use the Windows batch PATH command. On Wed, Apr 30, 2008 at 11:56 AM, Michael [EMAIL PROTECTED] wrote: On 29 Apr 2008, Duncan Murdoch wrote: Right, you don't need to set the system path for everything, but you do need to set it in CMD (or other shell) before running Rcmd. For Win 2K/XP/Vista, the system path can be set (through the GUI interface, not sure how to do it with scripts) without restarting, for new CMD processes started afterwards. Michael __ 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] build packages with vignettes in Windows
The use of the UNIX find command on Windows makes installation very troublesome and fragile. I wonder if you could include a find2 or somesuch with the tools and change the scripts to use that getting rid of find or use just use the Windows find command in the scripts. Or some other solution so that one does not have to have a non-Windows find on the PATH. If you don't have the find in Rtools first in your path then you have problems like the one below and if you do have it first then it throws off the scripts from other software. On Tue, Apr 29, 2008 at 2:29 PM, Duncan Murdoch [EMAIL PROTECTED] wrote: On 29/04/2008 12:54 PM, Michael wrote: I've been trying to build a Windows binary of a package of mine without success. It seems that the files under inst/doc throw the script off. I am using the command 'Rcmd INSTALL --build'. -- Making package genepi adding build stamp to DESCRIPTION installing NAMESPACE file and metadata installing R files installing inst files FIND: Parameter format not correct That looks as though you don't have the tools installed correctly, you have some other find earlier on your path. Duncan Murdoch make[2]: *** [C:/Library/R/genepi/inst] Error 2 make[1]: *** [all] Error 2 make: *** [pkg-genepi] Error 2 *** Installation of genepi failed *** I also tried a couple of packages downloaded from CRAN. Those without inst/doc directory worked fine and those who do have it didn't. I'm using a fresh install of R-2.7.0 and Rtools-2.7. Any clue of what was wrong with my setup? Thanks, Michael __ 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build packages with vignettes in Windows
On Tue, Apr 29, 2008 at 4:00 PM, Duncan Murdoch [EMAIL PROTECTED] wrote: On 29/04/2008 2:51 PM, Gabor Grothendieck wrote: The use of the UNIX find command on Windows makes installation very troublesome and fragile. I wonder if you could include a find2 or somesuch with the tools and change the scripts to use that getting rid of find or use just use the Windows find command in the scripts. Or some other solution so that one does not have to have a non-Windows find on the PATH. Find isn't unique: there are lots of versions of make, and grep, and tar that don't work, either. We've adopted a simple solution, and it works: It only works if you are very careful and actually it doesn't work because it does not preserve Windows functionality for other programs. when you're using the R tools, put them first on the path. That's not comparable because find comes with Windows whereas those other programs you mention are addons. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] graphics::Axis loosing S3/S4 class attributes of 'x' in 2.7.0 RC
This also affects Axis.yearmon and Axis.yearqtr in the
zoo package which worked in R 2.6.2 and now don't work
properly. It seems more logical to define plot.whatever
to handle the object in question, i.e. we do define plot.zoo,
whereas only the Axis method ought to be required for the
X and Y coordinate axes.
On Tue, Apr 22, 2008 at 8:53 AM, Sklyar, Oleg (MI London)
[EMAIL PROTECTED] wrote:
Thanks Duncan,
this might explain why Axis.MyClass is never called.
However, it is really not only illogical to define plot.MyClass instead
of Axis.MyClass if the only thing I want is formatting of the axis, but
it is also broken in R 2.7.0 and here is why.
Let's forget about MyClass and take POSIXct, for which plot.POSIXct and
Axis.POSIXct are defined in graphics. First question would be, why
define Axis.POSIXct if it is logical to just define plot.POSIXct. But
then, try the following example in 2.7.0 and 2.6.2:
x = Sys.time() + runif(100,1,7200) ## time over two hours, POSIXct
plot(x,1:100)
plot(1:100,x)
The first plot will be correctly formatted in both R versions while the
second one will be *incorrectly* formatted in 2.7.0 (funny enough
xy.coords returns as.double in both, so that might not be the reason for
the problem).
What happens is that plot.POSIXct is called in the former case and thus
we get the correct formatting. However, plot.default is called in the
latter case. In 2.6.2 Axis.POSIXct was the reason why y axis was
correctly formatted here. In 2.7.0 Axis.default is called instead
because class of x is reset.
Now this perfectly indicates why it is logical to have Axis.MyClass
defined (as this two-liner would be called in all possible situations
producing correct axes independently where it is called from) and not
plot.MyClass (which would actually not cover the situation of only the
second argument being MyClass). Surely I can define S4 with multiple
signatures, but logically I would define Axis.MyClass.
Omitting axes completely is not a good options to enforce on users for
default plots, is it?
Dr Oleg Sklyar
Technology Group
Man Investments Ltd
+44 (0)20 7144 3803
[EMAIL PROTECTED]
-Original Message-
From: Duncan Murdoch [mailto:[EMAIL PROTECTED]
Sent: 22 April 2008 13:01
To: Sklyar, Oleg (MI London)
Cc: R-devel@r-project.org
Subject: Re: [Rd] graphics::Axis loosing S3/S4 class
attributes of 'x' in 2.7.0 RC
On 22/04/2008 7:25 AM, Sklyar, Oleg (MI London) wrote:
Following my previous post on S3 method despatch, I put
debug messages
in the code of Axis, Axis.default and plot.default in
graphics/R/axis.R and graphics/R/plot.R to print the class of x, at
and y on plot. After recompiling R, what I see is that x *lost* its
class attribute (at least for classes not known to 'graphics') in
Axis, called directly from plot.default and this could be
the reason
why R did not despatch on Axis.MyClass from my previous post. This
happens for both S3 and S4 classes as in the code below!
Funny enough,
even integer was reset to numeric in Axis...
If you look at plot.default, you'll see it passes x and y
through xy.coords to get coordinates. That function ends with
return(list(x=as.double(x), y=as.double(y), xlab=xlab, ylab=ylab))
so that's where classes get removed. If you don't want this
to happen, shouldn't you be defining plot.MyClass, or calling
the default with axes=F, and then calling Axis on your object
yourself?
Is this really an intended behaviour? It looks very wrong to me!
This is documented: ?plot.default tells you to look at
?xy.coords for details of how x and y are handled, and
xy.coords says In any other case, the 'x' argument is
coerced to a vector and
returned as *y* component where the resulting 'x' is just the
index vector '1:n'. In this case, the resulting 'xlab'
component
is set to 'Index'.
Duncan Murdoch
Thanks,
Oleg
*** R version 2.7.0 RC (2008-04-20 r45403)
[/research/osklyar/R-devel]
***
Axis
function (x = NULL, at = NULL, ..., side, labels = NULL) {
cat(In Axis() class(x)=, class(x), ; class(at)=, class(at),
\n, sep = )
if (!is.null(x))
UseMethod(Axis, x)
else if (!is.null(at))
UseMethod(Axis, at)
else axis(side = side, at = at, labels = labels, ...) }
environment: namespace:graphics
graphics:::Axis.default
function (x = NULL, at = NULL, ..., side, labels = NULL) {
cat(In Axis.default() class(x)=, class(x), ; class(at)=,
class(at), \n, sep = )
if (is.null(at) !is.null(x))
at = pretty(x)
axis(side = side, at = at, labels = labels, ...) }
environment: namespace:graphics
setClass(MyClass, representation(smth=character),
contains=numeric)
[1] MyClass
a = new(MyClass, runif(10))
a
An object of class MyClass
[1] 0.773237167 0.548630205 0.987956687 0.212667925
Re: [Rd] graphics::Axis loosing S3/S4 class attributes of 'x' in 2.7.0 RC
On Tue, Apr 22, 2008 at 9:24 AM, Duncan Murdoch [EMAIL PROTECTED] wrote: On 4/22/2008 9:08 AM, Sklyar, Oleg (MI London) wrote: Duncan, looking further, what has changed from 2.6.2 into 2.7.0 are the following two lines in plot.default, which I think were logical before and are not really logical now: I believe it is behaving as documented now, so the behaviour is logical, even if it may not be convenient. In your example x = Sys.time() + runif(100,1,7200) ## time over two hours, POSIXct plot(x, 1:100) plot(1:100, x) the 1st works in 2.6.2 and 2.7.0 and the second only works in 2.6.2. But the change below was designed to fix the case plot(x) In what sense is plot(x) fixed? When I try it I get numbers on both axes -- times on neither. Clearly Axis should not behave in a way which effectively makes it useless and breaks reasonable old code. R.version.string [1] R version 2.7.0 RC (2008-04-17 r45367) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] graphics::Axis loosing S3/S4 class attributes of 'x' in 2.7.0 RC
Its not clear to me at this point what and where the proposed
or already made change is but here
is a test that should produce a year/month style rather than
numeric style X axis:
library(zoo)
z - zoo(1:12, as.yearmon(2000 + 1:12/12))
plot(z)
On Tue, Apr 22, 2008 at 1:18 PM, Duncan Murdoch [EMAIL PROTECTED] wrote:
There seem to be nonlinearities in the time-space continuum, so this
message arrived several hours after Martin's, even though both have the
same timestamp. Please test his, and see if you can break it. I'd
guess not, it looks simple enough, but not too simple.
And for the future:
Please test the alpha/beta/RC releases! The change we're talking about
came fairly late in the process, but it was there for the last couple of
weeks. It would be easier for everyone if it had been corrected before
release, rather than after. It was announced on the RSS list, here:
http://developer.r-project.org/blosxom.cgi/R-2-7-branch/NEWS/2008/04/08#n2008-04-08
so it would really have helped if people who rely on special axis
handling by Axis had tested the change after they'd seen that notice.
On 4/22/2008 10:26 AM, Sklyar, Oleg (MI London) wrote:
Ok, so what's wrong with the following fix for plot(x)
The main thing that's wrong with it is that you don't explain what the
changes are. I can't believe that the error is specific to the POSIXct
class, so it doesn't make sense that changes there would fix it in general.
Duncan Murdoch
that would
actually fix what needs to be fixed instead of changing plot.default?
Fix means reverting plot.default in 2.7.0 to what it was (if testing in
2.7.0, copy and paste the OLD plot.default into the .GlobalEnv):
plot.POSIXct - function(x, y, xlab = , ...) {
if (!missing(y)) {
side = 1
plotDef - function(x, y, xaxt, xlab, ...) plot.default(x, y,
xaxt=n, xlab=xlab, ...)
plotDef(x, y, xlab=xlab, ...)
} else {
side = 2
plotDef - function(x, y, yaxt, xlab, ...) plot.default(x, y,
yaxt=n, xlab=xlab, ...)
plotDef(seq_along(x), x, xlab=xlab, ...)
}
## trick to remove arguments intended for title() or plot.default()
axisInt - function(x, type, main, sub, xlab, ylab, col, lty, lwd,
xlim, ylim, bg, pch, log, asp, axes, frame.plot,
...)
axis.POSIXct(side, x, ...)
dots - list(...)
axes - if(axes %in% names(dots)) dots$axes else TRUE
xaxt - if(xaxt %in% names(dots)) dots$xaxt else par(xaxt)
if(axes xaxt != n) axisInt(x, ...)
}
plot.POSIXlt - function(x, y, xlab = , ...) {
if (missing(y)) plot.POSIXct(as.POSIXct(x), xlab=xlab, ...)
else plot.POSIXct(as.POSIXct(x), y=y, xlab=xlab, ...)
}
And try with:
x = Sys.time() + runif(100,1,7200)
plot(x)
plot(x,1:100)
plot(1:100,x)
plot(as.POSIXlt(x))
plot(as.POSIXlt(x),1:100)
plot(1:100,as.POSIXlt(x))
Dr Oleg Sklyar
Technology Group
Man Investments Ltd
+44 (0)20 7144 3803
[EMAIL PROTECTED]
-Original Message-
From: Duncan Murdoch [mailto:[EMAIL PROTECTED]
Sent: 22 April 2008 14:24
To: Sklyar, Oleg (MI London)
Cc: R-devel@r-project.org
Subject: Re: [Rd] graphics::Axis loosing S3/S4 class
attributes of 'x' in 2.7.0 RC
On 4/22/2008 9:08 AM, Sklyar, Oleg (MI London) wrote:
Duncan,
looking further, what has changed from 2.6.2 into 2.7.0 are the
following two lines in plot.default, which I think were
logical before
and are not really logical now:
I believe it is behaving as documented now, so the behaviour
is logical, even if it may not be convenient. In your example
x = Sys.time() + runif(100,1,7200) ## time over two hours,
POSIXct plot(x, 1:100) plot(1:100, x)
the 1st works in 2.6.2 and 2.7.0 and the second only works in 2.6.2.
But the change below was designed to fix the case
plot(x)
which works in 2.7.0 and *not* in 2.6.2, so reverting the
change is not the way to address this.
Duncan Murdoch
plot.R: plot.default (2.6.2):
if (axes) {
localAxis(x, side=1, ...)
localAxis(y, side=2, ...)
}
plot.R: plot.default (2.7.0):
...
if (axes) {
localAxis(xy$x, side=1, ...)
localAxis(xy$y, side=2, ...)
}
The fact that xy.coords is called does not really matter.
Dr Oleg Sklyar
Technology Group
Man Investments Ltd
+44 (0)20 7144 3803
[EMAIL PROTECTED]
-Original Message-
From: Duncan Murdoch [mailto:[EMAIL PROTECTED]
Sent: 22 April 2008 13:01
To: Sklyar, Oleg (MI London)
Cc: R-devel@r-project.org
Subject: Re: [Rd] graphics::Axis loosing S3/S4 class attributes of
'x' in 2.7.0 RC
On 22/04/2008 7:25 AM, Sklyar, Oleg (MI London) wrote:
Following my previous post on S3 method despatch, I put
debug messages
in the code of Axis, Axis.default and plot.default in
graphics/R/axis.R and graphics/R/plot.R to print the
class
Re: [Rd] plot(x) in 2.7.0 (with y=NULL) proposed code correction
On Tue, Apr 22, 2008 at 1:45 PM, Duncan Murdoch [EMAIL PROTECTED] wrote: defined for POSIX and Date classes only. zoo defines Axis methods for the yearmon and yearqtr classes and potentially other time/date classes will need Axis methods. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
