Add support for fancy indexing on get/setitem #725

jni · 2021-04-28T07:47:50Z

Addresses #657

This matches NumPy behaviour in that basic, boolean, and vectorized integer (fancy) indexing are all accessible from __{get,set}item__. Users still have access to all the indexing methods if they want to be sure to use only basic indexing (integer + slices).

I'm not 100% sure about the approach, but it seemed much easier to use a try/except than to try to detect all the cases when fancy indexing should be used. Happy to hear some guidance about how best to arrange that.

I still need to update docstrings + docs, will do that now — thanks for the checklist below. 😂

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/tutorial.rst
Changes documented in docs/release.rst
GitHub Actions have all passed
Test coverage is 100% (Codecov passes)

pep8speaks · 2021-04-28T07:47:53Z

Hello @jni! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2021-10-19 19:51:41 UTC

jni · 2021-04-28T08:05:27Z

Questions for maintainers:

how to update release.rst
do I need to update any of the notebooks? git grep "unsupported selection item for basic indexing" has some hits in there.
have I missed anything?

Thanks! 😊 Here's a picture of me painting into a zarr array with napari. 😃

joshmoore · 2021-04-28T08:11:59Z

how to update release.rst

Add a commit like 03dce69 to this PR?

jni · 2021-04-28T10:02:21Z

But is the next version 2.8.2 or 2.9? =) Or 3.0! Surely this momentous change merits such an upgrade. 😂

joshmoore · 2021-04-28T15:11:30Z

🙄 (:smile:)

I'd think 2.8.2 but could get behind 2.9 as well.

codecov · 2021-04-28T19:30:44Z

Codecov Report

Merging #725 (cf9051c) into master (4f8cb35) will increase coverage by 0.00%.
The diff coverage is 100.00%.

❗ Current head cf9051c differs from pull request most recent head b9c8f59. Consider uploading reports for the commit b9c8f59 to get more accurate results

@@           Coverage Diff           @@
##           master     #725   +/-   ##
=======================================
  Coverage   99.94%   99.94%           
=======================================
  Files          31       31           
  Lines       10936    10986   +50     
=======================================
+ Hits        10930    10980   +50     
  Misses          6        6

Impacted Files	Coverage Δ
zarr/core.py	`100.00% <100.00%> (ø)`
zarr/indexing.py	`100.00% <100.00%> (ø)`
zarr/tests/test_indexing.py	`100.00% <100.00%> (ø)`

jakirkham · 2021-04-28T20:44:02Z

Yeah 2.9 makes sense. It's a new feature to some extent

Am hoping that 3.0 will also be when we are using the v3 spec 😉

jni · 2021-04-29T00:58:51Z

Ok, all done. I used 2.9.0 based on @jakirkham's logic that enhancements belong in minor version bumps, not patch. This should be ready for a full review now. 🙏

jni · 2021-05-04T00:32:20Z

kind ping! 🙏 Just rebased on latest master.

joshmoore · 2021-05-04T15:47:43Z

Looking at #657, @shoyer, any thoughts?

joshmoore · 2021-05-04T19:20:24Z

import numpy as np
import pytest as pt
import zarr as zr


@pt.fixture
def na():
    return np.arange(60).reshape((3, 4, 5))


@pt.fixture
def za(na):
    return zr.array(data=na)


def test_base(na, za):
    np.equal(na, za)


def test_base(na, za):
    np.equal(na[0], za[0])
    np.equal(na[1], za[1])
    np.equal(na[2, 3], za[2, 3])


@pt.mark.skip
def test_integer_array(na, za):
    print(na[[0, 0]], za[[0, 0]])


def test_int_arr_arr(na, za):
    x = [0, 0, 0]
    y = [1, 1, 1]
    z = [2, 2, 2]
    np.equal(na[x, y, z], za[x, y, z])


def test_simple(na, za):
    np.equal(na[0, 1, [2, 3]], za[0, 1, [2, 3]])
    np.equal(na[[0, 1], 1, [2, 3]], za[[0, 1], 1, [2, 3]])


@pt.mark.skip
def test_slicing(na, za):
    np.equal(na[1:, 2:, [3, 4]], za[1:, 2:, [3, 4]])

Assuming there are no objections by tomorrow, I'm inclined to move forward with this.

shoyer · 2021-05-04T19:36:49Z

I don't think Zarr should fall back to using vindex. There are some cases where the dimension order from vindex differs from NumPy, so this could perpetuate exactly the sort of confusion we were trying to solve with vindex :).

We could definitely leverage vindex for normal array indexing, but we should be sure reorder dimensions in a way that is consistent with NumPy.

joshmoore · 2021-05-04T19:45:07Z

There are some cases where the dimension order from vindex differs from NumPy,...

Thanks @shoyer. Do you have an example handy? And does this count as a reversal of #657 (comment) ?

shoyer · 2021-05-04T20:17:45Z

There are some cases where the dimension order from vindex differs from NumPy,...

Thanks @shoyer. Do you have an example handy? And does this count as a reversal of #657 (comment) ?

This is probably the canonical edge case:
https://numpy.org/neps/nep-0021-advanced-indexing.html#mixed-indexing

I think I'm being consistent with my previous suggestion to "copy NumPy's behavior for fancy indexing" here :). It's just important to recognize that vindex is not consistent with NumPy's behavior for fancy indexing, in the case where slices and arrays are mixed.

So as long as that edge case is avoided, we could support "array only" fancy indexing. (This would probably be a good place to start.)

Or we could support mixed slice/array indexing, but only if we're careful to re-order array dimensions the same way that NumPy does.

joshmoore · 2021-05-05T08:00:18Z

That matches:

@pt.mark.skip
def test_slicing(na, za):
    np.equal(na[1:, 2:, [3, 4]], za[1:, 2:, [3, 4]])

right? which if I remove the skip fails with

IndexError: unsupported selection item for basic indexing; expected integer or slice, got <class 'list'>

full run

(base) /tmp $pytest -svk slicing t.py
========================================================= test session starts =========================================================
platform darwin -- Python 3.7.6, pytest-6.2.2, py-1.10.0, pluggy-0.13.1 -- /usr/local/anaconda3/bin/python
cachedir: .pytest_cache
rootdir: /private/tmp
plugins: testinfra-3.4.0, napari-plugin-engine-0.1.7
collected 5 items / 4 deselected / 1 selected

t.py::test_slicing FAILED

============================================================== FAILURES ===============================================================
____________________________________________________________ test_slicing _____________________________________________________________

na = array([[[ 0,  1,  2,  3,  4],
        [ 5,  6,  7,  8,  9],
        [10, 11, 12, 13, 14],
        [15, 16, 17, 18, 19]...     [[40, 41, 42, 43, 44],
        [45, 46, 47, 48, 49],
        [50, 51, 52, 53, 54],
        [55, 56, 57, 58, 59]]])
za = <zarr.core.Array (3, 4, 5) int64>

    def test_slicing(na, za):
>       np.equal(na[1:, 2:, [3, 4]], za[1:, 2:, [3, 4]])

t.py:44:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/local/anaconda3/lib/python3.7/site-packages/zarr/core.py:571: in __getitem__
    return self.get_basic_selection(selection, fields=fields)
/usr/local/anaconda3/lib/python3.7/site-packages/zarr/core.py:697: in get_basic_selection
    fields=fields)
/usr/local/anaconda3/lib/python3.7/site-packages/zarr/core.py:737: in _get_basic_selection_nd
    indexer = BasicIndexer(selection, self)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <zarr.indexing.BasicIndexer object at 0x7fc3c8217950>, selection = (slice(1, None, None), slice(2, None, None), [3, 4])
array = <zarr.core.Array (3, 4, 5) int64>

    def __init__(self, selection, array):

        # handle ellipsis
        selection = replace_ellipsis(selection, array._shape)

        # setup per-dimension indexers
        dim_indexers = []
        for dim_sel, dim_len, dim_chunk_len in \
                zip(selection, array._shape, array._chunks):

            if is_integer(dim_sel):
                dim_indexer = IntDimIndexer(dim_sel, dim_len, dim_chunk_len)

            elif is_slice(dim_sel):
                dim_indexer = SliceDimIndexer(dim_sel, dim_len, dim_chunk_len)

            else:
                raise IndexError('unsupported selection item for basic indexing; '
                                 'expected integer or slice, got {!r}'
>                                .format(type(dim_sel)))
E               IndexError: unsupported selection item for basic indexing; expected integer or slice, got <class 'list'>

/usr/local/anaconda3/lib/python3.7/site-packages/zarr/indexing.py:285: IndexError
======================================================= short test summary info =======================================================
FAILED t.py::test_slicing - IndexError: unsupported selection item for basic indexing; expected integer or slice, got <class 'list'>
=================================================== 1 failed, 4 deselected in 4.60s ===================================================
(base) /tmp $

jni · 2021-05-06T06:48:49Z

So as long as that edge case is avoided, we could support "array only" fancy indexing. (This would probably be a good place to start.)

@shoyer I didn't really know the best way to "check" that we were in "array only" fancy indexing mode, since arrays and scalars can be broadcast together. Also, are lists supported?

jni · 2021-05-06T06:49:14Z

or should I just check that there are no instances of slice in the indexing tuple?

shoyer · 2021-05-06T07:40:58Z

or should I just check that there are no instances of slice in the indexing tuple?

NumPy says "When there is at least one slice (:), ellipsis (...) or newaxis in the index (or the array has more dimensions than there are advanced indexes)"
https://numpy.org/doc/stable/reference/arrays.indexing.html#combining-advanced-and-basic-indexing

So this is the case to avoid.

shoyer · 2021-05-06T07:43:01Z

@shoyer I didn't really know the best way to "check" that we were in "array only" fancy indexing mode, since arrays and scalars can be broadcast together. Also, are lists supported?

From NumPy's perspective:

lists are arrays
scalars are arrays if doing "mixed" or "advanced indexing" (if there is at least one other array)

jni · 2021-05-11T02:07:32Z

Ok I think I've caught that case and raised an appropriate error then. Let me know if that meets requirements now! 🤞

shoyer · 2021-05-11T02:17:08Z

zarr/tests/test_indexing.py

+def test_fancy_indexing_doesnt_mix_with_slicing():
+    z = zarr.zeros((20, 20))
+    with pytest.raises(IndexError):
+        z[[1, 2, 3], :] = 2


another case would worth checking would be something like:

z = zarr.zeros((20, 20, 20)) with pytest.raises(IndexError): z[[1, 2, 3], 0] = 2

This doesn't look like mixed indexing but it actually is because of the implicit slice at the end.

great point! 😬 Will work on this.

shoyer · 2021-05-11T02:19:46Z

zarr/core.py

+        try:
+            result = self.get_basic_selection(pure_selection, fields=fields)
+        except IndexError:
+            result = self.vindex[selection]


I think this should probably have the same check you put in __setitem__?

shoyer · 2021-05-11T02:20:12Z

zarr/core.py

+            if (isinstance(pure_selection, tuple)
+                    and any(isinstance(elem, slice) for elem in pure_selection)
+            ):


I think you probably have to "expand" the indexer to a tuple with length equal to the number of array dimensions (i.e., by replacing Ellipsis and padding by slice(None)) in order to determine if vindex will work.

Thanks @shoyer, very good point. Is there a function to do this already in zarr?

actually, how about just checking that the length of the tuple matches the dimension of the array?

Here's a helper I wrote for Xarray:
https://github.com/pydata/xarray/blob/234b40a37e484a795e6b12916315c80d70570b27/xarray/core/indexing.py#L31

Conceivably you could copy it into Zarr as long as you are compliant with the Apache 2.0 license.

There may well be something like this in Zarr already, I'm not too familiar with the Zarr codebase here.

jni · 2021-05-11T09:16:09Z

Ok, take 3. 😂 This time I went with an explicit check for fancy indexing rather than a fallback, now that I understand the exact requirements better.

For the curious, the if-statement adds 8µs to the indexing operation, which normally takes about 150µs at least (that's when everything is in-memory and we are grabbing a single value), for a ~5% worst-case slowdown. I hope that's acceptable.

In [6]: arr = zarr.zeros((5, 5))

In [7]: %timeit arr[0, 1] = 4
157 µs ± 5.87 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [8]: idx.is_pure_fancy_indexing((0, 1), 2)
Out[8]: False

In [9]: %timeit idx.is_pure_fancy_indexing((0, 1), 2)
8.42 µs ± 430 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

Two other questions:

It turns out that zarr.indexing.is_integer(x) returns True for bools. Is this desired/expected? Or should I add a check to exclude them explicitly?
For lists, I have only added a check that the first element is an int, since I don't think we want a check to take O(n) time. Alternatives welcome.

jni · 2021-05-12T02:29:28Z

not sure why the CI isn't running, too... 🤷

jni · 2021-05-12T02:33:11Z

nvmd just read the notice on top of the checks. 🤦

jni · 2021-05-31T04:51:20Z

Ok I've rebased on master. The failure in the previous CI run was:

assert a[42] == z[np.uint64(42)] in TestArrayWithFSStorePartialRead.test_array_1d

________________ TestArrayWithFSStorePartialRead.test_array_1d _________________

self = <zarr.tests.test_core.TestArrayWithFSStorePartialRead testMethod=test_array_1d>

    def test_array_1d(self):
        a = np.arange(1050)
        z = self.create_array(shape=a.shape, chunks=100, dtype=a.dtype)
    
        # check properties
        assert len(a) == len(z)
        assert a.ndim == z.ndim
        assert a.shape == z.shape
        assert a.dtype == z.dtype
        assert (100,) == z.chunks
        assert a.nbytes == z.nbytes
        assert 11 == z.nchunks
        assert 0 == z.nchunks_initialized
        assert (11,) == z.cdata_shape
    
        # check empty
        b = z[:]
        assert isinstance(b, np.ndarray)
        assert a.shape == b.shape
        assert a.dtype == b.dtype
    
        # check attributes
        z.attrs['foo'] = 'bar'
        assert 'bar' == z.attrs['foo']
    
        # set data
        z[:] = a
    
        # check properties
        assert a.nbytes == z.nbytes
        assert 11 == z.nchunks
        assert 11 == z.nchunks_initialized
    
        # check slicing
        assert_array_equal(a, np.array(z))
        assert_array_equal(a, z[:])
        assert_array_equal(a, z[...])
        # noinspection PyTypeChecker
        assert_array_equal(a, z[slice(None)])
        assert_array_equal(a[:10], z[:10])
        assert_array_equal(a[10:20], z[10:20])
        assert_array_equal(a[-10:], z[-10:])
        assert_array_equal(a[:10, ...], z[:10, ...])
        assert_array_equal(a[10:20, ...], z[10:20, ...])
        assert_array_equal(a[-10:, ...], z[-10:, ...])
        assert_array_equal(a[..., :10], z[..., :10])
        assert_array_equal(a[..., 10:20], z[..., 10:20])
        assert_array_equal(a[..., -10:], z[..., -10:])
        # ...across chunk boundaries...
        assert_array_equal(a[:110], z[:110])
        assert_array_equal(a[190:310], z[190:310])
        assert_array_equal(a[-110:], z[-110:])
        # single item
        assert a[0] == z[0]
        assert a[-1] == z[-1]
        # unusual integer items
        assert a[42] == z[np.int64(42)]
        assert a[42] == z[np.int32(42)]
>       assert a[42] == z[np.uint64(42)]

zarr/tests/test_core.py:212: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
zarr/core.py:675: in __getitem__
    result = self.vindex[selection]
zarr/indexing.py:818: in __getitem__
    return self.array.get_coordinate_selection(selection, fields=fields)
zarr/core.py:1032: in get_coordinate_selection
    out = self._get_selection(indexer=indexer, out=out, fields=fields)
zarr/core.py:1141: in _get_selection
    self._chunk_getitems(lchunk_coords, lchunk_selection, out, lout_selection,
zarr/core.py:1868: in _chunk_getitems
    self._process_chunk(
zarr/core.py:1752: in _process_chunk
    index_selection = PartialChunkIterator(chunk_selection, self.chunks)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <zarr.indexing.PartialChunkIterator object at 0x7f1ef83bec70>
selection = [slice(42, 43.0, 1)], arr_shape = (100,)

    def __init__(self, selection, arr_shape):
        selection = make_slice_selection(selection)
        self.arr_shape = arr_shape
    
        # number of selection dimensions can't be greater than the number of chunk dimensions
        if len(selection) > len(self.arr_shape):
            raise ValueError(
                "Selection has more dimensions then the array:\n"
                f"selection dimensions = {len(selection)}\n"
                f"array dimensions = {len(self.arr_shape)}"
            )
    
        # any selection can not be out of the range of the chunk
>       selection_shape = np.empty(self.arr_shape)[tuple(selection)].shape
E       TypeError: slice indices must be integers or None or have an __index__ method

zarr/indexing.py:958: TypeError

which I can't reproduce locally:

 $ pytest zarr/tests/test_core.py::TestArrayWithFSStorePartialRead
============================= test session starts ==============================
platform darwin -- Python 3.8.2, pytest-6.2.2, py-1.10.0, pluggy-0.13.1
PySide2 5.14.2.1 -- Qt runtime 5.14.2 -- Qt compiled 5.14.2
rootdir: /Users/jni/projects/zarr-python, configfile: pytest.ini
plugins: timeout-1.3.4, localserver-0.5.0, napari-plugin-engine-0.1.9, hypothesis-6.0.0, mypy-plugins-1.6.1, ordering-0.6, order-0.11.0, qt-3.3.0, cov-2.8.1, napari-0.4.8.dev133+g46f295b5
collected 48 items

zarr/tests/test_core.py ................................................ [100%]

I hope this run passes but if not, any suggestions about what is going on are most welcome!

jni · 2021-05-31T06:00:12Z

... Nope. 😭 Anyone got any ideas?

self.shape is a property that hides a lot of computation, and, more importantly, it can be waiting for an update and so .ndim *cannot* be accessed during a reshape/append. See: zarr-developers#725 (comment) This should prevent that behavior.

jni · 2021-09-29T05:45:30Z

@joshmoore 🎉 🎉 🎉 Probably should have done this a while back. 😂 I'll revert the pytest commits and then hopefully 🤞 this can go in?

jni · 2021-09-29T05:46:36Z

... Or maybe we want to keep the timeouts? They're kinda handy.

joshmoore

Latest changes & test status are looking good. Also bubbling up #725 (comment) in case there were any opinions:

For the curious, the if-statement adds 8µs to the indexing operation, which normally takes about 150µs at least (that's when everything is in-memory and we are grabbing a single value), for a ~5% worst-case slowdown. I hope that's acceptable.

joshmoore · 2021-10-08T06:31:43Z

zarr/core.py

@@ -340,7 +341,7 @@ def attrs(self):
    @property
    def ndim(self):
        """Number of dimensions."""
-        return len(self.shape)
+        return len(self._shape)


Note from zulip: this fixed the weird timeout issue, though we still don't know why the deadlock was platform specific.

joshmoore · 2021-10-19T19:52:57Z

Merging now that 2.10.2 is released (fixing #840). I'll look into getting a 2.11rc1 released soon.

jni · 2021-10-20T00:35:47Z

🎉:rocket:!!!!

* Fall back on .vindex when basic indexing fails Addresses #657 This matches NumPy behaviour in that basic, boolean, and vectorized integer (fancy) indexing are all accessible from `__{get,set}item__`. Users still have access to all the indexing methods if they want to be sure to use only basic indexing (integer + slices). * Fix basic selection test now with no IndexError * Fix basic_selection_2d test with no vindex error * Add specific test for fancy indexing fallback * Update get/setitem docstrings * Update tutorial.rst * PEP8 fix * Rename test array to z as in other tests * Add release note * Avoid mixing slicing and array indexing in setitem * Actually test for fancy index rather than try/except * Add check for 1D fancy index (no tuple) * Add tests for implicit fancy indexing, and getitem * Add expected blank line * Add strict test for make_slice_selection * Ensure make_slice_selection returns valid NumPy slices * Make pytest verbose to see what is failing in windows * Add 5 min per-test timeout * Use private self._shape when determining ndim self.shape is a property that hides a lot of computation, and, more importantly, it can be waiting for an update and so .ndim *cannot* be accessed during a reshape/append. See: zarr-developers/zarr-python#725 (comment) This should prevent that behavior. Co-authored-by: Josh Moore <[email protected]>

jni force-pushed the fancy-indexing branch from ccb4b05 to 582f430 Compare May 4, 2021 00:32

joshmoore mentioned this pull request May 4, 2021

Expand (and pass) nested FSStore tests #709

Merged

6 tasks

shoyer reviewed May 11, 2021

View reviewed changes

jni force-pushed the fancy-indexing branch from eb39593 to 1aa575d Compare May 18, 2021 10:20

jni force-pushed the fancy-indexing branch from 1aa575d to ce04dd3 Compare May 31, 2021 04:49

jni added 10 commits September 29, 2021 15:26

Avoid mixing slicing and array indexing in setitem

769c364

Actually test for fancy index rather than try/except

2e87b53

Add check for 1D fancy index (no tuple)

b0504c5

Add tests for implicit fancy indexing, and getitem

a03f9e2

Add expected blank line

92faf42

Add strict test for make_slice_selection

b4ea006

Ensure make_slice_selection returns valid NumPy slices

2a4fa96

Make pytest verbose to see what is failing in windows

208050c

Add 5 min per-test timeout

4e7733c

jni force-pushed the fancy-indexing branch from e0c67ee to 2f5df3e Compare September 29, 2021 05:27

jni requested review from joshmoore and shoyer October 2, 2021 02:23

Merge branch 'master' into fancy-indexing

cf9051c

joshmoore approved these changes Oct 8, 2021

View reviewed changes

shoyer approved these changes Oct 11, 2021

View reviewed changes

Merge branch 'master' into fancy-indexing

b9c8f59

joshmoore merged commit 7c31f04 into zarr-developers:master Oct 19, 2021

joshmoore mentioned this pull request Oct 19, 2021

Optimize setitem with chunk equal to fill_value, round 2 #738

Merged

6 tasks

jni deleted the fancy-indexing branch October 20, 2021 00:35

jni mentioned this pull request Oct 20, 2021

Request for fancy indexing #657

Closed

jakirkham mentioned this pull request Dec 1, 2021

Blogpost for Zarr 2.11 #901

Closed

jni mentioned this pull request Jan 27, 2022

Default write empty chunks false #951

Closed

jakirkham mentioned this pull request Feb 8, 2022

Feature Request: Advanced indexing without oindex and vindex #926

Closed

jni mentioned this pull request May 18, 2022

indexing with list not supported #1029

Closed

Add support for fancy indexing on get/setitem #725

Add support for fancy indexing on get/setitem #725

Conversation

jni commented Apr 28, 2021 • edited Loading

pep8speaks commented Apr 28, 2021 • edited Loading

Comment last updated at 2021-10-19 19:51:41 UTC

jni commented Apr 28, 2021

joshmoore commented Apr 28, 2021

jni commented Apr 28, 2021

joshmoore commented Apr 28, 2021

codecov bot commented Apr 28, 2021 • edited Loading

Codecov Report

jakirkham commented Apr 28, 2021

jni commented Apr 29, 2021

jni commented May 4, 2021

joshmoore commented May 4, 2021

joshmoore commented May 4, 2021

shoyer commented May 4, 2021

joshmoore commented May 4, 2021

shoyer commented May 4, 2021

joshmoore commented May 5, 2021 • edited Loading

jni commented May 6, 2021

jni commented May 6, 2021

shoyer commented May 6, 2021

shoyer commented May 6, 2021

jni commented May 11, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jni commented May 11, 2021

jni commented May 12, 2021

jni commented May 12, 2021

jni commented May 31, 2021 • edited Loading

jni commented May 31, 2021

jni commented Sep 29, 2021

jni commented Sep 29, 2021

joshmoore left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joshmoore commented Oct 19, 2021

jni commented Oct 20, 2021

jni commented Apr 28, 2021 •

edited

Loading

pep8speaks commented Apr 28, 2021 •

edited

Loading

codecov bot commented Apr 28, 2021 •

edited

Loading

joshmoore commented May 5, 2021 •

edited

Loading

jni commented May 31, 2021 •

edited

Loading