Bug 15552 - parallel:::splitIndicies returns wrong value for zero-valued inputs
parallel:::splitIndicies returns wrong value for zero-valued inputs
Status: RESOLVED FIXED
Product: R
Classification: Unclassified
Component: Low-level
R-devel (trunk)
All All
: P5 minor
Assigned To: R-core
: 15658 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-11 13:22 UTC by Richard Cotton
Modified: 2014-02-05 21:25 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Cotton 2013-11-11 13:22:39 UTC
I would expect parallel:::splitIndices(0L, ncl) to return integer(0).  Instead, it returns a list, some of whose elements contain a value.

parallel:::splitIndices(0L, 4)
[[1]]
[1] 0

[[2]]
integer(0)

[[3]]
integer(0)

[[4]]
[1] 1

This appears to be an instance of the common 1:n-where-n-is-0 bug.

Changing the line i <- 1L:nx to i <- seq_len(nx) provides a fix.

A related problem is when the ncl input is zero.  It isn't entirely clear if clusters with no nodes should be allowed, and some thought about how they are handled throughout the package is needed.  In the meantime, since makeCluster currently permits clusters with zero nodes, splitIndices needs to deal with that possibility.  Here's a suggested update to the function:

splitIndices <- function(nx, ncl) 
{
    if(ncl < 1) return(list())
    i <- seq_len(nx)
    if (ncl == 1L || nx <= 1L) 
        i
    else {
        fuzz <- min((nx - 1L)/1000, 0.4 * nx/ncl)
        breaks <- seq(1 - fuzz, nx + fuzz, length = ncl + 1L)
        structure(split(i, cut(i, breaks)), names = NULL)
    }
}

Some tests:

x <- splitIndices(5, 4)
stopifnot(
  identical(length(x), 4L),
  identical(length(unlist(x)), 5L),
  identical(splitIndices(0, 4), integer()),
  identical(splitIndices(5, 0), list()),
  identical(splitIndices(0, 0), list())
)
Comment 1 Luke Tierney 2013-11-12 20:22:02 UTC
Improved in R-devel and R-patched
Comment 2 Brian Ripley 2014-02-05 21:25:45 UTC
*** Bug 15658 has been marked as a duplicate of this bug. ***