ENH: nullable Float32/64 ExtensionArray #34307

jorisvandenbossche · 2020-05-22T11:18:22Z

As proposed at #32265 (comment), this is adding a float extension dtype and array (for now avoiding/ignoring the NaN-discussion), using the masked array approach following our other nullable dtypes.

Brief overview:

This PR adds a FloatingArray and Float32Dtype / Float64Dtype (similar as for the nullable integer dtypes)
I am using the "Float64" pattern with capital "F" as name for the dtype to distinguish the string name of the "float64" dtype from numpy (consistent with Int64 etc)
For now I only added Float32 and Float64 (we can see later if we want to add others like float16)
Upon conversion of input (both in construction as in operations such as setitem), any np.nan is coerced to NA (we can see later to add an option / config for this)
The added tests are for now mostly copied from the existing integer/boolean tests, and adapted for Float

It directly uses some of the masked ops I implemented earlier for IntegerArray, which means that eg sum already shows a similar perf benefit:

a = np.random.randn(1_000_000) 
a[np.random.randint(0, 1_000_000, 100)] = np.nan 
s1 = pd.Series(a)
s2 = pd.Series(a, dtype="Float64")

In [6]: np.allclose(s1.sum(), s2.sum()) 
Out[6]: True

# numpy float series
In [7]: %timeit s1.sum()   
2.73 ms ± 104 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

# nullable float series
In [8]: %timeit s2.sum()   
875 µs ± 18.3 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

Still to do:
- Add whatsnew + docs
- Division with Int64 dtype can now result in nullable Float Dtype instead of numpy float array
Other todo's but that can probably be left for follow-up PRs:
- Update the convert_dtypes method to also return nullable floats (one question here: what with floats that are all "integer"-like? I think we want to keep returning nullable int for that, but we might want to add a parameter controlling that behaviour?)
- Some more arithmetical operations with IntegerArray/BooleanArray can now return a FloatingArray instead of numpy float array
- Ufuncs on IntegerArray/BooleanArray can return FloatingArray, ufuncs on mixture of IntegerArray/FloatArray
- Consolidate some tests that are common for integer/boolean/float
- Deduplicate more things between the Array classes and move to BaseMaskedArray (eg the arithmetic / comparison ops can probably be moved with a bit of refactoring)
  - __from_arrow__
  - ufuncs
  - coerce_to_array, but this will probably require some refactoring
- formatting options

Dr-Irv · 2020-05-22T15:49:25Z

pandas/tests/arrays/floating/test_arithmetic.py

+    def test_divide_by_zero(self, zero, negative):
+        # TODO pending NA/NaN discussion
+        # https://github.com/pandas-dev/pandas/issues/32265/
+        a = pd.array([0, 1, -1, None], dtype="Float64")


for this and other tests, shouldn't you also test dtype Float32 ?

Dr-Irv · 2020-05-22T15:50:24Z

pandas/tests/arrays/floating/test_arithmetic.py

+        tm.assert_extension_array_equal(result, expected)
+
+
+def test_cross_type_arithmetic():


Do you need to add tests for arithmetic with pd.NA ?

pandas/tests/arrays/floating/test_to_numpy.py

dsaxton · 2020-05-22T20:05:56Z

pandas/tests/arrays/floating/test_arithmetic.py

+        a = pd.array([0, 0, 0, 1, 1, 1, None, None, None], dtype="Float64")
+        b = pd.array([0, 1, None, 0, 1, None, 0, 1, None], dtype="Float64")
+        result = a ** b
+        expected = pd.array([1, 0, None, 1, 1, 1, 1, None, None], dtype="Float64")


Is it also worth testing cases where Float is raised to an Int power and Int to a Float power (the latter case should I think become Float)?

dsaxton · 2020-05-22T20:15:31Z

pandas/tests/arrays/floating/test_arithmetic.py

+    def test_rpow_one_to_na(self):
+        # https://github.com/pandas-dev/pandas/issues/22022
+        # https://github.com/pandas-dev/pandas/issues/29997
+        arr = pd.array([np.nan, np.nan], dtype="Float64")


If later NaN and NA are distinguishable in this context could it make sense to use None or NA explicitly in these tests (it wouldn't actually matter in this specific case but still)?

pep8speaks · 2020-05-29T13:07:24Z

Hello @jorisvandenbossche! 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 2020-09-30 08:18:27 UTC

jorisvandenbossche · 2020-05-29T13:31:47Z

@dsaxton @Dr-Irv thanks for the comments!
For your comments on test_arithmetic.py, that's mostly because I copied those from the integer tests, and it was done like that there as well. Not a reason to improve it of course ;), but I am completely refactoring those arithmetic tests for integer (#34454), and if that goes through, will do the same here.

And we indeed also need to start having tests where those dtypes are mixed (eg Int64 with Float64)

jorisvandenbossche · 2020-05-29T13:40:44Z

cc @pandas-dev/pandas-core

dsaxton · 2020-05-29T17:19:14Z

pandas/tests/arrays/floating/test_arithmetic.py

+        tm.assert_extension_array_equal(result, expected)
+
+        # reversed
+        a = a[1:]  # Can't raise integers to negative powers.


Shouldn't this be possible, with the result now being a FloatingArray? Do we also want to test raising float values (other than NaN) to a FloatingArray power, maybe including fractional values in the exponent?

WillAyd · 2020-05-29T18:33:07Z

pandas/core/arrays/floating.py

+        if not all(isinstance(t, _FloatingDtype) for t in dtypes):
+            return None
+        np_dtype = np.find_common_type(
+            [t.numpy_dtype for t in dtypes], []  # type: ignore


what error was this producing?

@WillAyd This was added in #33607.
The problem is that by doing the if not all(isinstance(t, _FloatingDtype) for t in dtypes): return None, we know that by ending up here, we have a list of all FloatingDtype dtypes (which have a numpy_dtype attribute). But mypy doesn't know this.
A cast(List[_FloatingDtype], dtypes) might help?

pandas/core/arrays/floating.py

TomAugspurger

Are you planning to deduplicate with IntegerArray before or after merging this? I noted a couple places, but there's plenty more that could be done.

TomAugspurger · 2020-05-29T18:26:27Z

pandas/core/arrays/floating.py

+.. versionchanged:: 1.0.0
+
+   Now uses :attr:`pandas.NA` as its missing value,
+   rather than :attr:`numpy.nan`.


Don't need this versionchanged.

pandas/core/arrays/floating.py

TomAugspurger · 2020-05-29T18:33:13Z

pandas/core/arrays/floating.py

+        scalars = to_numeric(strings, errors="raise")
+        return cls._from_sequence(scalars, dtype, copy)
+
+    _HANDLED_TYPES = (np.ndarray, numbers.Number)


Need to think about ops involving a mix of our extension arrays something like

np.add(FloatingArray, IntegerArray)

How feasible is an __array_ufunc__ on a base class of FloatingArray & IntegerArray?

Yes, right now you get a TypeError when calling numpy ufuncs on a mixture of integer / floating arrays. Noted that as a follow-up item.

TomAugspurger · 2020-05-29T18:34:16Z

pandas/core/arrays/floating.py

+            result = self._data.astype(dtype.numpy_dtype, copy=False)
+            return type(self)(result, mask=self._mask, copy=False)


Why are these both copy=False? Shouldn't the first be copy=copy?

Good catch, we currently also do incorrectly for IntegerDtype ..

Fix for the integer case -> #34931 (can copy that over here once the other is merged)

pandas/core/arrays/string_.py

TomAugspurger · 2020-05-29T18:39:45Z

pandas/core/construction.py

@@ -319,6 +331,9 @@ def array(
        elif inferred_dtype == "integer":
            return IntegerArray._from_sequence(data, copy=copy)

+        elif inferred_dtype == "floating":


Maybe handle mixed-integer-float too?

In [11]: pd._libs.lib.infer_dtype([1., np.nan, 2]) Out[11]: 'mixed-integer-float' In [12]: pd._libs.lib.infer_dtype([1., 2]) Out[12]: 'mixed-integer-float'

jorisvandenbossche · 2020-06-01T12:23:13Z

@TomAugspurger @WillAyd regarding sharing code with the other masked arrays (it's not only with integer, but also with boolean): yes, this certainly needs to happen.

There are plenty of things that should be shared (some will need a bit of refactoring). See also the last todo item in the top post. I have noted some more things to be shared, and I also actually already started deduplicating some things that I noticed while preparing this PR that could easily be done prior to this PR: #34187, #34308 (there are also other things that could be done prior, I think).
(and I also started refactoring the arithmetic tests, with one of the goals to make it easier to share them: #34454)

But about doing those in this PR: I have a slight preference to not do this. First, because it won't actually make the diff of this PR smaller, but rather more complex (as it would involve moving things from integer.py to one of the other files). So it won't necessarily make it easier to review this PR.
And second, because some of those need a bit of refactoring to properly share things. That will certainly be for the better, but it might be cleaner / clearer to do this in separate, more focused PRs (eg rewriting the ufunc machinery, rewriting the integer/float_arithmetic_ops, .. I would rather do those in separate PRs).

(and I am also commited to actually doing such follow-ups, like I already started doing some PRs prior to this)

For things that are straight copy-paste and require no changes, those can certainly be done here (or in a pre-cursor PR).

TomAugspurger · 2020-06-01T12:43:35Z

I'm happy to have the deduplication done as followups. That's easier for me to understand than abstracting things ahead of time.

…

On Mon, Jun 1, 2020 at 7:23 AM Joris Van den Bossche < ***@***.***> wrote: @TomAugspurger <https://github.com/TomAugspurger> @WillAyd <https://github.com/WillAyd> regarding sharing code with the other masked arrays (it's not only with integer, but also with boolean): yes, this certainly needs to happen. There are plenty of things that should be shared (some will need a bit of refactoring). See also the last todo item in the top post. I have noted some more things to be shared, and I also actually already started deduplicating some things that I noticed while preparing this PR that could easily be done prior to this PR: #34187 <#34187>, #34308 <#34308> (there are also other things that could be done prior, I think). (and I also started refactoring the arithmetic tests, with one of the goals to make it easier to share them: #34454 <#34454>) But about doing those in *this* PR: I have a slight preference to not do this. First, because it won't actually make the diff of this PR smaller, but rather more complex (as it would involve moving things from integer.py to one of the other files). So it won't necessarily make it easier to review this PR. And second, because some of those need a bit of refactoring to properly share things. That will certainly be for the better, but it might be cleaner / clearer to do this in separate, more focused PRs (eg rewriting the ufunc machinery, rewriting the integer/float_arithmetic_ops, .. I would rather do those in separate PRs). (and I am also commited to actually doing such follow-ups, like I already started doing some PRs prior to this) For things that are straight copy-paste and require no changes, those can certainly be done here (or in a pre-cursor PR). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#34307 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKAOITHDGMYPAFVKC6RBV3RUOMUBANCNFSM4NHWOC7Q> .

jreback

i will look soon

jbrockmendel · 2020-06-16T15:52:14Z

%timeit s1.sum()

Out of curiosity, what is driving the improved perf here?

jorisvandenbossche · 2020-06-19T09:53:39Z

@jbrockmendel it's mostly due to avoiding using the "nan.." versions (eg nansum is quite a bit slower as sum. See also #34773).

I think there are mostly two reasons the nanops versions are slower: 1) you need to calculate the mask every time, and 2) the approach nanops takes (copy array + putmask to fill in "neutral" value, eg 0 for sum) seems slower compared to the newer where argument in numpy ufuncs.

Eg for

a = np.random.randn(1_000_000)  
a[np.random.randint(0, 1_000_000, 100)] = np.nan

the nansum basically is:

In [14]: %%timeit 
    ...: mask = np.isnan(a) 
    ...: temp = a.copy() 
    ...: np.putmask(temp, mask, 0) 
    ...: np.sum(temp) 
2.34 ms ± 48.4 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

which is also I suppose more or less what numpy does:

In [15]: %timeit np.nansum(a)      
2.15 ms ± 55.9 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

whereas with a known mask + where argument:

In [16]: %timeit np.sum(a, where=~mask) 
813 µs ± 9.85 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

(now, it also depends on the number of values that are missing how well the different approaches work, I think)

Also, floating-point-wise, both approaches are also not the same, and result in slightly different numbers (np.nansum and the multi-line nanops implementation above give exactly the same result, but the where approach gives a difference after 14 significant digits)

jreback

needs some performance testing to ensure that didn't break anything on regular float arrays (as there are some changes in the shared code)

doc/source/whatsnew/v1.1.0.rst

jreback · 2020-06-20T15:13:42Z

doc/source/whatsnew/v1.1.0.rst

+
+.. warning::
+
+   Experimental: the new floating data types are currently experimental, and its


is there a doc section can link to?

is there a doc section can link to?

Not yet, can probably put more or less the same content as in this whatsnew somewhere in the user guide

IMO, we should consolidate https://pandas.pydata.org/pandas-docs/dev/user_guide/integer_na.html and https://pandas.pydata.org/pandas-docs/dev/user_guide/boolean.html into a single "nullable data types" page and add it there (not in this PR).

Indeed, that has been on my personal to do list, but never got to it. In general we should have a page about data types (and can still have some subpages if needed)

pandas/_testing.py

jreback · 2020-06-20T15:15:01Z

pandas/core/arrays/boolean.py


            if isinstance(
-                other, (ABCDataFrame, ABCSeries, ABCIndexClass, IntegerArray)
+                other,
+                (ABCDataFrame, ABCSeries, ABCIndexClass, IntegerArray, FloatingArray),


we should create a superclass NumericArray I think for Integer / Floating

pandas/core/arrays/integer.py

jreback · 2020-06-20T15:16:16Z

pandas/core/arrays/integer.py


            mask = None

-            if isinstance(other, (BooleanArray, IntegerArray)):
+            if isinstance(other, (BooleanArray, IntegerArray, FloatingArray)):


same comments above about creating NumericArray

I used here BaseMaskedArray because we basically want to check for any masked array we now have (including BooleanArray)

jreback · 2020-06-20T15:17:02Z

pandas/core/dtypes/common.py

@@ -83,6 +83,8 @@ def ensure_float(arr):
    float_arr : The original array cast to the float dtype if
                possible. Otherwise, the original array is returned.
    """
+    if is_extension_array_dtype(arr.dtype):
+        return arr.to_numpy(dtype="float64", na_value=np.nan)


jreback · 2020-06-20T15:17:22Z

pandas/core/groupby/ops.py

@@ -494,7 +495,7 @@ def _cython_operation(
            else:
                values = ensure_int_or_float(values)
        elif is_numeric and not is_complex_dtype(values):
-            values = ensure_float64(values)
+            values = ensure_float64(ensure_float(values))


hmm, we really need to do this twice?

I did it this way because we need to have ensure_float to convert a EA FloatingArray into a numpy float array, and the cython ensure_float64 is written to expect a numpy array, not an EA.
If you actually have already a float64 ndarray, the ensure_float is a no-op.

how about you make the same mod in ensure_float64 then, much more clear

ensure_float64 is a cython function that is used in many places, so doing something like that might affect performance in many cases, so needs to be done carefully, so I would rather want to keep that for a different PR. I also think it might be clearn to leave those ensure_<dtype> to deal with only numpy arrays (in addition, ensure_float64 is also implemented as a template-ized method for many different dtypes, so it's not that straightforward to add a custom check only for float).

jreback

a few comments, but much of this needs to share code

doc/source/whatsnew/v1.1.0.rst

pandas/_testing.py

jreback · 2020-09-19T01:36:06Z

pandas/core/arrays/floating.py

+    base = None
+    type: Type
+
+    def __repr__(self) -> str:


should e in the BaseMaskedArray class

should be in the BaseMaskedArray class

There would be nothing else using it, as the Integer/Boolean also have custom implementations. It needs some refactor to be able to share.

jreback · 2020-09-19T01:36:20Z

pandas/core/arrays/floating.py

+    def _is_numeric(self) -> bool:
+        return True
+
+    @cache_readonly


pandas/core/arrays/floating.py

jreback · 2020-09-19T01:37:16Z

pandas/core/arrays/floating.py

+        from pandas.core.arrays._arrow_utils import pyarrow_array_to_numpy_and_mask
+
+        pyarrow_type = pyarrow.from_numpy_dtype(self.type)
+        if not array.type.equals(pyarrow_type):


ideally also push to the super-class (looks doable if you use self.construct_array_type

pandas/core/arrays/floating.py

jorisvandenbossche · 2020-09-19T07:37:10Z

Thanks for the reviews! Pushed some updates.

Regarding the comments about things that could/should be shared: I copied a few additional properties that can be shared verbatim, but for all others this will require some refactor, and see my long comment about that above why I think it is better to do that in separate PRs: #34307 (comment)

pandas/core/arrays/boolean.py

doc/source/whatsnew/v1.2.0.rst

pandas/core/arrays/floating.py

Co-authored-by: Simon Hawkins <simonjayhawkins@gmail.com>

jorisvandenbossche · 2020-09-30T09:00:37Z

Any remaining comments here?

jreback · 2020-09-30T10:42:04Z

will look again

jreback

ok good to get this in. as indicated refactoring to share code is a good next set of PRs. Also really pushing this dtypes into all of the numeric tests via a fixture is needed (maybe this first). pls open followon issues for these

jreback · 2020-09-30T12:24:51Z

pandas/core/arrays/floating.py

+        results = []
+        for arr in chunks:
+            data, mask = pyarrow_array_to_numpy_and_mask(arr, dtype=self.type)
+            float_arr = FloatingArray(data.copy(), ~mask, copy=False)


do we actually need to copy?

jreback · 2020-09-30T12:27:02Z

pandas/core/arrays/floating.py

+            # return the same object for copy=False
+            return self.copy() if copy else self
+        # if we are astyping to another nullable masked dtype, we can fastpath
+        if isinstance(dtype, BaseMaskedDtype):


jreback · 2020-09-30T12:27:59Z

pandas/core/arrays/floating.py

+
+
+@register_extension_dtype
+class Float32Dtype(FloatingDtype):


we have almost no support for float16 (e.g. no algos support) and float128 is platform specific (IIRC)

jreback · 2020-09-30T12:29:34Z

doc/source/whatsnew/v1.2.0.rst

+
+.. ipython:: python
+
+  # the default numpy float64 dtype


could be non-comments (e.g. just before the block itself)

jreback · 2020-09-30T12:32:21Z

thanks @jorisvandenbossche really nice, sorry for the long time to review, as always shorter PRs are much easier (but get it!)

ENH: nullable Float32/64 ExtensionArray

cddc939

jorisvandenbossche added Enhancement NA - MaskedArrays Related to pd.NA and nullable extension arrays labels May 22, 2020

jorisvandenbossche added this to the 1.1 milestone May 22, 2020

This was referenced May 22, 2020

API: distinguish NA vs NaN in floating dtypes #32265

Open

CLN: consolidate arrow roundtrip tests for nullable dtypes in base masked tests #34308

Merged

fix doctest

6a1d822

Dr-Irv reviewed May 22, 2020

View reviewed changes

jorisvandenbossche added 2 commits May 22, 2020 18:13

add basic whatsnew note

f43f021

typo

ffdd65c

dsaxton reviewed May 22, 2020

View reviewed changes

jorisvandenbossche mentioned this pull request May 29, 2020

TST/REF: refactor the arithmetic tests for IntegerArray #34454

Merged

Merge remote-tracking branch 'upstream/master' into EA-floating

3d189f9

fix astype to string

ff3b937

dsaxton reviewed May 29, 2020

View reviewed changes

WillAyd reviewed May 29, 2020

View reviewed changes

TomAugspurger reviewed May 29, 2020

View reviewed changes

jreback requested changes Jun 1, 2020

View reviewed changes

Merge remote-tracking branch 'upstream/master' into EA-floating

13b8281

jorisvandenbossche mentioned this pull request Jun 15, 2020

PERF: Significant speed difference between arr.mean() and arr.values.mean() for common dtype columns #34773

Closed

3 tasks

jorisvandenbossche added 2 commits June 19, 2020 19:23

Merge remote-tracking branch 'upstream/master' into EA-floating

4c1d06c

clean-up arithmetic tests to align with integer/boolean tests

ebbc64d

jreback requested changes Jun 20, 2020

View reviewed changes

jreback requested changes Sep 19, 2020

View reviewed changes

jorisvandenbossche added 5 commits September 19, 2020 09:01

whatsnew 1.2

81456f9

update whatsnew

71009c3

add fixture

56d2311

share some dtype properties

65a2060

update ensure_float

8b36098

jorisvandenbossche added 2 commits September 23, 2020 13:24

Merge remote-tracking branch 'upstream/master' into EA-floating

7f3e965

remove skip for float32 conversion to string

66d6939

dsaxton mentioned this pull request Sep 23, 2020

BUG: Cannot use pd.NA in a series with float dtype #36587

Closed

3 tasks

gsheni mentioned this pull request Sep 28, 2020

DataTable init does not not replace NaNs with pd.NA with float data type alteryx/woodwork#128

Open

jorisvandenbossche added 2 commits September 29, 2020 09:16

Merge remote-tracking branch 'upstream/master' into EA-floating

e0c9d9a

code formatting

d37b815

jorisvandenbossche commented Sep 29, 2020

View reviewed changes

pandas/core/arrays/boolean.py Outdated Show resolved Hide resolved

simonjayhawkins reviewed Sep 29, 2020

View reviewed changes

doc/source/whatsnew/v1.2.0.rst Outdated Show resolved Hide resolved

pandas/core/arrays/floating.py Outdated Show resolved Hide resolved

jorisvandenbossche and others added 3 commits September 30, 2020 08:48

Update doc/source/whatsnew/v1.2.0.rst

44e699a

Co-authored-by: Simon Hawkins <simonjayhawkins@gmail.com>

Update pandas/core/arrays/floating.py

b42b61d

Co-authored-by: Simon Hawkins <simonjayhawkins@gmail.com>

ignore mypy bug

edf9618

jreback approved these changes Sep 30, 2020

View reviewed changes

jreback merged commit 0846dc1 into pandas-dev:master Sep 30, 2020

simonjayhawkins mentioned this pull request Oct 2, 2020

BUG: Nullable floats can look like ints in repr #36775

Closed

gsheni mentioned this pull request Oct 14, 2020

Replace float64 with Float64Dtype in pandas alteryx/woodwork#264

Open

kesmit13 pushed a commit to kesmit13/pandas that referenced this pull request Nov 2, 2020

ENH: nullable Float32/64 ExtensionArray (pandas-dev#34307)

435ca72

jorisvandenbossche deleted the EA-floating branch November 27, 2020 14:18

jorisvandenbossche mentioned this pull request Nov 27, 2020

Follow-up on basic FloatingArray implementation #38110

Open

10 tasks

jorisvandenbossche mentioned this pull request Jan 20, 2021

API/BUG: pd.array(float_ndarray_with_nans) casts np.nan to pd.NA #39039

Closed

tswast mentioned this pull request Oct 25, 2023

BUG: Nullable Float64Dtype incorrectly converting NaN to NA when constructed with Arrow array #55668

Open

3 tasks

		tm.assert_extension_array_equal(result, expected)


		def test_cross_type_arithmetic():

		result = self._data.astype(dtype.numpy_dtype, copy=False)
		return type(self)(result, mask=self._mask, copy=False)


		.. warning::

		Experimental: the new floating data types are currently experimental, and its

ENH: nullable Float32/64 ExtensionArray #34307

ENH: nullable Float32/64 ExtensionArray #34307

Conversation

jorisvandenbossche commented May 22, 2020 • edited Loading

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

pep8speaks commented May 29, 2020 • edited Loading

Comment last updated at 2020-09-30 08:18:27 UTC

jorisvandenbossche commented May 29, 2020 • edited Loading

jorisvandenbossche commented May 29, 2020

dsaxton May 29, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TomAugspurger left a 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

Choose a reason for hiding this comment

jorisvandenbossche commented Jun 1, 2020

TomAugspurger commented Jun 1, 2020 via email

jreback left a comment

Choose a reason for hiding this comment

jbrockmendel commented Jun 16, 2020

jorisvandenbossche commented Jun 19, 2020

jreback left a 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

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

jreback left a 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

jorisvandenbossche commented Sep 19, 2020

jorisvandenbossche commented Sep 30, 2020

jreback commented Sep 30, 2020

jreback left a 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

jreback commented Sep 30, 2020

jorisvandenbossche commented May 22, 2020 •

edited

Loading

pep8speaks commented May 29, 2020 •

edited

Loading

jorisvandenbossche commented May 29, 2020 •

edited

Loading

dsaxton May 29, 2020 •

edited

Loading