Regarding Martin Maechler's proposal:
Arithmetic between length-1 arrays and longer non-arrays had
silently dropped the array attributes and recycled. This now gives
a warning and will signal an error in the future, as it has always
for logic and comparison operations
For example,
Could we take a cue from min() and max()?
> x <- 1:10
> min(x[x>7])
[1] 8
> min(x[x>11])
[1] Inf
Warning message:
In min(x[x > 11]) : no non-missing arguments to min; returning Inf
>
As ?min says, this is implemented to preserve transitivity, and this
makes a lot of sense.
I think the issuing of
Hi,
With Bioc-release I can run without problems the following code:
library('GenomicRanges')
l <- CharacterList(list(NA, NA, '1', '2'))
r <- CharacterList(as.list(letters[1:4]))
tmp <- merge(l, r, all = TRUE)
However, it gives an error with Bioc-devel:
Error in V_recycle(value, x, x_what =
On 09/08/2016 01:22 PM, Gabriel Becker wrote:
On Thu, Sep 8, 2016 at 10:05 AM, William Dunlap wrote:
Shouldn't binary operators (arithmetic and logical) should throw an error
when one operand is NULL (or other type that doesn't make sense)? This is
a different case than
Prior to the mid-1990s, S did "length-0 OP length-n -> rep(NA, n)" and it
was changed
to "length-0 OP length-n -> length-0" to avoid lots of problems like
any(x<0) being NA
when length(x)==0. Yes, people could code defensively by putting lots of
if(length(x)==0)...
in their code, but that is
On Thu, Sep 8, 2016 at 10:05 AM, William Dunlap wrote:
> Shouldn't binary operators (arithmetic and logical) should throw an error
> when one operand is NULL (or other type that doesn't make sense)? This is
> a different case than a zero-length operand of a legitimate type.
Shouldn't binary operators (arithmetic and logical) should throw an error
when one operand is NULL (or other type that doesn't make sense)? This is
a different case than a zero-length operand of a legitimate type. E.g.,
any(x < 0)
should return FALSE if x is number-like and length(x)==0 but
Alexandre,
AFAICS, this code actually causes infinite recursion, and here's why:
1. formals grabs returns the formals of the function identified by
sys.function(sys.parent()) this ends up being print.new, whose first
argument is x
2. mget looks for the symbol x in envir =
Martin,
Like Robin and Oliver I think this type of edge-case consistency is
important and that it's fantastic that R-core - and you personally - are
willing to tackle some of these "gotcha" behaviors. "Little" stuff like
this really does combine to go a long way to making R better and better.
I
That would work, although it would entail standing up a server to front the
elasticsearch module. The strikes me a huge investment of time which
would, in addition, recreate the current key man risk.
On Thu, Sep 8, 2016 at 7:51 AM, Kevin Coombes
wrote:
> Would it
Would it make sense to recreate the "searchable R help pages" by feeding
them all into elasticsearch, which will automatically index them and
also provides an extensive (HTTP+JSON-based) API to perform complex
searches?
On 9/8/2016 10:31 AM, Jonathan Baron wrote:
On 09/08/16 07:09, John
Jonathan,
FWIW I mentored a Google Summer of Code student (who was more than highly
self-sufficient and needed next to no help, apart from some small R packaging
tricks) as part of the Xapian project in order to write RXapian:
https://github.com/amandaJayanetti/RXapian
which is an R
On 09/08/16 07:09, John Merrill wrote:
Given Google's commitment to R, I don't think that they'd be at all averse
to supporting a custom search box on the package page. It might well be a
good thing for "someone" to examine the API for setting up such a page and
to investigate how to mark the
I looked at rdocumentation.org. At first I thought it was a superior
replacement for namazu, but after I tried a few things I decided that
it wasn't. I could not find any documentation about how to search, and
the various things I tried seemed to yield very strange responses,
e.g., a search for
On 9/8/2016 5:01 AM, Jonathan Baron wrote:
OK. It is sort of fixed and sort of works.
We'll keep it for now, but this is not going to work forever. When
namazu fails completely I will not have the time to install a new
search engine.
One option is to use google. For a site like this, I
On 9/8/2016 3:30 AM, Joris Meys wrote:
>
> Hi Jonathan,
>
> I have neither the resources nor the skills to take over, but whatever
> happens I want to thank you for all the work. Too often people forget
> that all these nice tools keep working due to the devotion of people
> like you.
>
> So
On 8 September 2016 at 06:01, Jonathan Baron wrote:
| We have over 10,000 packages now. I wonder if searching all help files
| is really helpful anymore.
Yes it is. I go to http://rdocumentation.org a lot for quick look-ups.
So thanks to Datacamp for running that.
Dirk
--
I have mixed feelings about this. I used to find the sos package very
useful when I first started using it but as the number of packages has
grown I now find it gives me a huge list which takes a lot of time to
digest. This may of course reflect my rudimentary search term selection
skills.
> robin hankin
> on Thu, 8 Sep 2016 10:05:21 +1200 writes:
> Martin I'd like to make a comment; I think that R's
> behaviour on 'edge' cases like this is an important thing
> and it's great that you are working on it.
> I make heavy use of
OK. It is sort of fixed and sort of works.
We'll keep it for now, but this is not going to work forever. When
namazu fails completely I will not have the time to install a new
search engine.
One option is to use google. For a site like this, I think they will
want some money, but I'm not sure,
> You are not enumerating your trade-offs very well. There are natural
> conflicts. What is you really want?
>
> - Being able to pre-build and distribute? We have done that since the last
> 5C1990s with .deb packages.
>
> - Being able to install with minimal size? Have you queried your users?
21 matches
Mail list logo