Re: [Rd] graphics documentation omission (PR#9149)
Please DO try not to file multiple reports on a single subject: this has
been filed under PR#9148 and PR#9149 already, both started by RMH.
It is important to be aware of the difference between `argument' and
`parameter'. 'asp' is an argument, whereas ?par describes parameters (see
its title).
This report seems to stem from missing that distinction, which is crucial
(e.g. 'bg' is a graphical parameter, but also an argument name for
some functions with a different meaning). (This is described under ?par.)
plot.Rd should say that '...' can contain arguments to be passed to
methods, many of which accept graphical parameters. I've altered it to do
so, and added an alias to 'asp' in plot.window, so ?asp and
help.search("asp") both get to plot.window.
On Tue, 15 Aug 2006, [EMAIL PROTECTED] wrote:
> On Tue, 2006-08-15 at 22:13 +0200, [EMAIL PROTECTED] wrote:
> > Thanks, Marc
>
> Happy to help Rich.
>
> > Neither plot.window or plot.default are natural places for me to look for
> > argument names. par and plot are, for me, the natural places. I realize
> > that asp is not a par argument. Nonetheless, par is still the first place
> > to look for arguments that I would use in the ... position of any plot
> > function.
> > It would be easy to make a case that asp is the same type of argument as mar
> > or fin, thus it would make sense for it to be added to par.
It is an argument, not a parameter, as in
> par(asp=1)
Warning message:
"asp" is not a graphical parameter
Unlike 'mar' and 'fin' it is not a property of the plot but of the
coordinate system (like 'usr', which causes inconsistencies if set
directly). Note that 'type' and 'main' are also not parameters.
> Over the years, more from "behavioral modification" than from instinct,
> I look at ?plot.default when I forget defacto plot() arguments. Of
> course, plot.default() is in the See Also in ?plot.
Yes, and plot() is a generic so one needs to be aware that different
methods will be called, some of which support 'asp' and some of which do
not.
> It is rare for me to look at ?plot.window, given the rarity in which I
> call it directly.
>
> > There are NO (that is, zero) live links in the Rgui help system.
There is no such thing. R itself provides several forms of help
text
CHM
HTML
latex
PDF (the reference manual)
and three of those five have active links. Which of the first three you
get by default for help() in Rgui is a preference (latex comes from
offline=TRUE).
> Yeah. I enabled options(htmlhelp = TRUE) in my .Rprofile for the times
> when I use R from the GNOME console, otherwise I am usually in ESS using
> emacs 22 from CVS with the XFT patches.
>
> I am not sure that I ever used the .CHM help when I used to run on
> Windows, but presume that there is a hyperlink in that format to
> parallel the live link in the HTML file.
>
> > help.search("asp") doesn't find anything related to graphics.
>
> Could be added as a \concept presumably in the .Rd files for
> plot.default and plot.window. For example:
>
> \concept{asp aspect ratio}
>
> > ESS is much better for help than Rgui since ESS Rd mode can go to the help
> > page for any word that the cursor sits on. ESS for R help doesn't have the
> > links themselves.
>
> Indeed.
--
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
Re: [Rd] plot with Julian date (PR#9145)
You are using the plot method for class "date" from contributed package
'survival', so it was incorrect to post this as a bug report on R itself.
See
> args(survival:::plot.date)
function (x, y, ..., axes, xaxt, xlab, ylab, log = NULL, xlim = range(x,
na.rm = TRUE), ylim = range(y, na.rm = TRUE))
NULL
which defaults 'log' to the invalid value of NULL.
Similarly, the warning comes from passing the non-graphics-parameter
'type' to axis() inside that function.
Please take this up with the package maintainer (as the posting guide and
FAQ ask).
[You did not get a reply on R-help, at least from me, because you ignored
the advice to contact the package maintainer.]
On Mon, 14 Aug 2006, [EMAIL PROTECTED] wrote:
> Full_Name: Chanseok Park
> Version: 2.3.1
> OS: RHEL
> Submission from: (NULL) (130.127.112.89)
>
>
> Dear Sir/Madam:
>
> I wrote some examples below.
> The plot() function is not working properly with Julian date.
> For example, log="" should be a default option, but without the repetition of
> this default option in plot(), we can not draw it especially with Julian
> date.
> So, maybe, the plot() function might not be compatible with as.date().
>
> Thanks,
> C. Park
>
> ##
> library(survival)
>
> dat=c("12-5-1995", "12-30-1995", "8-27-1996", "11-20-1996", "8-29-1997" )
>
> miles = c(106, 1468, 7298, 7935, 13440 )
>
> jdat = as.date(dat)
>
> plot( jdat, miles ) ## Not working
>
> plot( jdat, miles, log="" ) ## Works
>
> plot( jdat, miles, type="l") ## Not working
>
> plot( jdat, miles, log="", type="l") ## works with WARNING
>
> ##===
> ## Let's use as.Date() and as.date().
> jdat = as.Date( as.date(dat) )
>
> plot( jdat, miles ) ## Works
> plot( jdat, miles, log="" ) ## Works
> plot( jdat, miles, type="l") ## WOrks
>
> __
> 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
Re: [Rd] Using TCP/IP sockets in R
Dirk Eddelbuettel wrote: > Are you aware of Simon's Rserve project at http://www.rosuda.org/Rserve/ ? > It already has Java and C++ client code -- it would be nice if you could > add Python client code to this project. I dont think its feature-complete or well-tested or documented and certainly doesn't deserve a version number anywhere near 1.x, but I did this: http://www.maths.lancs.ac.uk/~rowlings/Software/PythonRserve/ - which I did a while ago and its untested against the latest Rserve versions. No money back, no guarantee. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using TCP/IP sockets in R
There is also svSocket in the SciViews bundle. ..<°}))>< ) ) ) ) ) ( ( ( ( (Prof. Philippe Grosjean ) ) ) ) ) ( ( ( ( (Numerical Ecology of Aquatic Systems ) ) ) ) ) Mons-Hainaut University, Belgium ( ( ( ( ( .. Dirk Eddelbuettel wrote: > On 15 August 2006 at 14:31, Mark Schultz wrote: > | Hi All: > | I've examined the R documentation on sockets and while I can probably > | figure it out with a bit of experimentation, I wondered if anyone has > | some sample code they could send me. I'd like to use R > | as a statistics server to python clients. Is ist possible to have a > | multithreaded server in R? > > Are you aware of Simon's Rserve project at http://www.rosuda.org/Rserve/ ? > It already has Java and C++ client code -- it would be nice if you could > add Python client code to this project. It is not multithreaded [ as R's > core isn't, this isn't easily achievable ] but allows several properly > separated connections at the same time [ when running on Linux/Unix ]. > > Cheers, Dirk > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] fSeries - garchFit (PR#9153)
Full_Name: Ian Gregory Version: 2.1 OS: Windows x64 Submission from: (NULL) (220.236.8.114) fSeries version: 221.10065, Feb 21, 2006. Trying to fit a GARCH(0,1) model with garchFit. Use syntax: formula.mean <- ~arma(0,0); formula.var <- ~garch(0,1) fitaltmodelresults = garchFit( formula.mean, formula.var, series = yseries) yseries can be any length array of data. ie. Equation is: y=z_t*sqrt(omega) The error received is: Error in sum(alpha) : object "alpha" not found __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error in options(...) : invalid continue parameter
Hello!
It seems that prompt and continue argument of options() must be at least
of length one i.e.
> options(prompt="")
Error in options(...) : prompt parameter invalid
> options(prompt=" ")
# bla, bla, ...
> options(prompt="> ")
> # bla, bla, ...
> options(continue="")
Error in options(...) : invalid continue parameter
> options(continue=" ")
> ls(
)
This could be properly documented as shown bellow. I do not think that
it is worth bothering with modifying the code to allow empty prompt and
continue argument.
Cheers!
Index: R/src/library/base/man/options.Rd
===
--- options.Rd (revision 38890)
+++ options.Rd (working copy)
@@ -58,7 +58,7 @@
like \code{x <- 1:3; x[5] <- 6}.}
\item{\code{continue}:}{a string setting the prompt used for lines
- which continue over one line.}
+ which continue over one line. Must be at least of length 1.}
\item{\code{defaultPackages}:}{the packages that are attached by
default when \R starts up. Initially set from value of the
@@ -179,7 +179,7 @@
argument.}
\item{\code{prompt}:}{a string, used for \R's prompt; should usually
- end in a blank (\code{" "}).}
+ end in a blank (\code{" "}). Must be at least of length 1.}
--
Lep pozdrav / With regards,
Gregor Gorjanc
--
University of Ljubljana PhD student
Biotechnical Faculty
Zootechnical Department URI: http://www.bfro.uni-lj.si/MR/ggorjan
Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si
SI-1230 Domzale tel: +386 (0)1 72 17 861
Slovenia, Europefax: +386 (0)1 72 17 888
--
"One must learn by doing the thing; for though you think you know it,
you have no certainty until you try." Sophocles ~ 450 B.C.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rownames() problem with 0-extent arrays (PR#9136)
R-bugs is not the place to ask questions, see the FAQ
On Fri, 11 Aug 2006, [EMAIL PROTECTED] wrote:
[...]
> A separate but related question (not a bug) has to do with the handling
> of dimnames for 0-extent arrays. If an array starts out with non-NULL
> dimnames and is subscripted down to have 0-extent, the corresponding
> component is set to NULL, rather than character(0):
and that dimension does not have any names, so this is appropriate.
> dimnames(tmp[0,,drop=FALSE]) # first component is NULL
>
> Why is that? Note that this is different from how data frames are
> handled:
>
> tmp.df <- data.frame(tmp)
> dimnames(tmp.df[0,]) # first component is character(0)
Data frames do not have 'dimnames', and what is reported by the accessor
function is list(row.names(x), names(x)), both of which are required to be
character vectors. Indeed, as the help file says
For the \code{"data.frame"} method both dimnames must be non-null, and
the rownames must contain no duplicates nor missing values.
> The description in ?dimnames seems to allow character(0) components
> of dimnames,
>
> "The dimnames of a matrix or array can be 'NULL' or a list of the
> same length as 'dim(x)'. If a list, its components are either
> 'NULL' or a character vector the length of the appropriate
> dimension of 'x'."
That is accurate.
> yet the implementation seems to resist them:
>
> tmp2 <- tmp[0,,drop=FALSE]
> dimnames(tmp2) <- list(character(0), LETTERS[1:3])
> dimnames(tmp2) # still NULL
>
> So my question is whether it would be reasonable to change 'dimnames'
> and/or "dimnames<-" to use (or at least allow) character(0) rather than
> NULL for array dimensions of 0 extent.
Why would it be desirable to have two equivalent representations of the
same thing (no names)? As you could easily have found out, the C code
replaces a zero-length vector by NULL.
--
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
Re: [Rd] configure on mac
On Tue, 15 Aug 2006, roger koenker wrote: > Apologies for my ignorance about these matters. All of us except Simon are in the same boat, it seems. It might be helpful to know for his benefit what CPU this is and how you configured R. This seems to a manifestation of an apparent MacOS bug Simon told me about. xerbla_ is in libR.dylib, which loads Matrix.so and that is linked against libRblas.dylib and libRlapack.dylib, both of are looking for xerbla_. On any other OS (except perhaps AIX), the runtime linker would resolve this, but apparently not on the MacOS two-level linking scheme he is currently using. > I think that the multiply defined symbols were probably my fault. After > removing some lapack routines and using a > modified version of Makevars suggested by Martin Maechler > > ## we use the BLAS and now also the LAPACK library: > PKG_LIBS= $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) > > The multiple definitions problems don't appear, but instead I get -- > trying to INSTALL > quantreg -- the same problem with undefined _xerbla_ appears when I > try to install > Matrix. A variety of other source packages install without complaint. > > gcc -dynamiclib -Wl,-macosx_version_min -Wl,10.3 -undefined > dynamic_lookup -single_module > -multiply_defined suppress -L/sw/lib -L/usr/local/lib -o quantreg.so > akj.o boot.o chlfct.o > cholesky.o dsel05.o extract.o kuantile.o mcmb.o penalty.o qrcens.o > rls.o rq1.o rqbr.o rqf > n.o rqfnb.o rqfnc.o sparskit2.o srqfn.o srqfnc.o srtpai.o -L/Library/ > Frameworks/R.framewor > k/Resources/lib -lRlapack -L/Library/Frameworks/R.framework/Resources/ > lib -lRblas -L/usr/l > ocal/lib/gcc/powerpc-apple-darwin8/4.0.0 -L/usr/local/lib/gcc - > lgfortran -lgcc_s -lSystemS > tubs -lmx -lSystem -L/usr/local/lib/gcc/powerpc-apple-darwin8/4.0.0 - > L/usr/local/lib/gcc - > lgfortran -lgcc_s -lSystemStubs -lmx -lSystem -F/Library/Frameworks/ > R.framework/.. -framew > ork R > ld: warning can't open dynamic library: libR.dylib referenced from: / > Library/Frameworks/R. > framework/Resources/lib/libRlapack.dylib (checking for undefined > symbols may be affected) > (No such file or directory, errno = 2) > ld: Undefined symbols: > _xerbla_ referenced from libRlapack expected to be defined in libR.dylib > /usr/bin/libtool: internal link edit command failed > > _xerbla_ is in > > yzzy: otool -Tv libR.dylib | grep xerbla > single module_xerbla_ > > which doesn't appear to be part of the ld above should it be? > Can this be arranged > by modifying Makevars? > > > url:www.econ.uiuc.edu/~rogerRoger Koenker > email[EMAIL PROTECTED]Department of Economics > vox: 217-333-4558University of Illinois > fax: 217-244-6678Champaign, IL 61820 > > On Aug 15, 2006, at 1:08 AM, Prof Brian Ripley wrote: > > > On Tue, 15 Aug 2006, stefano iacus wrote: > > > >> It seems that there are symbols defined in more than one header. This > >> causes problems on mac. You should define the symbol in one header > >> and declare elsewhere as extern. You can find examples in main.c (if > >> I remember well). > >> I'm not sure this is the problems, but it looks like > > > > One of the reasons given by Simon for this change was that was no > > longer > > a problem: see the last sentence of > > > > o MacOS X 10.3 and higher now use two-level namespaces, single > > module in a shared library and allow undefined symbols to be > > resolved at run-time. This implies that common symbols are now > > allowed in package libraries. > > > > What apparently is a problem is having the same entry point in > > multiple > > dynamic libraries (we have had to deal with LSAME, NEWS item two > > up). I > > think this means that having arranged specially to satisfy symbols on > > MacOS, we now need to change it, so in src/extra/blas/Makefile.in > > > > Rblas_la_LIBADD = @RBLAS_LDFLAGS@ @DYLIB_UNDEFINED_ALLOWED_FALSE@ $ > > (FLIBS) > > > > '@DYLIB_UNDEFINED_ALLOWED_FALSE@' needs to be '#'. > > > > and we may then need to link against $(FLIBS) elsewhere. > > > > We need Simon's input: to the rest of us the ever-increasing number of > > ways that MacOS needs special pampering is a mystery. > > > >> stefano > >> > > __ > 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
Re: [Rd] rownames() problem with 0-extent arrays (PR#9136)
The bug here comes from code assuming that
paste("row", numeric(0), sep="")
is of length 0. See ?paste.
Fixed for 2.4.0.
On Fri, 11 Aug 2006, [EMAIL PROTECTED] wrote:
> [R 2.3.1 on Windows XP]
>
> Hello,
> The 'do.NULL=FALSE' option of 'rownames' and 'colnames' does not
> work as documented when the array has a 0-extent dimension:
>
> tmp <- matrix(1:15, ncol=3, dimnames=list(letters[1:5], LETTERS[1:3]))
> rownames(tmp) # Fine
> rownames(tmp[0,,drop=FALSE]) # NULL (okay, but see question below)
> rownames(tmp[0,,drop=FALSE], do.NULL=FALSE) # "row"
>
> The last line returns a character vector of length 1, "row", rather
> than character(0) as implied by the second paragraph of the details
> section of ?rownames:
>
> "If 'do.NULL' is 'FALSE', a character vector (of length 'NROW(x)'
> or 'NCOL(x)') is returned in any case, prepending 'prefix' to
> simple numbers, if there are no dimnames or the corresponding
> component of the dimnames is 'NULL'."
>
> --
>
> A separate but related question (not a bug) has to do with the handling
> of dimnames for 0-extent arrays. If an array starts out with non-NULL
> dimnames and is subscripted down to have 0-extent, the corresponding
> component is set to NULL, rather than character(0):
>
> dimnames(tmp[0,,drop=FALSE]) # first component is NULL
>
> Why is that? Note that this is different from how data frames are
> handled:
>
> tmp.df <- data.frame(tmp)
> dimnames(tmp.df[0,]) # first component is character(0)
>
> The description in ?dimnames seems to allow character(0) components
> of dimnames,
>
> "The dimnames of a matrix or array can be 'NULL' or a list of the
> same length as 'dim(x)'. If a list, its components are either
> 'NULL' or a character vector the length of the appropriate
> dimension of 'x'."
>
> yet the implementation seems to resist them:
>
> tmp2 <- tmp[0,,drop=FALSE]
> dimnames(tmp2) <- list(character(0), LETTERS[1:3])
> dimnames(tmp2) # still NULL
>
> So my question is whether it would be reasonable to change 'dimnames'
> and/or "dimnames<-" to use (or at least allow) character(0) rather than
> NULL for array dimensions of 0 extent.
>
> Rich Raubertas
> Merck & Co.
>
> __
> 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
Re: [Rd] how to include a windows dll in a package
Gabor Csardi <[EMAIL PROTECTED]> writes: > No problem, libxml2 sources are available, that is fine with the > GPL. They need not be included in the _same_ package as the > binaries. This is a topic of vigorous debate at the moment. r-devel is not a good forum in which to repeat the debate, but look at http://software.newsforge.com/software/06/06/23/1728205.shtml and then google around for topics like 'linux distributions provide source'. In any case, I'd recommend against a blase attitude that, because the code is available somewhere, you have no responsibility to distribute it yourself. - Allen S. Rout __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to include a windows dll in a package
On Wed, Aug 16, 2006 at 10:09:52AM -0400, Allen S. Rout wrote: > Gabor Csardi <[EMAIL PROTECTED]> writes: > > > No problem, libxml2 sources are available, that is fine with the > > GPL. They need not be included in the _same_ package as the > > binaries. > > This is a topic of vigorous debate at the moment. r-devel is not a > good forum in which to repeat the debate, but look at > > http://software.newsforge.com/software/06/06/23/1728205.shtml > > and then google around for topics like 'linux distributions provide > source'. > > In any case, I'd recommend against a blase attitude that, because the > code is available somewhere, you have no responsibility to distribute > it yourself. In the meanwhile we agreed in a solution. (Basically i'll do what Uwe tells me to do: the source R package will not include any libxml code but the windows binary package will contain binaries.) I'm not very much interested in these debates anyway... but thanks for the pointer. Gabor -- Csardi Gabor <[EMAIL PROTECTED]>MTA RMKI, ELTE TTK __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using TCP/IP sockets in R
Mark Schultz wrote: > Hi All: > I've examined the R documentation on sockets and while I can probably > figure it out with a bit of experimentation, I wondered if anyone has > some sample code they could send me. I'd like to use R > as a statistics server to python clients. Is ist possible to have a > multithreaded server in R? To answer your last question, R doesn't provide thread capabilities, so one cannot write a multi-threaded server in R. Hence, Rserve, Rsoap, and Rapache (others?) deal with concurrency by using the fork() system call (not available on windows) which clones the parent process, to handle multiple clients. -- Jeffrey Horner Computer Systems Analyst School of Medicine 615-322-8606 Department of Biostatistics Vanderbilt University __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rownames() problem with 0-extent arrays (PR#9136)
Prof Ripley,
Thanks for your reply. I've inserted a couple of inline
comments below.
Rich Raubertas
> -Original Message-
> From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 16, 2006 7:21 AM
> To: Raubertas, Richard
> Cc: r-devel@stat.math.ethz.ch
> Subject: Re: [Rd] rownames() problem with 0-extent arrays (PR#9136)
>
>
> R-bugs is not the place to ask questions, see the FAQ
Yes, I should have sent a separate message.
>
> On Fri, 11 Aug 2006, [EMAIL PROTECTED] wrote:
>
> [...]
>
> > A separate but related question (not a bug) has to do with
> the handling
> > of dimnames for 0-extent arrays. If an array starts out
> with non-NULL
> > dimnames and is subscripted down to have 0-extent, the
> corresponding
> > component is set to NULL, rather than character(0):
>
> and that dimension does not have any names, so this is appropriate.
I think the question of whether a dimension has names or not
should be independent of the extent of that dimension. (My reason
for raising the issue was that some code I was writing would
be cleaner if "dimension has names" and "extent of dimension" were
orthogonal concepts.) Under that premise, there is a difference
between NULL (no names) and character(0) (names).
It appears you don't agree with my premise, and I can see how a
discussion about naming things that don't exist could get rather
metaphysical. So I have worked around the issue in my code.
>
> > dimnames(tmp[0,,drop=FALSE]) # first component is NULL
> >
> > Why is that? Note that this is different from how data frames are
> > handled:
> >
> > tmp.df <- data.frame(tmp)
> > dimnames(tmp.df[0,]) # first component is character(0)
>
> Data frames do not have 'dimnames', and what is reported by
> the accessor
> function is list(row.names(x), names(x)), both of which are
> required to be
> character vectors. Indeed, as the help file says
>
> For the \code{"data.frame"} method both dimnames must be
> non-null, and
> the rownames must contain no duplicates nor missing values.
>
> > The description in ?dimnames seems to allow character(0) components
> > of dimnames,
> >
> > "The dimnames of a matrix or array can be 'NULL' or a
> list of the
> > same length as 'dim(x)'. If a list, its components are either
> > 'NULL' or a character vector the length of the appropriate
> > dimension of 'x'."
>
> That is accurate.
>
> > yet the implementation seems to resist them:
> >
> > tmp2 <- tmp[0,,drop=FALSE]
> > dimnames(tmp2) <- list(character(0), LETTERS[1:3])
> > dimnames(tmp2) # still NULL
> >
> > So my question is whether it would be reasonable to change
> 'dimnames'
> > and/or "dimnames<-" to use (or at least allow) character(0)
> rather than
> > NULL for array dimensions of 0 extent.
>
> Why would it be desirable to have two equivalent
> representations of the
> same thing (no names)? As you could easily have found out,
> the C code
> replaces a zero-length vector by NULL.
>
> --
> 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
[Rd] Abnormal behavior of log function (PR#9155)
Full_Name: Biao Li Version: 2.3.1 OS: Mac OS X 10.4.7 (Intel) Submission from: (NULL) (132.192.4.18) I installed R 2.3.1 on my MacBook Pro (Tiger 10.4.7) and found strange behavior of log function: > a <- 1:20 > log(2^a, 2) == a [1] TRUE TRUE FALSE TRUE TRUE FALSE FALSE TRUE TRUE TRUE TRUE FALSE FALSE FALSE TRUE TRUE TRUE TRUE TRUE TRUE > a[log(2^a, 2) != a] [1] 3 6 7 12 13 14 But on Linux or Windows XP there is no such a problem, and log(2^a, 2) always equals a. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Abnormal behavior of log function (PR#9155)
You do not tell us what log(2^a, a) is on your system. It is likely this is a case of the warning given in ?"==", but we cannot tell from the output shown. R does log(x, 2) more accurately on platforms with a working C function log2: you can see from the configure results if yours is one of those. (Windows is, and Linux normally is.) On Wed, 16 Aug 2006, [EMAIL PROTECTED] wrote: > Full_Name: Biao Li > Version: 2.3.1 > OS: Mac OS X 10.4.7 (Intel) > Submission from: (NULL) (132.192.4.18) > > > I installed R 2.3.1 on my MacBook Pro (Tiger 10.4.7) and found strange > behavior > of log function: > > > a <- 1:20 > > log(2^a, 2) == a > [1] TRUE TRUE FALSE TRUE TRUE FALSE FALSE TRUE TRUE TRUE TRUE FALSE > FALSE FALSE TRUE TRUE TRUE TRUE TRUE TRUE > > a[log(2^a, 2) != a] > [1] 3 6 7 12 13 14 > > But on Linux or Windows XP there is no such a problem, and log(2^a, 2) always > equals a. Have you really tested all possible values? It is not true: > a <- 1e10 > log(2^a, 2) [1] Inf > a <- -1e10 > log(2^a, 2) [1] -Inf -- 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
[Rd] S4 creation where= problems
I had this problem creating S4 objects with 'where'
> env <- new.env()
> setClass("A", where=env)
[1] "A"
> setClass("A", representation(x="numeric"), where=env)
[1] "A"
> setClass("A", representation("numeric"), where=env)
Error in exists(x, envir, mode, inherits) :
invalid first argument
John Chambers (below) suggests I bring this to R-devel. My primary use
is to minimize inadvertent consequences of class creation, e.g., by
overwriting an existing (user) class definition during unit testing or
in .Rd examples. There are also programming opportunities from adding a
suite of class definitions, etc., to an environment, and then
'attach'ing and removing or otherwise exposing the environment in a
modular way.
Martin
--
Bioconductor
John Chambers <[EMAIL PROTECTED]> writes:
> Hmm, an interesting one! There's a good deal of code that assumes
> classes and methods are defined in a _package_, even though
> technically it's allowed for where= to be an ordinary environment.
> What's happening here is that the package name is empty, eventually
> resulting in a problem.
> Class definitions, generic functions and some other objects are
> constructed with a "package" slot, assumed to be a non-empty
> character string. That's the mechanism by which R recognizes the
> corresponding package reference when the class, function, etc is
> being used during a later session. It's possible to patch over the
> specific issue here quite easily (it has to do with creating a
> method for as(x, "numeric") when x is from class "A"), but it's far
> from clear that the result will work in a general sense, when the
> environment is used later on, say.
> If you have a good reason for wanting to use non-package
> environments this way, it's something we should think about & deal
> with cleanly. It would be good, if so, to start a discussion on
> r-devel.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] configure on mac
On Aug 15, 2006, at 3:21 PM, roger koenker wrote: Sorry this, is my fault: > gcc -dynamiclib -Wl,-macosx_version_min -Wl,10.3 -undefined > dynamic_lookup -single_module -multiply_defined suppress -L/sw/lib - > L/usr/local/lib -o quantreg.so akj.o boot.o chlfct.o cholesky.o > dsel05.o extract.o kuantile.o mcmb.o penalty.o qrcens.o rls.o rq1.o > rqbr.o rqfn.o rqfnb.o rqfnc.o sparskit2.o srqfn.o srqfnc.o srtpai.o > -L/Library/Frameworks/R.framework/Resources/lib -lRlapack -L/ > Library/Frameworks/R.framework/Resources/lib -lRblas -L/usr/local/ > lib/gcc/powerpc-apple-darwin8/4.0.0 -L/usr/local/lib/gcc - > lgfortran -lgcc_s -lSystemStubs -lmx -lSystem -L/usr/local/lib/gcc/ > powerpc-apple-darwin8/4.0.0 - L/usr/local/lib/gcc -lgfortran - > lgcc_s -lSystemStubs -lmx -lSystem -F/Library/Frameworks/ > R.framework/.. -framework R > ld: warning can't open dynamic library: libR.dylib referenced > from: / Library/Frameworks/R.framework/Resources/lib/ > libRlapack.dylib (checking for undefined symbols may be affected) ^^ the actual error is here - it cannot find libR > (No such file or directory, errno = 2) > ld: Undefined symbols: > _xerbla_ referenced from libRlapack expected to be defined in > libR.dylib This is just a consequence of the above, _xerbla_ is not found as it is defined libR which couldn't be loaded. The reason is that the framework install didn't set the correct path in libRlapack. It is now fixed in the current R-devel. The current R-devel now also checks the Xcode capabilities and will fall-back to flat namespaces if the linker is too old (the other error reported here). I tested some combinations of BLAS and tools, but not all of them, so please drop me a line if you find a setup that doesn't work. Thanks, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rownames() problem with 0-extent arrays (PR#9136)
Raubertas, Richard wrote:
> Prof Ripley,
> Thanks for your reply. I've inserted a couple of inline
> comments below.
>
> Rich Raubertas
>
>> -Original Message-
>> From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, August 16, 2006 7:21 AM
>> To: Raubertas, Richard
>> Cc: r-devel@stat.math.ethz.ch
>> Subject: Re: [Rd] rownames() problem with 0-extent arrays (PR#9136)
>>
>>
>> R-bugs is not the place to ask questions, see the FAQ
>
> Yes, I should have sent a separate message.
>
>> On Fri, 11 Aug 2006, [EMAIL PROTECTED] wrote:
>>
>> [...]
>>
>>> A separate but related question (not a bug) has to do with
>> the handling
>>> of dimnames for 0-extent arrays. If an array starts out
>> with non-NULL
>>> dimnames and is subscripted down to have 0-extent, the
>> corresponding
>>> component is set to NULL, rather than character(0):
>> and that dimension does not have any names, so this is appropriate.
>
> I think the question of whether a dimension has names or not
> should be independent of the extent of that dimension. (My reason
> for raising the issue was that some code I was writing would
> be cleaner if "dimension has names" and "extent of dimension" were
> orthogonal concepts.) Under that premise, there is a difference
> between NULL (no names) and character(0) (names).
>
> It appears you don't agree with my premise, and I can see how a
> discussion about naming things that don't exist could get rather
> metaphysical.
Yes. There has been quite a lot discussion about 'god' during history!
Kjetil
So I have worked around the issue in my code.
>
>>> dimnames(tmp[0,,drop=FALSE]) # first component is NULL
>>>
>>> Why is that? Note that this is different from how data frames are
>>> handled:
>>>
>>> tmp.df <- data.frame(tmp)
>>> dimnames(tmp.df[0,]) # first component is character(0)
>> Data frames do not have 'dimnames', and what is reported by
>> the accessor
>> function is list(row.names(x), names(x)), both of which are
>> required to be
>> character vectors. Indeed, as the help file says
>>
>> For the \code{"data.frame"} method both dimnames must be
>> non-null, and
>> the rownames must contain no duplicates nor missing values.
>>
>>> The description in ?dimnames seems to allow character(0) components
>>> of dimnames,
>>>
>>> "The dimnames of a matrix or array can be 'NULL' or a
>> list of the
>>> same length as 'dim(x)'. If a list, its components are either
>>> 'NULL' or a character vector the length of the appropriate
>>> dimension of 'x'."
>> That is accurate.
>>
>>> yet the implementation seems to resist them:
>>>
>>> tmp2 <- tmp[0,,drop=FALSE]
>>> dimnames(tmp2) <- list(character(0), LETTERS[1:3])
>>> dimnames(tmp2) # still NULL
>>>
>>> So my question is whether it would be reasonable to change
>> 'dimnames'
>>> and/or "dimnames<-" to use (or at least allow) character(0)
>> rather than
>>> NULL for array dimensions of 0 extent.
>> Why would it be desirable to have two equivalent
>> representations of the
>> same thing (no names)? As you could easily have found out,
>> the C code
>> replaces a zero-length vector by NULL.
>>
>> --
>> 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
