[Rd] whislist (PR#8117)
Full_Name: Knut Krueger
Version:
OS:
Submission from: (NULL) (217.250.214.33)
Maybe it is an idea to copy the hints f.e -> help.search("...") in the
commandline or in the memory to paste it into the commandline.
maybe you could build in an option entry to start the search with help.search
automatically if there is no entry with the ? function
?deviation
No documentation for 'deviation' in specified packages and libraries:
you could try 'help.search("deviation")'
Regards Knut
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.2.0 slated for October 6
We plan to release R version 2.2.0 on October 6. Daily alpha releases will be available after the "Grand feature" freeze on September 8 and beta releases from September 22. The full schedule is available on http://developer.r-project.org (pending propagation delay from https://svn.r-project.org/R-dev-web/trunk/index.html). As usual, it is strongly preferred if bugs are discovered prior to the release and not immediately afterwards! Please do try the alpha/beta releases and report back any errors. On behalf of the R Core Team Peter Dalgaard -- 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] RFC: rawConnection (was "loop connections")
[EMAIL PROTECTED] wrote: > Duncan Murdoch <[EMAIL PROTECTED]> wrote: > > >>I would implement it differently from the way you did. I'd call it >>a rawConnection, taking a raw variable (or converting something else >>using as.raw) as the input, and providing both text and binary >>read/write modes (using the same conventions for text mode as a file >>connection would). It *should* support seek, at least in binary >>mode. > > > I was trying to reuse as much of the textConnection semantics and > underlying code as possible... > > Having a rawConnection() entry point is simple enough. Seeking also > seems straightforward. I'm not so sure about using as.raw(). I > wondered about that, but also thought that rather than coercing to > raw, it might make more sense to cast atomic vector types to raw, > byte-for-byte. I'd prefer as.raw, so that we don't end up with two incompatible ways to convert other objects to raw objects. > Can you given an example of where a text-mode raw connection would be > a useful thing? No, but someone else might. Why unnecessarily let the source of the bytes determine the mode of the connection? In the case of textConnection, there are natural line breaks, so a text mode connection makes sense. A raw object can contain anything, so why wouldn't someone want to put text in it some day? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD BATCH on scripts without trailing newline
If the last line of an R script does not have a trailing newline, a small errror is produced at the end of the script. Small example. If file eg.r contains one line: getwd() and there is no newline after the closing paren $ R CMD BATCH eg.r produces an error: $ cat eg.r.Rout R : Copyright 2005, The R Foundation for Statistical Computing Version 2.1.1 Patched (2005-09-01), ISBN 3-900051-07-0 ... > getwd()proc.time() Error: syntax error Execution halted $ Is it worth changing the BATCH script so that it adds a newline before adding the call to proc.time()? Stephen __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD BATCH on scripts without trailing newline
> "StEgl" == Stephen Eglen <[EMAIL PROTECTED]> > on Thu, 1 Sep 2005 12:09:15 +0100 writes: StEgl> If the last line of an R script does not have a StEgl> trailing newline, a small errror is produced at the StEgl> end of the script. StEgl> Small example. If file eg.r contains one line: StEgl> getwd() and there is no newline after the closing StEgl> paren StEgl> $ R CMD BATCH eg.r StEgl> produces an error: $ cat eg.r.Rout StEgl> R : Copyright 2005, The R Foundation for Statistical StEgl> Computing Version 2.1.1 Patched (2005-09-01), ISBN StEgl> 3-900051-07-0 StEgl> ... >> getwd()proc.time() StEgl> Error: syntax error Execution halted $ aahh, now I finally understand via some people append those **ugly** unneeded ';' to the end of almost every line of R code. It would have helped here :-) :-) StEgl> Is it worth changing the BATCH script so that it adds StEgl> a newline before adding the call to proc.time()? Yes I think it would be. This is trivial, at least for /src/scripts/BATCH Slightly better but more tricky: only append a newline "when needed". Any idea for that? You didn't tell us the *platform* you run R on (and BATCH does depend on the platform), but I know that it's a version of unix, Linux I suppose? BTW: The windows version of "R CMD BATCH" is actually *documented* do to work with files that don't end in newline. Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD BATCH on scripts without trailing newline
> You didn't tell us the *platform* you run R on > (and BATCH does depend on the platform), > but I know that it's a version of unix, Linux I suppose? Thanks Martin. Yes, linux - scientific linux 3 here. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD BATCH on scripts without trailing newline
On Thu, Sep 01, 2005 at 01:39:52PM +0200, Martin Maechler wrote: > >> getwd()proc.time() > StEgl> Error: syntax error Execution halted $ > > aahh, now I finally understand via some people append > those **ugly** unneeded ';' to the end of almost every line of R > code. It would have helped here > :-) :-) What is the problem with the semicolons? Ugliness is in the eye of the beholder, evidently, but on a more objective level, terminating statements by an explicit and visible separator seems like a very reasonable idea to me. > StEgl> Is it worth changing the BATCH script so that it adds > StEgl> a newline before adding the call to proc.time()? > > Yes I think it would be. This is trivial, at least for > /src/scripts/BATCH > Slightly better but more tricky: only append a newline "when needed". > Any idea for that? I think this is a dangerous direction of thought. Having a "terminator if apparently needed" semantics of newline has already brought us the inconsistency of if / else parsing inside and outside of blocks. No more of that, please. Best regards, Jan -- +- Jan T. Kim ---+ |*NEW*email: [EMAIL PROTECTED] | |*NEW*WWW: http://www.cmp.uea.ac.uk/people/jtk | *-=< hierarchical systems are for files, not for humans >=-* __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] strwrap
The maximum length of a character string returned by strwrap,
i.e. max(nchar(strwrap(x,width))), never in my experience exceeds
width-2 (unless x contains a word that is longer than this).
This is not exactly a bug -- width is described only as a "target
column for wrapping lines" -- but seems odd.
Though I don't understand everything that the code is doing,
I think that the first line in the "while" block,
k <- max(sum(lens < maxLength), 1)
should be replaced by
k <- max(sum(lens <= maxLength + 1), 1)
-- here lens[i] is the number of characters in the string
that consists of the first i words *with a trailing space*,
so there is no need to split unless this number exceeds
the target width plus one.
A code snippet for testing:
x <- paste(sapply(sample(10, 100, rep=T),
function(x) substring("aa", 1, x)), collapse=" ")
sapply(10:40, function(m) c(requested.width=m,
actual.width=max(nchar(strwrap(x, m)
Tested on:
> R.version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status Under development (unstable)
major2
minor2.0
year 2005
month08
day 29
svn rev 35457
language R
J. R. M. Hosking
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] generic function S3 consistency warning advice
Hi
section 6.1 of R-exts suggests that a package can take over a
function in the base
package and make it generic.
I want to do this with Re() and have the following lines in my R code:
"Re" <- function(x){UseMethod("Re" )}
"Re.default" <- get("Re" ,pos=NULL,mode="function")
"Re.octonion" <- function(x){give.comp(x,1)}
This, however, generates the following warning from R CMD check:
* checking S3 generic/method consistency ... WARNING
Re:
function(x)
Re.default:
function()
See section 'Generic functions and methods' of the 'Writing R
Extensions'
manual.
I can suppress the warning by commenting out the first line. Is this a
sensible thing to do?
--
Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
tel 023-8059-7743
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] generic function S3 consistency warning advice
This happens because you get a primitive function. However, I believe
Re() is already an generic function ("too") internally, so you do not
have to create your own and redefine the default one. (I'm not sure if
there is another way to tell if a primitive function is also a generic
function than to look at the C source code or by trial-and-error).
Try:
% R --vanilla
> Re.MyClass <- function(x) NA
> x <- structure(3, class="MyClass")
> Re(5+3i)
5
> Re(x)
NA
/Henrik
Robin Hankin wrote:
> Hi
>
> section 6.1 of R-exts suggests that a package can take over a
> function in the base
> package and make it generic.
>
> I want to do this with Re() and have the following lines in my R code:
>
>
>
> "Re" <- function(x){UseMethod("Re" )}
> "Re.default" <- get("Re" ,pos=NULL,mode="function")
> "Re.octonion" <- function(x){give.comp(x,1)}
>
> This, however, generates the following warning from R CMD check:
>
> * checking S3 generic/method consistency ... WARNING
> Re:
>function(x)
> Re.default:
>function()
>
> See section 'Generic functions and methods' of the 'Writing R
> Extensions'
> manual.
>
>
>
> I can suppress the warning by commenting out the first line. Is this a
> sensible thing to do?
>
>
>
>
> --
> Robin Hankin
> Uncertainty Analyst
> National Oceanography Centre, Southampton
> European Way, Southampton SO14 3ZH, UK
> tel 023-8059-7743
>
> __
> 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 CMD check example problem (PR#8113)
[CCing to r-bugs to inform people that we have looked at it.]
Greg,
you sent me the example which can be reduced to an example.Rd file that
contains the following Example section:
\examples{
# \code{} \code{}
foo <- function()
{
}
}
calling now
R CMD Rdconv -t example example.Rd
results in:
### ** Examples
# this-is-escaped-code{ this-is-escaped-codenormal-bracket9bracket-normal
foo <- function()
normal-bracket10bracket-normal
normal-bracket10bracket-normal
I do not know whether this qualifies as a bug, but for simplicity let's say:
"Don't use \code{} in an Example section where it does not make sense
anyway."
Best,
Uwe
Warnes, Gregory R wrote:
>
>>-Original Message-
>>From: Uwe Ligges [mailto:[EMAIL PROTECTED]
>>Sent: Thursday, September 01, 2005 8:57 AM
>>To: Warnes, Gregory R
>>Subject: Re: [Rd] R CMD check example problem (PR#8113)
>>
>>
>>Greg,
>>
>>the attachment is not appended on the forwarded message to
>>R-devel, and
>>I would like to take a look, can you send it in a private
>>message, please?
>>
>>Best,
>>Uwe
>>
>>Warnes, Gregory R wrote:
>>
>>
>>>[Automatic forwarding from R-bugs failed. This message has
>>
>>been manually
>>
>>>forwarded.]
>>>
>>>Hi all!
>>>
>>>I'm trying to add Thomas Lumley's defmacro() function Lumley T.
>>>"Programmer's Niche: Macros in {R}", R News, 2001, Vol 1,
>>> No. 3, pp 11--13,
>>
>>\url{http://CRAN.R-project.org/doc/Rnews/} to the gtools
>>
>>>package (provided that Thomas gives his OK). And I've
>>
>>encountered an error
>>
>>>in how R CMD check is extracting the example code I have in
>>
>>the .Rd file.
>>
>>>The example section contains the lines
>>>
>>> # An equivalent function is somewhat messier, since it must either
>>>explicitly
>>> # construct the y axis label, duplicating some of the
>>
>>work of the plot
>>
>>> # function:
>>> plotit <- function( df, var, col="red", title="" )
>>> {
>>> dname <- deparse(substitute(df))
>>> vname <- deparse(substitute(var))
>>> plot( df[[vname]] ~ df$Grp, type="b", col=col, title=title,
>>>ylab=paste( dname, "$", vname, sep='' ) )
>>> }
>>> # or we explicitly construct the call and then call eval.
>>
>> The code for
>>
>>> # the latter approach is # omiited since this is quite messy and
>>> # requires a lot of work.
>>>
>>>which is getting extracted for testing into
>>
>>gtools.Rcheck/gtools-Ex.R as
>>
>>> # An equivalent function is somewhat messier, since it must either
>>>explicitly
>>> # construct the y axis label, duplicating some of the
>>
>>work of the plot
>>
>>> # function:
>>> plotit <- function( df, var, col="red", title=""
>>>)normal-bracket43bracket-normal
>>> dname <- deparse(substitute(df))
>>> vname <- deparse(substitute(var))
>>> plot( df[[vname]] ~ df$Grp, type="b", col=col, title=title,
>>>ylab=paste( dname, "$", vname, sep='' ) )
>>> normal-bracket43bracket-normal
>>> # or we explicitly construct the call and then call eval.
>>
>> The code for
>>
>>> # the latter approach is # omiited since this is quite messy and
>>> # requires a lot of work.
>>>
>>>Note that the opening and closing curly brakkets are
>>
>>converted to the string
>>
>>>"normal-bracket43bracket-normal". [I assume that this is happeing
>>>somewhere to check for brace-matches, and isn't being
>>
>>properly undone.] As
>>
>>>a consequence, R CMD check is failing:
>>>
>>> > # An equivalent function is somewhat messier, since it
>>
>>must either
>>
>>>explicitly
>>> > # construct the y axis label, duplicating some of the
>>
>>work of the plot
>>
>>> > # function:
>>> > plotit <- function( df, var, col="red", title=""
>>>)normal-bracket43bracket-normal
>>> > dname <- deparse(substitute(df))
>>> > vname <- deparse(substitute(var))
>>> > plot( df[[vname]] ~ df$Grp, type="b", col=col, title=title,
>>> + ylab=paste( dname, "$", vname, sep='' ) )
>>> Error in df[[vname]] : object is not subsettable
>>> Execution halted
>>>
>>>I've checked, and this occurs under R-2.1.0, R-2.1.1, and today's
>>>R-2.2.0-devel on my
>>>
>>> platform i686-pc-linux-gnu
>>> arch i686
>>> os linux-gnu
>>> system i686, linux-gnu
>>>
>>>I'm attaching the probelmatic .Rd file to this email.
>>>
>>> <>
>>>
>>>(For the record, I've simply enclosed the problematic
>>
>>section in \dontrun as
>>
>>>a workaround.)
>>>
>>>-Greg
>>>
>>>
>>>
>>>Gregory R. Warnes, Ph.D.
>>>Associate Director, Non-Clinical Statistics
>>>Pfizer Global Research and Development
>>>
>>>
>>>
>>>LEGAL NOTICE
>>>Unless expressly stated otherwise, this message is
>>
>>confidential and may be privileged. It is intended for the
>>addressee(s) only. Access to this E-mail by anyone else is
>>unauthorized. If you are not an addressee, any disclosure or
>>copying of the contents of this E-mai
[Rd] error in apply help file? (PR#8118)
Gents: (alas, I think no ladies need to be included in the salutation) The apply() Help file says "... If the calls to FUN return vectors of different lengths, apply returns a list of length dim(X)[MARGIN]. " Shouldn't that be: "If the calls to FUN return vectors of different lengths, apply returns a list of length prod(dim(X)[MARGIN]). " Also, might you wish to add: "This list has a dim attribute of MARGIN. That is, if VALUE is the returned list, dim(VALUE) = MARGIN and the values in VALUE can be accessed by the usual array subscripting operations." Further, it might also be useful to add the following to your Examples code: ## Example with different lengths for each call z <- array(1:24,dim=2:4) zseq <- apply(z,1:2,function(x)seq(length=max(x))) zseq ## displayed as a 2 x 3 matrix typeof(zseq) ## list dim(zseq) ## 2 3 zseq[1,] Feel free to ignore these suggestions, of course. Cheers, -- Bert Gunter Genentech Non-Clinical Statistics South San Francisco, CA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check example problem (PR#8113)
Ahh. I didn't notice that my fingers had used \code() inside of the example
section. I've removed them, and everything seems to be working properly
now.
-G
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> [EMAIL PROTECTED]
> Sent: Thursday, September 01, 2005 12:23 PM
> To: r-devel@stat.math.ethz.ch
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Rd] R CMD check example problem (PR#8113)
>
>
> [CCing to r-bugs to inform people that we have looked at it.]
>
> Greg,
>
> you sent me the example which can be reduced to an example.Rd
> file that
> contains the following Example section:
>
>
>
> \examples{
> # \code{} \code{}
> foo <- function()
> {
> }
> }
>
>
> calling now
> R CMD Rdconv -t example example.Rd
> results in:
>
>
>
>
> ### ** Examples
>
> # this-is-escaped-code{
> this-is-escaped-codenormal-bracket9bracket-normal
> foo <- function()
> normal-bracket10bracket-normal
> normal-bracket10bracket-normal
>
>
>
> I do not know whether this qualifies as a bug, but for
> simplicity let's say:
> "Don't use \code{} in an Example section where it does not make sense
> anyway."
>
> Best,
> Uwe
>
>
>
>
>
>
> Warnes, Gregory R wrote:
>
> >
> >>-Original Message-
> >>From: Uwe Ligges [mailto:[EMAIL PROTECTED]
> >>Sent: Thursday, September 01, 2005 8:57 AM
> >>To: Warnes, Gregory R
> >>Subject: Re: [Rd] R CMD check example problem (PR#8113)
> >>
> >>
> >>Greg,
> >>
> >>the attachment is not appended on the forwarded message to
> >>R-devel, and
> >>I would like to take a look, can you send it in a private
> >>message, please?
> >>
> >>Best,
> >>Uwe
> >>
> >>Warnes, Gregory R wrote:
> >>
> >>
> >>>[Automatic forwarding from R-bugs failed. This message has
> >>
> >>been manually
> >>
> >>>forwarded.]
> >>>
> >>>Hi all!
> >>>
> >>>I'm trying to add Thomas Lumley's defmacro() function Lumley T.
> >>>"Programmer's Niche: Macros in {R}", R News, 2001, Vol 1,
> >>> No. 3, pp 11--13,
> >>
> >>\url{http://CRAN.R-project.org/doc/Rnews/} to the gtools
> >>
> >>>package (provided that Thomas gives his OK). And I've
> >>
> >>encountered an error
> >>
> >>>in how R CMD check is extracting the example code I have in
> >>
> >>the .Rd file.
> >>
> >>>The example section contains the lines
> >>>
> >>> # An equivalent function is somewhat messier, since it
> must either
> >>>explicitly
> >>> # construct the y axis label, duplicating some of the
> >>
> >>work of the plot
> >>
> >>> # function:
> >>> plotit <- function( df, var, col="red", title="" )
> >>> {
> >>> dname <- deparse(substitute(df))
> >>> vname <- deparse(substitute(var))
> >>> plot( df[[vname]] ~ df$Grp, type="b", col=col, title=title,
> >>>ylab=paste( dname, "$", vname, sep='' ) )
> >>> }
> >>> # or we explicitly construct the call and then call eval.
> >>
> >> The code for
> >>
> >>> # the latter approach is # omiited since this is quite messy and
> >>> # requires a lot of work.
> >>>
> >>>which is getting extracted for testing into
> >>
> >>gtools.Rcheck/gtools-Ex.R as
> >>
> >>> # An equivalent function is somewhat messier, since it
> must either
> >>>explicitly
> >>> # construct the y axis label, duplicating some of the
> >>
> >>work of the plot
> >>
> >>> # function:
> >>> plotit <- function( df, var, col="red", title=""
> >>>)normal-bracket43bracket-normal
> >>> dname <- deparse(substitute(df))
> >>> vname <- deparse(substitute(var))
> >>> plot( df[[vname]] ~ df$Grp, type="b", col=col, title=title,
> >>>ylab=paste( dname, "$", vname, sep='' ) )
> >>> normal-bracket43bracket-normal
> >>> # or we explicitly construct the call and then call eval.
> >>
> >> The code for
> >>
> >>> # the latter approach is # omiited since this is quite messy and
> >>> # requires a lot of work.
> >>>
> >>>Note that the opening and closing curly brakkets are
> >>
> >>converted to the string
> >>
> >>>"normal-bracket43bracket-normal". [I assume that this is happeing
> >>>somewhere to check for brace-matches, and isn't being
> >>
> >>properly undone.] As
> >>
> >>>a consequence, R CMD check is failing:
> >>>
> >>> > # An equivalent function is somewhat messier, since it
> >>
> >>must either
> >>
> >>>explicitly
> >>> > # construct the y axis label, duplicating some of the
> >>
> >>work of the plot
> >>
> >>> > # function:
> >>> > plotit <- function( df, var, col="red", title=""
> >>>)normal-bracket43bracket-normal
> >>> > dname <- deparse(substitute(df))
> >>> > vname <- deparse(substitute(var))
> >>> > plot( df[[vname]] ~ df$Grp, type="b", col=col, title=title,
> >>> + ylab=paste( dname, "$", vname, sep='' ) )
> >>> Error in df[[vname]] : object is not subsettable
> >>> Execution halted
> >>>
> >>>I've checked, and this occurs under R-2.1.0, R-2.1.1, and today's
> >
Re: [Rd] RFC: rawConnection (was "loop connections")
Duncan Murdoch <[EMAIL PROTECTED]> wrote: > > > > Having a rawConnection() entry point is simple enough. Seeking also > > seems straightforward. I'm not so sure about using as.raw(). I > > wondered about that, but also thought that rather than coercing to > > raw, it might make more sense to cast atomic vector types to raw, > > byte-for-byte. > I'd prefer as.raw, so that we don't end up with two incompatible ways to > convert other objects to raw objects. An advantage of no as.raw() would be that you could create a raw connection on an object without making an extra copy, which was another of your requests. But there would be a lack of symmetry, because you could "r" from an arbitrary R object, but only "w" to raw, unless there was also a way of specifying a type for the result vector. Having the backing store be an R object with no copy does seem tricky, however. Currently, textConnection() makes a copy for "r" connections but writes directly to an R object for "w" connections. The "w" case is buggy; you can crash R by removing the target object while the connection is being used. I'm not familiar enough with R internals to know how to fix that. Maybe the object has to be searched for every time the connection is used, to avoid potentially stale pointers? > > Can you given an example of where a text-mode raw connection would be > > a useful thing? > No, but someone else might. Why unnecessarily let the source of the > bytes determine the mode of the connection? In the case of > textConnection, there are natural line breaks, so a text mode connection > makes sense. A raw object can contain anything, so why wouldn't someone > want to put text in it some day? It seems that that a text-mode raw connection would be equivalent to a textConnection on the result of rawToChar(), no? While some of these possibilities seem like they might be useful, I'm not sure that all need to be implemented immediately. If we can agree on the basic interface and semantics, then we could implement a basic version now, and relax restrictions on the arguments later as needed? -- Dave __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] error in apply help file? (PR#8118)
[EMAIL PROTECTED] wrote:
> Gents: (alas, I think no ladies need to be included in the salutation)
May I ask why you think R-devel (to which R-bugs stuff is forwarded) is
only read by males?
Sounds a little bit discriminating ("Only males produce bugs, females
simply produce perfect code and do not need to read R-devel mails."??!).
Hence, I'd like to complain in this case.
Uwe Ligges
> The apply() Help file says
> "...
> If the calls to FUN return vectors of different lengths, apply returns a
> list of length dim(X)[MARGIN]. "
>
> Shouldn't that be:
>
> "If the calls to FUN return vectors of different lengths, apply returns a
> list of length prod(dim(X)[MARGIN]). "
>
> Also, might you wish to add:
>
> "This list has a dim attribute of MARGIN. That is, if VALUE is the returned
> list, dim(VALUE) = MARGIN and the values in VALUE can be accessed by the
> usual array subscripting operations."
>
> Further, it might also be useful to add the following to your Examples code:
>
> ## Example with different lengths for each call
> z <- array(1:24,dim=2:4)
> zseq <- apply(z,1:2,function(x)seq(length=max(x)))
> zseq ## displayed as a 2 x 3 matrix
> typeof(zseq) ## list
> dim(zseq) ## 2 3
> zseq[1,]
>
>
> Feel free to ignore these suggestions, of course.
>
> Cheers,
>
> -- Bert Gunter
> Genentech Non-Clinical Statistics
> South San Francisco, CA
>
> __
> 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] Question about package's DESCRIPTION/Depends field
Hi, My package "caMassClass" depends on several other packages, one of them "PROcess" residing on "Bioconductor" website. Bioconductor repository is not, listed in default set of repositories in current version of R (Windows R 2.1.1). As a result people installing my package have to change that default, before installing the package. Is there a way of including that information in the DESCRIPTION file, that would spare the user from manual tinkering with the installation process?. Something along the lines of "Repositories: Bioconductor". Jarek Tuszynski [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about package's DESCRIPTION/Depends field
> Tuszynski, Jaroslaw W writes: > Hi, > My package "caMassClass" depends on several other packages, one of them > "PROcess" residing on "Bioconductor" website. Bioconductor repository is > not, listed in default set of repositories in current version of R (Windows > R 2.1.1). As a result people installing my package have to change that > default, before installing the package. > Is there a way of including that information in the DESCRIPTION file, that > would spare the user from manual tinkering with the installation process?. > Something along the lines of "Repositories: Bioconductor". No. The idea is that the 'repos' option is set appropriately. Best -k > Jarek Tuszynski > [[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] Bug in copying of S4 objects (PR#8112)
Another variant of what is probably the same issue:
> setClass("foo", representation(a = "numeric"))
[1] "foo"
> f <- function() [EMAIL PROTECTED] <<- 2
> x <- new("foo",a=1)
> y <- x
> f()
> x
An object of class âfooâ
Slot "a":
[1] 2
> y
An object of class âfooâ
Slot "a":
[1] 2
luke
On Wed, 31 Aug 2005, [EMAIL PROTECTED] wrote:
If I have an S4 object, and I make a copy, changes to the original
aren't reflected in the copy:
> setClass("foo", representation(slot="numeric"))
> x <- new("foo", slot=1)
> y <- x
> [EMAIL PROTECTED] <- 2
> y
An object of class "foo"
Slot "slot":
[1] 1
This is as it should be. However, if I call the slot assignment
function in a funny way, y *does* receive the changes:
> x <- new("foo", slot=1)
> y <- x
> assign("x", "@<-"(x, "slot", 2))
> y
An object of class "foo"
Slot "slot":
[1] 2
This happens in the current R-devel in Windows, and R-patched too.
> version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status Under development (unstable)
major2
minor2.0
year 2005
month08
day 31
svn rev 35467
language R
Duncan Murdoch
__
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] RFC: rawConnection (was "loop connections")
[EMAIL PROTECTED] wrote: > Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >>>Having a rawConnection() entry point is simple enough. Seeking also >>>seems straightforward. I'm not so sure about using as.raw(). I >>>wondered about that, but also thought that rather than coercing to >>>raw, it might make more sense to cast atomic vector types to raw, >>>byte-for-byte. > > >>I'd prefer as.raw, so that we don't end up with two incompatible ways to >>convert other objects to raw objects. > > > An advantage of no as.raw() would be that you could create a raw > connection on an object without making an extra copy, which was > another of your requests. But there would be a lack of symmetry, > because you could "r" from an arbitrary R object, but only "w" to raw, > unless there was also a way of specifying a type for the result > vector. I think the cost of duplicating as.raw is worse than the cost of using extra memory. If the lack of symmetry bothers you, a solution is to require a raw object as input. > Having the backing store be an R object with no copy does seem tricky, > however. In that case I wouldn't bother. It's important to get it right; being maximally efficient is a second priority. > Currently, textConnection() makes a copy for "r" connections > but writes directly to an R object for "w" connections. The "w" case > is buggy; you can crash R by removing the target object while the > connection is being used. I'm not familiar enough with R internals to > know how to fix that. Maybe the object has to be searched for every > time the connection is used, to avoid potentially stale pointers? I've been having an argument with some other people about something related to this. I think they would say that the language doesn't support writing to a variable. I don't know the right way to fix this. > > >>>Can you given an example of where a text-mode raw connection would be >>>a useful thing? > > >>No, but someone else might. Why unnecessarily let the source of the >>bytes determine the mode of the connection? In the case of >>textConnection, there are natural line breaks, so a text mode connection >>makes sense. A raw object can contain anything, so why wouldn't someone >>want to put text in it some day? > > > It seems that that a text-mode raw connection would be equivalent to a > textConnection on the result of rawToChar(), no? If so, then a binary mode rawConnection (with mention of the way to convert in the Rd file) would be good enough for me. > > While some of these possibilities seem like they might be useful, I'm > not sure that all need to be implemented immediately. If we can agree > on the basic interface and semantics, then we could implement a basic > version now, and relax restrictions on the arguments later as needed? I'd rather get it right now, but that doesn't have to mean including every bell and whistle someone (even me!) has suggested. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in copying of S4 objects (PR#8112)
I've poked in the source a bit. Here are some notes in case someone
has time to look into this.
The main internal difference between <<- and <- for complex
assignments is that <- calls EnsureLocal which calls duplicate on the
value of the left hand side value if NAMED == 2. In principle I don't
tink this should be necessary, but it means that assignment functions
called for <- assignments will not see NAMED == 2. This protects
agains internal assignment functions that destructively modify without
looking at NAMED, which is what @<- and slot<- do. But <<- does not
do this defensive duplicating, hence the problem with <<-. Similar
problems occur if structures contain environments used to implement
reference behaviour since the copying stops at the environment.
The appropriate fix is to insure that @<- and slot<- respect NAMED and
duplicate when NAMED == 2, as attr<- does. This will require either
making @<- and slot<- into SPECIALSXP's or some sort of
underhandedness to allow them to remain closures. One possibility
might be to define a SPECIALSXP that looks at the NAMED value of the
object argument (by inspecting the promise before it is forced). This
can then be passed into the internal R_set_slot function via .Call.
luke
On Thu, 1 Sep 2005, Luke Tierney wrote:
Another variant of what is probably the same issue:
> setClass("foo", representation(a = "numeric"))
[1] "foo"
> f <- function() [EMAIL PROTECTED] <<- 2
> x <- new("foo",a=1)
> y <- x
> f()
> x
An object of class âfooâ
Slot "a":
[1] 2
> y
An object of class âfooâ
Slot "a":
[1] 2
luke
On Wed, 31 Aug 2005, [EMAIL PROTECTED] wrote:
If I have an S4 object, and I make a copy, changes to the original
aren't reflected in the copy:
> setClass("foo", representation(slot="numeric"))
> x <- new("foo", slot=1)
> y <- x
> [EMAIL PROTECTED] <- 2
> y
An object of class "foo"
Slot "slot":
[1] 1
This is as it should be. However, if I call the slot assignment
function in a funny way, y *does* receive the changes:
> x <- new("foo", slot=1)
> y <- x
> assign("x", "@<-"(x, "slot", 2))
> y
An object of class "foo"
Slot "slot":
[1] 2
This happens in the current R-devel in Windows, and R-patched too.
> version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status Under development (unstable)
major2
minor2.0
year 2005
month08
day 31
svn rev 35467
language R
Duncan Murdoch
__
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] RFC: rawConnection (was "loop connections")
Duncan Murdoch <[EMAIL PROTECTED]> wrote: > I think the cost of duplicating as.raw is worse than the cost of using > extra memory. If the lack of symmetry bothers you, a solution is to > require a raw object as input. It wouldn't exactly be duplicating as.raw since this way of converting to raw is actually to do nothing at all, just to treat the object as if it is already raw. But, I don't have a strong opinion. > > Currently, textConnection() makes a copy for "r" connections > > but writes directly to an R object for "w" connections. The "w" case > > is buggy; you can crash R by removing the target object while the > > connection is being used. I'm not familiar enough with R internals to > > know how to fix that. Maybe the object has to be searched for every > > time the connection is used, to avoid potentially stale pointers? > I've been having an argument with some other people about something > related to this. I think they would say that the language doesn't > support writing to a variable. I tried changing textConnection output connections to look up the destination object on every access and that seems to solve the problem without being terribly expensive. > If so, then a binary mode rawConnection (with mention of the way to > convert in the Rd file) would be good enough for me. It seems we are coming back to something close to what I had originally implemented? -- Dave __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
