Is this a bug in `[`?

This should more clearly illustrate the issue:

c(1, 2, 3, 4)[-seq_len(4)]
#> numeric(0)
c(1, 2, 3, 4)[-seq_len(3)]
#> [1] 4
c(1, 2, 3, 4)[-seq_len(2)]
#> [1] 3 4
c(1, 2, 3, 4)[-seq_len(1)]
#> [1] 2 3 4
c(1, 2, 3, 4)[-seq_len(0)]
#> numeric(0)
Created on 2018-08-05 by the reprex package (v0.2.0.9000).

On Sun, Aug 5, 2018 at 3:58 AM Rui Barradas <ruipbarradas at sapo.pt> wrote:

?s 15:51 de 04/08/2018, I?aki ?car escreveu:

El s?b., 4 ago. 2018 a las 15:32, Rui Barradas
(<ruipbarradas at sapo.pt>) escribi?:

Hello,

Maybe I am not understanding how negative indexing works but

1) This is right.

(1:10)[-1]
#[1]  2  3  4  5  6  7  8  9 10

2) Are these right? They are at least surprising to me.

(1:10)[-0]
#integer(0)

(1:10)[-seq_len(0)]
#integer(0)


It was the last example that made me ask, seq_len(0) whould avoid an
if/else or something similar.

I think it's ok, because there is no negative zero integer, so -0 is 0.

Ok, this makes sense, I should have thought about that.

1.0/-0L # Inf
1.0/-0.0 # - Inf

And the same can be said for integer(0), which is the result of
seq_len(0): there is no negative empty integer.

I'm not completely convinced about this one, though.
I would expect -seq_len(n) to remove the first n elements from the
vector, therefore, when n == 0, it would remove none.

And integer(0) is not the same as 0.

(1:10)[-0] == (1:10)[0] == integer(0) # empty

(1:10)[-seq_len(0)] == (1:10)[-integer(0)]


And I have just reminded myself to run

identical(-integer(0), integer(0))

It returns TRUE so my intuition is wrong, R is right.
End of story.

Thanks for the help,

Rui Barradas

I?aki

Thanks in advance,

Rui Barradas