Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow empty sub-containers in reductions #129

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

majosm
Copy link
Collaborator

@majosm majosm commented Dec 15, 2021

Allows some (but not all) of the sub-containers in an array container to be empty in reductions. This allows reductions to be used on single-species CV objects in mirgecom.

Depends on #128 (not in an essential way, just avoiding dealing with merge conflicts).

@inducer
Copy link
Owner

inducer commented Dec 27, 2021

This has picked up some merge conflicts. Could you take a look? Also, ready to un-draft?

@majosm majosm marked this pull request as ready for review December 27, 2021 18:56
@majosm majosm requested a review from inducer December 27, 2021 18:56
Copy link
Owner

@inducer inducer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! LGTM aside from the all-empty handling, which I think ought to be quick to resolve.

Comment on lines +488 to +489
if result is None:
raise ValueError("cannot reduce empty array container")
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I think reducing over an empty container is well-defined: just return the neutral element. reduce_func should be trusted to do the right thing. What was the reasoning for putting in this error message? Basically, what I'm pushing for is to get rid of it and return reduce_func([]) instead.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If reduce_func worked for an empty list, I think this PR wouldn't be needed, right?

The motivation for this was for things like actx.np.max where reduce_func doesn't (currently) behave nicely for empty inputs. Should that maybe be fixed instead?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reference, calling np.max on an empty list raises

>>> np.max([])
ValueError: zero-size array to reduction operation maximum which has no identity

and requires specifying an initial value with np.max([], initial=np.inf). We should probably do something like that in actx.np too.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The motivation for this was for things like actx.np.max where reduce_func doesn't (currently) behave nicely for empty inputs.

That's a great point. I had not thought far enough to realize that, but I agree now.

Should that maybe be fixed instead?

I think that's exactly what we should do.

We should probably do something like that in actx.np too.

I agree. While I wasn't loving numpy's interface of "no implicit neutral" element at first, I think it makes sense from the perspective of integers. I think we should aim to replicate this, both at the level of actx.np, and for the array container reductions under discussion here.

One subtlety is the ValueError for empty arrays. For symbolically-shaped pytato arrays, it may not be possible to do a perfect job.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did some work towards that:

That latter PR needs some more work done to it. @majosm, could you take a look?

Comment on lines +529 to +530
if result is None:
raise ValueError("cannot reduce empty array container")
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above.

@inducer
Copy link
Owner

inducer commented Dec 28, 2021

@majosm, depending on how you feel, #136 might supersede this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants