Sounds cool. I agree about the need for range* functions, if just for
simplicity and convenience. Are you able to attach the patch?
Thanks,
Michael
On Sun, Jun 1, 2014 at 7:58 PM, Peter Haverty haverty.pe...@gene.com
wrote:
I think viewMedians would be great. While you have the hood up,
Hi Peter,
Seems like you have a pretty good implementation of the view* functions
in genoset. Nice work! And great to hear that there is so much room for
improvements to the implementation currently in IRanges. I'll try to
give this a shot soon but first I want to move Rle's to the S4Vectors
While we rework things, what about adding support for atomic vectors, in
addition to Rles? Also, what about functions that are optimized for
partitionings? Those would be easy to write and would let us greatly
accelerate e.g. sum,CompressedIntegerList. Right now we rely on rowsum()
which is fast
I have have rangeColMeans which is essentially rangeMeans for
vector/matrix. I renamed this to make it a method on rangeMeans. I think it
would be great to have methods for all the commonly used types. We should
put some thought into how these would all share as much code as is
practical.
Pete
So rangeMeans,matrix implies rangeColMeans? Honestly, I would just have a
rangeColMeans and rangeRowMeans, which is consistent with the existing
row/colMeans. Don't see a good reason to prefer columns over rows.
On Mon, Jun 2, 2014 at 5:34 PM, Peter Haverty haverty.pe...@gene.com
wrote:
I have
Hi All,
may I suggest to put a Contact us link or information on the CRAN web
pages?
I guess package maintainers are expected to email c...@r-project.org if
they want to contact CRAN maintainers, but it would be nice to know for
sure.
Thanks, Best,
Gabor
[[alternative HTML version
I noted Duncan's comment that an answer had been provided, and went to
the archives to find his earlier comment, which I am fairly sure I saw a
day or two ago. However, neither May nor June archives show Duncan in
the thread except for the msg below (edited for space). Possibly tech
failures are
On 06/02/2014 12:16 AM, Gabriel Becker wrote:
Carl,
I don't really have a horse in this race other than a strong feeling that
whatever check does should be mandatory.
That having been said, I think it can be argued that the fact that check
does this means that it IS in the R package vignette
Yes, I completely agree the tangle code should run without errors, if
the package author has provided such a script. However, I think it is
also the package author's right to choose not to provide such a
script, for reasons that I stated in the beginning (1. redundancy; 2.
tangle functions ignore
I asked the same question privately yesterday since I did not receive
it or find it in the archive, and it turned out he sent an off-line
reply. I'm replying publicly just to avoid further confusion, and
sorry to spam all in the list.
Regards,
Yihui
--
Yihui Xie xieyi...@gmail.com
Web:
Hi,
Please consider the following code:
a - seq.int(10) # create a
tracemem(a)
a[1:4] - 4:1 # no internal copy
b - a # no internal copy
b[1:4] - 1:4 # copy, b is not a any more
a[1:4] - 1:4 # copy, but why?
With results:
a - seq.int(10)
tracemem(a)
[1] 0x1792bc0
a[1:4] -
On 03/06/2014, 12:58 AM, Yihui Xie wrote:
Yes, I completely agree the tangle code should run without errors, if
the package author has provided such a script. However, I think it is
also the package author's right to choose not to provide such a
script, for reasons that I stated in the beginning
On 2 June 2014 11:44, Duncan Murdoch murdoch.dun...@gmail.com wrote:
On 03/06/2014, 12:58 AM, Yihui Xie wrote:
Please also note that I do not expect R core or CRAN maintainers to do
any extra work: package authors can easily disable tangle by
themselves without anything special flags to R
Well, there is still misunderstanding: there is nothing that really
stops you from tangling the vignettes, and I do not disagree that
tangle can be useful in certain cases. I'm talking about whether
package authors _must_ tangle all their vignettes, or leave some to
users to run Stangle() or
As far as I understand, the purpose of vignettes is to document the
functions/objects provided by the package.
If we consider vignettes documentation, then having code in the vignette
which won't run outside of a dynamic document is akin to having an example
which runs correctly when you call
On 03/06/2014, 4:12 AM, Gavin Simpson wrote:
On 2 June 2014 11:44, Duncan Murdoch murdoch.dun...@gmail.com
mailto:murdoch.dun...@gmail.com wrote:
On 03/06/2014, 12:58 AM, Yihui Xie wrote:
Please also note that I do not expect R core or CRAN maintainers
to do
any
On 03/06/2014, 4:38 AM, Yihui Xie wrote:
Well, there is still misunderstanding: there is nothing that really
stops you from tangling the vignettes, and I do not disagree that
tangle can be useful in certain cases. I'm talking about whether
package authors _must_ tangle all their vignettes,
On 2 June 2014 15:59, Duncan Murdoch murdoch.dun...@gmail.com wrote:
On 03/06/2014, 4:12 AM, Gavin Simpson wrote:
On 2 June 2014 11:44, Duncan Murdoch murdoch.dun...@gmail.com
mailto:murdoch.dun...@gmail.com wrote:
Several of us have told you the real harm: it means that users
Ben Bolker bbolker at gmail.com writes:
FWIW this seems to be a FAQ:
https://stat.ethz.ch/pipermail/r-devel/2003-July/027018.html
http://thr3ads.net/r-devel/2013/01/
2171832-Re-na.omit-option-in-prcomp-formula-interface-only
http://r.789695.n4.nabble.com/
Doc, it hurts when I do this.
So, don't do that.
If no one in R Core does anything about this issue (in terms of changing
Sweave or Stangle), then the solution still remains very simple.
Authors of vignettes should avoid using anything in \Sexpr{} that has a
side effect. As long as they do
Under Windows 8.1 with a touch screen, the pinch gesture
causes an rgl plot to expand (zoom in) instead of contract, the opposite of
what I would expect. When using a map app, for example, the pinch
gesture causes the map to contract (zoom out).
__
As I pointed out, \Sexpr{} is not the only potential problem. Besides,
side effects are not necessarily evil in all cases.
Since I have been described as nitpicky, it is time for me to quit
the discussion now (adjectives on personal pronouns instead of nouns
in a discussion is a sign for me to
22 matches
Mail list logo
