Repository navigation
tile_arange() drops the last element when the range is not an exact multiple of the step #1774
Description
Bug Description
wp.tile_arange() mirrors numpy.arange() in name, signature and exclusive-stop convention, but
computes its length with truncating division instead of ceil. Any range whose span is not an exact
multiple of step therefore silently loses its final element.
Repro
import numpy as np, warp as wp
@wp.kernel
def k(out: wp.array[wp.int32]):
t = wp.tile_arange(0, 10, 3, dtype=int)
wp.tile_store(out, t)
out = wp.zeros(4, dtype=wp.int32)
wp.launch_tiled(k, dim=1, outputs=[out], block_dim=32)
print(out.numpy(), "vs", np.arange(0, 10, 3))The length is decided in Python at codegen time, so it can also be checked without a device:
>>> int((10 - 0) / 3) # tile_arange_value_func
3
>>> len(np.arange(0, 10, 3))
4Observed
| range | tile_arange |
numpy.arange |
|---|---|---|
(0, 10, 3) |
3 â [0, 3, 6] |
4 â [0, 3, 6, 9] |
(0, 5, 2) |
2 â [0, 2] |
3 â [0, 2, 4] |
(10, 0, -3) |
3 â [10, 7, 4] |
4 â [10, 7, 4, 1] |
(0, 9, 3) |
3 | 3 â |
(0, 10, 1) |
10 | 10 â |
Floating-point ranges are exposed twice over, because the same expression also inherits binary
rounding: (0.3 - 0.0) / 0.1 == 2.9999999999999996, so wp.tile_arange(0.0, 0.3, 0.1) yields 2
elements where numpy.arange yields 3.
Root cause
tile_arange_value_func() in warp/_src/builtins.py sizes the tile with
n = int((stop - start) / step)int() truncates, while arange semantics require ceil((stop - start) / step). The two agree only
when the span divides evenly by the step. The native tile_arange then fills start + i * step for
i < n, so the shortfall comes entirely from this length.
This is not a regression: the identical expression existed in the pre-refactor TileRange type, so
the behavior dates from the introduction of tile_arange.
Expected
wp.tile_arange(start, stop, step) should produce ceil((stop - start) / step) elements, matching
numpy.arange(), rather than silently discarding the last one.
Activity
christophercrouzet commentedon Sep 13, 2026
Addressed in 69b75e2.
shi-eric commentedon Sep 13, 2026
This is addressed by 69b75e2.
wp.tile_arange()now computes the element count with ceiling semantics at the output element type. Ascending and descending ranges whose spans are not exact multiples of their steps retain the final element belowstop, floating-point ranges such as(0.0, 0.3, 0.1)produce the expected count, and exact-multiple ranges remain unchanged.The issue is already closed as completed; this comment adds the full implementation and verification record without changing its state.
Public API behavior
Kernel scope
wp.tile_arange()builtin now sizes non-empty half-open ranges consistently with the values representable by the output element type.Test coverage
warp/tests/tile/test_tile_construction.pycovers ascending and descending integer ranges, floating-point ranges, one-, two-, and three-argument forms, exact multiples, output-type rounding, extreme bounds, constant handling, and invalid-call diagnostics across CPU and CUDA.warp/tests/test_constant_precision.pyverifies that converting a literal for a typed call does not alter later uses of the caller's constant.warp/tests/tile/test_tile_struct.pyverifies thattile_arange()rejects a nonnumeric struct element type with the expected diagnostic.Behavioral verification
A targeted reproduction of the reported integer and floating-point ranges passed on CPU and CUDA. Register and shared storage both produced the complete expected ranges without omitting or adding elements.
Related tile-shape validation
wp.tile_zeros(),wp.tile_ones(),wp.tile_empty(),wp.tile_full(), andwp.tile_load().wp.tile_arange()only. For the remaining APIs,shape=0is accepted on CPU without writing output, while equivalent CUDA kernels fail during compilation.Fix tile_arange() dropping the last element [NVIDIAGH-1774]