From emil@bode @ending from d@n@@kn@w@nl  Tue Jul  3 15:46:58 2018
From: emil@bode @ending from d@n@@kn@w@nl (Emil Bode)
Date: Tue, 3 Jul 2018 13:46:58 +0000
Subject: [Rd] Inconsistencies when extracting with non-integer numeric
 indices near zero
Message-ID: <844EE523-2D01-4856-9A9E-1384C5DEE597@dans.knaw.nl>

Dear R-devel,

When I was playing around with different kind of indices when subsetting I noticed some unexpected behaviours when using non-integer numeric indices, especially near zero.
From the docs: ?Numeric values are coerced to integer as by as.integer<http://127.0.0.1:14277/help/library/base/help/as.integer> (and hence truncated towards zero).?
But some behaviour differs from that, and the behaviour also differs between [ and [[ :
c(1,2)[as.integer(.5)]               --> numeric(0) # As expected
c(1,2)[.5]                                 --> numeric(0) # As expected
c(1,2)[[as.integer(.5)]]            --> Error in c(1, 2)[[as.integer(0.5)]] : attempt to select less than one element in integerOneIndex # Also as expected
c(1,2)[[.5]]                               --> [1] 1            # Not so expected
c(1,2)[[1.5]]                             --> [1] 1            # As expected, but this also means somevector[[n]] and somevector[[n+1]] give back the same element for 0<n<1
c(1,2)[[as.integer(-1.5)]]         --> [1] 2            # As would be expected, though negative subscript for [[ is of course sketchy
c(1,2)[[-1.5]]                            --> [1] 1            # But coerced to -2 is the last thing I?d expect
c(1,2)[as.integer(-.5)]             --> numeric(0) # As expected
c(1,2)[-.5]                                --> [1] 2            # Coerced to -1?, this also means that length(union(c(1,2)[-n], c(1,2)[n])) != 2 for -1<n<1
c(1,2)[-1.5]                              --> [1] 2            # Again as expected, but same problem as before: indexing with n and n+1 can give same element back.

I suspect most of this behaviour is due to the case of special treatment of zero, where first 0-indices are dropped, and only then the casting to integer is done, and when that returns zero some unforeseen behaviour occurs.
Along with using negative indices when extracting with [[, which in any case only succeeds with length-2 vectors (We need a length-one index resulting in the return of a single element). For the last case I?d think we?d do best in throwing an error whenever negative indices are used with [[, but for other cases I think we need to change the underlying code, or at the very least update documentation.
Any thoughts?

Best regards,
Emil Bode

Data-analyst

+31 6 43 83 89 33
emil.bode at dans.knaw.nl<mailto:emil.bode at dans.knaw.nl>

DANS: Netherlands Institute for Permanent Access to Digital Research Resources
Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 | info at dans.knaw.nl<mailto:info at dans.kn> | dans.knaw.nl<applewebdata://71F677F0-6872-45F3-A6C4-4972BF87185B/www.dans.knaw.nl>
DANS is an institute of the Dutch Academy KNAW<http://knaw.nl/nl> and funding organisation NWO<http://www.nwo.nl/>.

	[[alternative HTML version deleted]]



[Rd] Inconsistencies when extracting with non-integer numeric indices near zero
Emil Bode