-
Notifications
You must be signed in to change notification settings - Fork 165
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
base: develop
Are you sure you want to change the base?
[RNG][Device API] Added (u)int8_t and (u)int16_t types support for Uniform #632
Conversation
There was a problem hiding this 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>) { |
There was a problem hiding this comment.
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>
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
ParamsType a = distr.a(); | ||
ParamsType b = distr.b(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fine with me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Description
At the DPNP team request support for the following small types was added for Uniform distribution:
Checklist
All Submissions