Make torch.conj() a composite function and return self for real tensors #43270

anjali411 · 2020-08-19T16:04:22Z

torch.conj is a very commonly used operator for complex tensors, but it's mathematically a no op for real tensors. Switching to tensorflow gradients for complex tensors (as discussed in #41857) would involve adding torch.conj() to the backward definitions for a lot of operators. In order to preserve autograd performance for real tensors and maintain numpy compatibility for torch.conj, this PR updates torch.conj() which behaves the same for complex tensors but performs a view/returns self tensor for tensors of non-complex dtypes. The documentation states that the returned tensor for a real input shouldn't be mutated. We could perhaps return an immutable tensor for this case in future when that functionality is available (@zdevito @ezyang ).

Stack from ghstack:

Make torch.conj() a composite function and return self for real tensors #43270 Make torch.conj() a composite function and return self for real tensors

Differential Revision: D23460493

[ghstack-poisoned]

ghstack-source-id: e00a233 Pull Request resolved: #43270

dr-ci · 2020-08-19T16:20:05Z

💊 CI failures summary and remediations

As of commit 33c3375 (more details on the Dr. CI page):

💚 💚 Looks good so far! There are no failures yet. 💚 💚

This comment was automatically generated by Dr. CI (expand for details).

Follow this link to opt-out of these comments for your Pull Requests.

Please report bugs/suggestions on the GitHub issue tracker or post in the (internal) Dr. CI Users group.

See how this bot performed.

This comment has been revised 40 times.

albanD · 2020-08-19T16:25:59Z

aten/src/ATen/native/UnaryOps.cpp

  }
 }

 Tensor& conj_out(Tensor& result, const Tensor& self) { return unary_op_impl_out(result, self, conj_stub); }


What about this one?
What happens if you try to use autograd with it? Does it still raise a nice error?

I don't follow. it's only called through at::_conj which has a definition in derivatives.yaml. how else can you use it with autograd?

This one is not called from _conj no.
And the user can call it directly by doing a.conj(out=b).
And this should raise an error if either a or b requires grad.

albanD · 2020-08-19T16:27:20Z

torch/_torch_docs.py


-Computes the element-wise conjugate of the given :attr:`input` tensor.
+Computes the element-wise conjugate of the given :attr:`input` tensor. If :attr:`self` tensor
+has a non-complex dtype, this function returns the :attr:`self` tensor.


nit: should be input here not self right?

zou3519 · 2020-08-19T16:29:19Z

aten/src/ATen/native/UnaryOps.cpp

+Tensor conj(const Tensor& self) {
+  if (!self.is_complex()) {
+    return self;
+  }
+  return at::_conj(self);
+}


This seems BC-breaking: previously if a user passed in a real tensor to conj, they'd get back a copy of said tensor. What was the rationale behind this change?

FWIW, in numpy, conj returns a copy of the original tensor if it wasn't complex:

>>> x = np.array([0.1, 0.1]) >>> y = np.conj(x) >>> y.flags ... OWNDATA : True

As discussed in this issue: #41857 switching to the tensorflow style gradients would involve addition of a bunch of conj in the gradient definitions. In order to preserve the backward performance for real tensors, it seems like a good option to make torch.conj a no op for real tensors.

I see, so the decision in that thread was to go for TF-style gradients. However, TF-style gradients require conj-calls everywhere in the gradient formulas. Because of that, we're trying to optimize calls to conj to avoid regressions.

The downside of calling the operator "fast_conj" is that writers of gradient formulas might use "conj" instead of "fast_conj". If we go down that route it would be nice to document somewhere (derivatives.yaml?) that users should use fast_conj and not conj. On the other hand, I think it is probably OK for us to break BC and to diverge from numpy and have our "conj" not do copies when possible but I am not sure which of these two solutions would be better.

Exploring the design space some more, I noticed that there were some comments about having a conj flag on tensors that reinterprets the tensor as its conjugate (#41857 (comment)). Was there a decision on that? That seems like it would eliminate the need to have a fast_conj

I understand why we want to have a function with this behavior, but have a few questions/suggestions:

I would prefer our conj have the same behavior as NumPy's

torch.conj is, conceptually, a universal function, and all universal functions create new outputs

for example, torch.abs(uint8) produces a new tensor, even though it could mathematically fulfill its contract by returning self

analogously, would we expect torch.ceil(int64) to return self or a copy of self?

do we expect this function to be used by anyone but developers? Is making a non-user-facing function self_or_conj an option to address the scenarios we'd like to target? If we're uncertain about those scenarios, could we start with this?

I appreciate @zou3519's concern about gradient writers mistakenly using conj instead of self_or_conj, and I agree that's a real possibility, but if we're consistent about using the latter and do our job in code review I think it'll be OK. I'm also less concerned about introducing a fixable performance issue vs. creating an inconsistent and semantically confusing UX for end users.

Although I am leaning towards "faithfully replicate numpy behavior" (@anjali411, I think I mentioned that I was having trouble deciding between these two choices in our call), I want to point out some reasons why fast conj by default might make sense.

do we expect this function to be used by anyone but developers? Is making a non-user-facing function self_or_conj an option to address the scenarios we'd like to target? If we're uncertain about those scenarios, could we start with this?

fast_conj absolutely would be used by non-developers. Any time you write code that you want to generalize over both reals and complex you will write conjugations to handle the complex case, and if they are not no-ops, you will unnecessarily slow down the execution of your code in the real case. Some more support from boedekker here #41857 (comment)

Exploring the design space some more, I noticed that there were some comments about having a conj flag on tensors that reinterprets the tensor as its conjugate (#41857 (comment)). Was there a decision on that?

For the BC consideration here, it doesn't help. If we have a fancy version of conjugate that returns a view rather than new tensor, that would still be incompatible with the Numpy behavior. So if you want to keep numpy behavior, you're still going to have to come up with a new name for view_conj or whatever.

cc @boeddeker

I would lean towards @ezyang opinion here personally. In particular, "fast_conj absolutely would be used by non-developers." and not having it would mean that people will start adding a lot of if t.is_complex() in their code.

@mruberry are there functions for which we explicitly plan to have a different API compared to numpy? And maybe provide a numpy-compliant version in a different namespace? Could this function be one of them?

I am working a lot with numpy and I must say, I never checked if numpy.conj returns a copy or hold the original data.
Sometimes I got the impression, that it is a no op, also for complex numbers, when I measured the execution time (execution time is close to nothing compared to any other function).

Nevertheless, assuming that conj returns a copy in the source tensor, also for real tensors, is a bad idea.

When you introduce fast_conj, I would never use conj.

In context of torch, I would prefer, when conj never creates a copy.
While the calculation of the copy may be suboptimal, the increased memory consumption is critical.
In numpy you can calculate on demand the conjugate and it will be deleted a few moments later.
In torch, it may be kept for the backward graph. When you call multiple times conj, you store several copies.

So maybe it would also be worth considering, that the conjugate operation gets an argument to enable something like torch.utils.checkpoint.checkpoint or have the conj flag, that was earlier mentioned.

cc @zdevito this may be one of the first cases where we have existentially important laziness on tensors

@mruberry are there functions for which we explicitly plan to have a different API compared to numpy? And maybe provide a numpy-compliant version in a different namespace?

Yes, but we should strive to limit these discrepancies. In particular we want a compelling reason for the difference (the NumPy behavior would be inconsistent with PyTorch, or it would require an extremely painful deprecation, ...).

Could this function be one of them?

Sure. I'm actually less worried about the NumPy compatibility of this function than the PyTorch inconsistency of it. It seems like we're trying to combine the ideas of torch.conj() the unary ufunc and a .conj attribute with a corresponding view function, like .real, .imag, and .T.

[ghstack-poisoned]

ghstack-source-id: 960922c Pull Request resolved: #43270

gchanan · 2020-08-20T22:09:02Z

Here's some fun that I think shows we shouldn't follow NumPy exactly:

>>> np.__version__
'1.17.2'

>>> x=np.random.randn(2,3)

>>> x.ctypes.data == x.conj().ctypes.data
True

>>> x.ctypes.data == np.conj(x).ctypes.data
False

Perhaps x.conj() returning self is just a bug, though. We've had those bugs before.

Same doesn't apply to complex values:

y=np.random.randn(2,3) + 1j*np.random.randn(2,3)

>>> y.ctypes.data == y.conj().ctypes.data
False

>>> y.ctypes.data == np.conj(y).ctypes.data
False

gchanan · 2020-08-20T22:11:07Z

test/test_torch.py

+    def test_conj_self(self, device, dtype):
+        t = torch.ones(5, 5, device=device)
+        s = t.fast_conj()
+        self.assertTrue(s is t)


do we actually want this or do we want s to be a view of t?

we could but I think we should just return same tensor as input with same storage to make it a complete no op

gchanan · 2020-08-20T22:20:54Z

I guess my questions are:

what is the "right" numpy conj behavior? I don't expect numpy meant to distinguish the functional and method variant. @rgommers?
is the the semantics of some function we actually want long-term? I would expect fast_conj or view_conj or whatever to do something fast/view for complex as well. I'm unsure if you are planning this, considering this, or you are set on the current semantics.
As an API issue, IMO you should start the name with the most "discoverable" information -- think code completion. People will type torch.conj... when looking for conjugate functionality, not start with fast.... So whatever we choose for the name, it should start with conj

mruberry · 2020-08-20T22:22:39Z

what is the "right" numpy conj behavior? I don't expect numpy meant to distinguish the functional and method variant. @rgommers?

I filed numpy/numpy#17124 about the discrepancy.

rgommers · 2020-08-20T22:57:06Z

what is the "right" numpy conj behavior? I don't expect numpy meant to distinguish the functional and method variant. @rgommers?

I commented on the NumPy issue Mike opened. For the decision to be made here, I think it's more important that PyTorch has a consistent design here rather than that it follow NumPy exactly. The copy-vs-view behavior in NumPy can be inconsistent for no good reason, and is very hard to change at this point.

I'd prefer if functions and methods always had the same behaviour.

ezyang · 2020-08-21T15:34:02Z

Based on this new information (thanks @gchanan for looking, this is really useful information), I've amended my position: I think we should do a serious investigation of doing conjugation view by default; I kind of suspect we still won't do it for conj because it is too surprising (because it is just too different from how all of our other unary operations work), but I think we should try to understand it better.

Conjugate views work in the following way:

Every tensor is associated with a boolean flag that says whether or not it is conjugated
x.conj_view() shares memory with x, but simply flips the boolean flag
Conjugation views necessitate the creation of negative views as well, so that x.imag is always a view (if x is conjugated, then x.imag must be negative)
A backend fallback, by default, materializes a conjugate/negative view into an actual tensor when it is used as a non-mutating input to an operation that doesn't support fused conjugation/negative
On a per operator basis, we may override the backend fallback to call specialized fused operations. For conjugation, typical fused operations include dot product and matrix multiply; for negative, an obvious fused operation is transforming add into sub, and vice versa. This fallback should be done AFTER autograd, so that autograd saves conjugate views for backward.
If you mutate a conjugate/negative view, you instead conjugate/negate the values you would have written in, and write them into the source tensor.
The machinery for conjugate/negative views would also generalize to zero tensors, which @albanD has argued are useful for autograd

An alternative to conjugate views is peephole lazy tensors, which @zdevito has advocated for. Peephole lazy tensors work like this:

When you write x.conj(), we don't immediately do the conjugation operation. Instead, we simply produce a tensor which says, "This is x, but conj." The distinction between this and the conjugate flag, is that this tensor is semantically a new copy of the tensor. So for example, if we then attempted to mutate the result, we would simply directly materialize the conjugated result and then mutate that.
If the result is used by another operation which doesn't support fusion, we materialize the conjugated tensor; all subsequent uses of the result make use of this materialized tensor

A variation of peephole lazy tensors is rematerialization (#42056). Instead of saving the materialized tensor, we never save it, and instead always redo the conjugation at a use site. (Or perhaps there is some policy, which specifies whether or not we save or not.)

@zdevito

… real tensors" `torch.conj` is a very commonly used operator for complex tensors, but it's mathematically a no op for real tensors. Switching to tensorflow gradients for complex tensors (as discussed in #41857) would involve adding `torch.conj()` to the backward definitions for a lot of operators. In order to preserve autograd performance for real tensors and maintain numpy compatibility for `torch.conj`, this PR updates `torch.conj()` which behaves the same for complex tensors but performs a view/returns `self` tensor for tensors of non-complex dtypes. The documentation states that the returned tensor for a real input shouldn't be mutated. We could perhaps return an immutable tensor for this case in future when that functionality is available (@zdevito @ezyang ). [ghstack-poisoned]

ghstack-source-id: bb48076 Pull Request resolved: #43270

anjali411 · 2020-08-28T16:40:38Z

torch/_torch_docs.py


-Computes the element-wise conjugate of the given :attr:`input` tensor.
+Computes the element-wise conjugate of the given :attr:`input` tensor. If the input has a non-complex dtype,
+the output tensor shouldn't be mutated.


as per @ezyang 's suggestion

Actually, since we're exploring conjugate view, let me suggest we make an even stronger claim: we should tell users to flat out NOT mutate the output of this function, ever. If you avoid doing so, you will write code that is forwards compatible with any possible semantics of conj (it always returns a new copy, it returns a new copy sometimes, it always returns a view).

I despair about actually making sure people don't do this with just a doc update. We really need some way to mark views as non-mutable. Maybe this wouldn't even be that hard to do...

@zdevito

… real tensors" `torch.conj` is a very commonly used operator for complex tensors, but it's mathematically a no op for real tensors. Switching to tensorflow gradients for complex tensors (as discussed in #41857) would involve adding `torch.conj()` to the backward definitions for a lot of operators. In order to preserve autograd performance for real tensors and maintain numpy compatibility for `torch.conj`, this PR updates `torch.conj()` which behaves the same for complex tensors but performs a view/returns `self` tensor for tensors of non-complex dtypes. The documentation states that the returned tensor for a real input shouldn't be mutated. We could perhaps return an immutable tensor for this case in future when that functionality is available (@zdevito @ezyang ). [ghstack-poisoned]

ghstack-source-id: 9cbd190 Pull Request resolved: #43270

@zdevito

… real tensors" `torch.conj` is a very commonly used operator for complex tensors, but it's mathematically a no op for real tensors. Switching to tensorflow gradients for complex tensors (as discussed in #41857) would involve adding `torch.conj()` to the backward definitions for a lot of operators. In order to preserve autograd performance for real tensors and maintain numpy compatibility for `torch.conj`, this PR updates `torch.conj()` which behaves the same for complex tensors but performs a view/returns `self` tensor for tensors of non-complex dtypes. The documentation states that the returned tensor for a real input shouldn't be mutated. We could perhaps return an immutable tensor for this case in future when that functionality is available (@zdevito @ezyang ). [ghstack-poisoned]

ghstack-source-id: 281cc5f Pull Request resolved: #43270

ezyang · 2020-08-31T14:43:00Z

aten/src/ATen/native/native_functions.yaml


+- func: _conj(Tensor self) -> Tensor
+  use_c10_dispatcher: full
+  variants: function


I hope this doesn't get traced; that would be _convolution all over again.

Maybe we want to rename it to conj_complex() as it is just a version of conj() that only accepts complex inputs?

@ezyang sorry I am not aware of the issue caused due to _convolution. what was it?
@albanD yeah that makes sense. will do!

Alias information for conj above is now not correct; you need to give it an alias annotation similar to what contiguous has.

@anjali411 Basically, _convolution, which has a bunch of extra arguments that people typically don't care about, is what is being traced to serialized models, meaning that now it is very difficult to add new parameters to _convolution because they are FC-breaking for all models.

conj is considerably less trafficked so the risks of getting it wrong here are lower, but it still seems to me that we should prefer tracing conj and not _conj. You should test which one we're getting in the trace.

Luckily I think the intent here is to keep _conj's signature equivalent to conj, since it's just an autograd hack to only apply autograd to complex inputs to conj. As you point out, @ezyang, _convolution suffers because it's secretly pulling in arguments the user doesn't expect.

Interesting question for what gets traced when ops are composite though: the composite ops or the original symbol. I don't know offhand.

Given that the code that handle tracing and autograd was the same until very recently. I expect that only the inner function is traced.

ezyang · 2020-08-31T19:20:47Z

test/test_torch.py

+    @dtypes(*(torch.testing.get_all_int_dtypes() + torch.testing.get_all_fp_dtypes()))
+    def test_conj_self(self, device, dtype):
+        t = torch.ones(5, 5, device=device)
+        s = t.fast_conj()


this needs to be updated

ezyang · 2020-08-31T20:47:10Z

In the interest of moving things along, I'd prefer to accept this patch. However, there are a bunch of ways this could go wrong. I'd prefer it if someone else could also ACK.

I'll also take a look at how hard it would be to mark tensors as immutable.

mruberry · 2020-09-01T13:59:56Z

aten/src/ATen/native/native_functions.yaml

  use_c10_dispatcher: full
  variants: function, method

 - func: conj.out(Tensor self, *, Tensor(a!) out) -> Tensor(a!)


Future work: inplace conj_?

mruberry · 2020-09-01T14:08:47Z

torch/_torch_docs.py

 conj(input, *, out=None) -> Tensor

-Computes the element-wise conjugate of the given :attr:`input` tensor.
+Computes the element-wise conjugate of the given :attr:`input` tensor. If the input has a non-complex dtype,


Would: "Computes the element-wise complex conjugate of :attr`input`." be a clearer fist sentence? "Conjugate" seems overloaded.

I wonder if the second sentence shouldn't be a note and/or a warning? Maybe something like:

NOTE: if :attr`input` is a non-complex dtype this function just returns :attr:input.

WARNING: In the future torch.conj may return a non-writeable view of :attr:input. It's recommended that programs not modify the tensor returned by torch.conj to be compatible with this change.

I think the behavior for non-complex tensors should go in the description, but added a warning as per your suggestion.

mruberry

This approach makes sense. Although this function may change in the future to return an immutable view the complex tensor UX is still in "beta", and @ezyang's suggestion to clarify the documentation seems like a reasonable mitigation. Few cleanup requirements:

test needs update (per @ezyang's note)
doc needs clarification

As for NumPy Compatibility, sometimes we do need to be different than NumPy for reasons of performance, our focus on neural networks, or our support of autograd, and I think we have a consensus that this approach is the best way (for now) to implement performant complex autograd.

From the perspective of how PyTorch's functions work, it's important that users know what to expect when they call a function. That is, ideally they should be able to infer what the function will do without reading its documentation. This means that functions should be named reasonably (e.g. torch.linalg.outer computes an outer product, and torch.ger is indecipherable for most users), and the system should be so consistent that users don't need to memorize a lot of exceptions or strange rules (for example, functions and methods in PyTorch perform the same computations).

torch.conj is a weird duck because there are good arguments for it being a unary ufunc like it is in NumPy, a view function, or a function like contiguous, cpu, cuda, and to. The first class of functions has always created a new tensor. The second usually returns a view (ahem, reshape), and the third class, which is hard to name, has returned self or a new tensor. From our discussion, however, it seems like torch.conj will eventually be in one of the latter two groups. Maybe the third class should be extended (and maybe torch.abs(uint8) should return self) or maybe torch.conj will eventually return an (immutable) view. Either way, this current approach seems like our best approximation of that future behavior.

ezyang · 2020-09-01T15:59:09Z

Thanks Mike!

@zdevito

… real tensors" `torch.conj` is a very commonly used operator for complex tensors, but it's mathematically a no op for real tensors. Switching to tensorflow gradients for complex tensors (as discussed in #41857) would involve adding `torch.conj()` to the backward definitions for a lot of operators. In order to preserve autograd performance for real tensors and maintain numpy compatibility for `torch.conj`, this PR updates `torch.conj()` which behaves the same for complex tensors but performs a view/returns `self` tensor for tensors of non-complex dtypes. The documentation states that the returned tensor for a real input shouldn't be mutated. We could perhaps return an immutable tensor for this case in future when that functionality is available (@zdevito @ezyang ). [ghstack-poisoned]

ghstack-source-id: d127021 Pull Request resolved: #43270

codecov · 2020-09-02T03:37:19Z

Codecov Report

❗ No coverage uploaded for pull request base (gh/anjali411/53/base@bacee6a). Click here to learn what that means.
The diff coverage is n/a.

@@                   Coverage Diff                   @@
##             gh/anjali411/53/base   #43270   +/-   ##
=======================================================
  Coverage                        ?   69.32%           
=======================================================
  Files                           ?      379           
  Lines                           ?    47106           
  Branches                        ?        0           
=======================================================
  Hits                            ?    32654           
  Misses                          ?    14452           
  Partials                        ?        0

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bacee6a...33c3375. Read the comment docs.

facebook-github-bot · 2020-09-03T00:20:21Z

@anjali411 merged this pull request in 129f406.

Make torch.conj a composite function

f5b3323

[ghstack-poisoned]

Update on "Make torch.conj a composite function"

a097c3c

[ghstack-poisoned]

anjali411 requested a review from zou3519 August 19, 2020 16:10

anjali411 requested review from albanD and ezyang August 19, 2020 16:10

Update on "Make torch.conj a composite function"

5db5a57

[ghstack-poisoned]

anjali411 added a commit that referenced this pull request Aug 19, 2020

Make torch.conj a composite function

8376a52

ghstack-source-id: e00a233 Pull Request resolved: #43270

albanD reviewed Aug 19, 2020

View reviewed changes

zou3519 reviewed Aug 19, 2020

View reviewed changes

Update on "Make torch.conj a composite function"

455c90d

[ghstack-poisoned]

anjali411 added module: complex Related to complex number support in PyTorch module: bc-breaking Related to a BC-breaking change and removed module: bc-breaking Related to a BC-breaking change labels Aug 19, 2020

Update on "Make torch.conj a composite function"

a11ef29

[ghstack-poisoned]

Update on "Make torch.conj a composite function"

2361923

[ghstack-poisoned]

anjali411 added a commit that referenced this pull request Aug 19, 2020

Make torch.conj a composite function

c96abcd

ghstack-source-id: 960922c Pull Request resolved: #43270

anjali411 requested a review from mruberry August 19, 2020 17:36

anjali411 changed the title ~~Make torch.conj a composite function~~ Add a composite function torch.fast_conj() Aug 19, 2020

gchanan reviewed Aug 20, 2020

View reviewed changes

ezyang mentioned this pull request Aug 25, 2020

Prototype of conjugate flag #43563

Closed

anjali411 changed the title ~~Add a composite function torch.fast_conj()~~ Make torch.conj() a composite function and return self for real tensors Aug 28, 2020

anjali411 added a commit that referenced this pull request Aug 28, 2020

Make torch.conj a composite function

f5d72b8

ghstack-source-id: bb48076 Pull Request resolved: #43270

anjali411 commented Aug 28, 2020

View reviewed changes

anjali411 requested review from ezyang and removed request for ezyang August 28, 2020 16:41

anjali411 added a commit that referenced this pull request Aug 28, 2020

Make torch.conj a composite function

05a78aa

ghstack-source-id: 9cbd190 Pull Request resolved: #43270

anjali411 added a commit that referenced this pull request Aug 28, 2020

Make torch.conj a composite function

41889ad

ghstack-source-id: 281cc5f Pull Request resolved: #43270

ezyang reviewed Aug 31, 2020

View reviewed changes

ezyang added the module: bc-breaking Related to a BC-breaking change label Aug 31, 2020

mruberry reviewed Sep 1, 2020

View reviewed changes

mruberry approved these changes Sep 1, 2020

View reviewed changes

ezyang mentioned this pull request Sep 1, 2020

first cut of adding backend fallback for conjugation #43702

Closed

anjali411 added a commit that referenced this pull request Sep 1, 2020

Make torch.conj a composite function

5fd9cf2

ghstack-source-id: d127021 Pull Request resolved: #43270

ezyang mentioned this pull request Sep 2, 2020

Immutable (read-only) tensors #44027

Open

facebook-github-bot closed this in 129f406 Sep 3, 2020

facebook-github-bot added the merged label Sep 3, 2020

facebook-github-bot deleted the gh/anjali411/53/head branch September 6, 2020 14:16

mruberry added the Merged label Oct 28, 2020

ezyang mentioned this pull request Jun 15, 2021

Lazy conjugated tensor is not numpy interoperable #59945

Closed

Make torch.conj() a composite function and return self for real tensors #43270

Make torch.conj() a composite function and return self for real tensors #43270

Uh oh!

Conversation

anjali411 commented Aug 19, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dr-ci bot commented Aug 19, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

💊 CI failures summary and remediations

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zou3519 Aug 19, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gchanan commented Aug 20, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gchanan commented Aug 20, 2020

Uh oh!

mruberry commented Aug 20, 2020

Uh oh!

rgommers commented Aug 20, 2020

Uh oh!

ezyang commented Aug 21, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ezyang commented Aug 31, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

anjali411 commented Aug 19, 2020 •

edited

Loading

dr-ci bot commented Aug 19, 2020 •

edited

Loading

zou3519 Aug 19, 2020 •

edited

Loading

codecov bot commented Sep 2, 2020 •

edited

Loading