Skip to content

Add NAN handling to convert() needed for some prefix routines with integer outputs.#502

Merged
rkarim2 merged 20 commits intonv-legate:branch-22.10from
rkarim2:convert_dev
Sep 4, 2022
Merged

Add NAN handling to convert() needed for some prefix routines with integer outputs.#502
rkarim2 merged 20 commits intonv-legate:branch-22.10from
rkarim2:convert_dev

Conversation

@rkarim2
Copy link
Contributor

@rkarim2 rkarim2 commented Aug 4, 2022

No description provided.

@rkarim2 rkarim2 requested a review from magnatelee August 4, 2022 23:19
rkarim2 added 11 commits August 9, 2022 18:03
…Ns when converting from complex/float to ints.

Eager currently incomplete.
On C++ side need to add OP handling to allow templatization on NAN identity values (for performance reasons).
…o identity based on operation. Not tested and likely buggy!
Bugfixes.
Changed the prefix routines to use the convert with NAN handling.
Remove unnecessary code from convert.
Added nan handling to eager variant of convert.
Intial testing seems to work correctly.
Modified the test code for scan routines, enabling int type outputs on float/complex inputs with NAN handling.
Modified the scan test code's parametrization.
Removed commented out unnecessary code from convert.
pre-commit fixes.
Change input ranges to avoid overflows resulting in NANs (NANs are still tested based on n0)
type_dispatch(args.in.code(), SourceTypeDispatch<KIND>{}, args);
ConvertArgs args{
context.outputs()[0], context.inputs()[0], context.scalars()[0].value<ConvertCode>()};
op_dispatch(args.nan_op, ConvertDispatch<KIND>{}, args);
Copy link
Contributor

Choose a reason for hiding this comment

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

Doing this dispatch upfront triples the number of template instantiations, even though the dispatch on nan_op is unnecessary when the source has an integer type (and please remember there are more integer types than floating point types and complex types combined). A more desirable implementation would be to instantiate a special conversion logic only for pairs of types that need it. You can express those pairs using a template like this:

template <LegateTypeCode SRC_TYPE, LegateTypeCode DST_TYPE>
using needs_dispatch_on_nan_op =
  (legate::is_floating_type(SRC_TYPE)::value || legate::is_complex_type(SRC_TYPE)::value) 
  && legate::is_integer_type(DST_TYPE)::value;

Then you move the dispatch on nan_op to the innermost template and do it only when needs_dispatch_on_nan_op is true.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Resolved in multiple commits, completed fix in d20450a

…sabling unnecessary templates when input is not float/complex (to be disabled in a future commit)
Adjusted nancumsum/nancumprod implementation to switch to the faster cumsum/cumprod if NAN conversion is already handled by convert.
With the change to convert's templatization it's needed (and beneficial) to reroute nancumsum/nancumprod to cumsum/cumprod at python level before convert is called for non-float/complex types.
Modified test to cover nancumsum/nancumprod for non-float/complex input types to catch any potential bugs (needed due to how convert's templatization is now done).
@rkarim2 rkarim2 added the category:new-feature PR introduces a new feature and will be classified as such in release notes label Aug 31, 2022
@magnatelee
Copy link
Contributor

LGTM. feel free to merge it once you fix the merge conflict

@rkarim2 rkarim2 merged commit 569e527 into nv-legate:branch-22.10 Sep 4, 2022
@rkarim2 rkarim2 deleted the convert_dev branch September 4, 2022 17:40
manopapad added a commit that referenced this pull request Nov 17, 2024
* Initial pass

* todos.rst

* Address comments

* Fix warnings

* Update product positioning

* Add supported platform info

* Move all Jupyter instructions to Legate

* more warnings

* Remove todos

---------

Co-authored-by: Manolis Papadakis <mpapadakis@nvidia.com>
XiaLuNV pushed a commit to XiaLuNV/cunumeric that referenced this pull request Dec 13, 2024
* Initial pass

* todos.rst

* Address comments

* Fix warnings

* Update product positioning

* Add supported platform info

* Move all Jupyter instructions to Legate

* more warnings

* Remove todos

---------

Co-authored-by: Manolis Papadakis <mpapadakis@nvidia.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

category:new-feature PR introduces a new feature and will be classified as such in release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants