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

[RNG][Device API] Added (u)int8_t and (u)int16_t types support for Uniform #632

Open
wants to merge 8 commits into
base: develop
Choose a base branch
from

Conversation

egrabovskaya
Copy link
Contributor

Description

At the DPNP team request support for the following small types was added for Uniform distribution:

  • int8_t
  • uint8_t
  • int16_t
  • uint16_t

Checklist

All Submissions

  • Do all unit tests pass locally? Attach a log.

@egrabovskaya egrabovskaya requested a review from a team as a code owner February 20, 2025 13:10
Copy link
Contributor

@andreyfe1 andreyfe1 left a comment

Choose a reason for hiding this comment

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

Thank you very much for the PR!

if constexpr (std::is_same_v<Type, std::int32_t> ||
std::is_same_v<Type, std::uint32_t>) {
if constexpr (std::is_same_v<Type, std::int8_t> || std::is_same_v<Type, std::uint8_t> ||
std::is_same_v<Type, std::int16_t> || std::is_same_v<Type, std::uint16_t>) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I would suggest to move this dispatch above to have floating type definition in one place, e.g.

std::conditional_t<
    !std::is_same_v<Method, uniform_method::accurate> ||
     std::is_same_v<Type, std::int8_t> ||
     std::is_same_v<Type, std::uint8_t> ||
     std::is_same_v<Type, std::int16_t> ||
     std::is_same_v<Type, std::uint16_t>,
float, double>

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it looks clearer with the extra condition. Furthermore, the existing condition relates to (u)int32, (u)int64 and floating point precision types. But with the option you suggested we will have less additional code.
@iMartyan, could you please share your opinion here?

Copy link
Contributor

Choose a reason for hiding this comment

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

I also like Andrey's approach more because the generation method is the same. So, better not to split it into several branches.

Comment on lines +174 to +175
ParamsType a = distr.a();
ParamsType b = distr.b();
Copy link
Contributor Author

@egrabovskaya egrabovskaya Feb 21, 2025

Choose a reason for hiding this comment

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

Is it OK if a, b params are always double-precision floating point numbers for all small types?

Copy link
Contributor

Choose a reason for hiding this comment

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

Could you please check it? If tests are passed I don't see any objections to use double for all Fp values

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I launched moments manually and they successfully passed

Copy link
Contributor

@andreyfe1 andreyfe1 Feb 21, 2025

Choose a reason for hiding this comment

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

So, I'm fine if we switch to double if there are no objections from somebody else

Copy link
Contributor

Choose a reason for hiding this comment

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

fine with me

Copy link
Contributor

@iMartyan iMartyan left a comment

Choose a reason for hiding this comment

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

lgtm

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