Skip to content

Conversation

@SwayamInSync
Copy link
Member

@SwayamInSync SwayamInSync commented Jan 2, 2026

This PR contains the unrelated refactors happend inside #246 (the commits were inter-twined with same_value feat so had to pick them manually here, can cause conflict in that PR but should be resolvable)

  • Single function to handle Sleef to double casting with edge cases
  • Use pass by pointer instead of value for quad_value union
  • Fixed the Quad2Quad inter-backend casting

@SwayamInSync SwayamInSync added this to the v1.0 milestone Jan 2, 2026
@SwayamInSync SwayamInSync requested a review from ngoldbaum January 2, 2026 14:45
@SwayamInSync
Copy link
Member Author

We could've also refactored the to_quad template specilizations to also take union pointers intead of returining, but that does not seems to cause any cross-platform issues (also compiler might perform the return value optimization, so doesn't seems like harming performance)

{
long double ld = in_val.longdouble_value;
if (std::isnan(ld)) {
out_val.sleef_value = (!ld_signbit(&ld)) ? QUAD_PRECISION_NAN : QUAD_PRECISION_NEG_NAN;
Copy link
Contributor

Choose a reason for hiding this comment

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

you can get rid of the double negation here and switch the arms

// fix can be catching the cases and returning corresponding type value without casting
if (backend == BACKEND_SLEEF) {
return (npy_byte)Sleef_cast_to_int64q1(x.sleef_value);
return (npy_byte)Sleef_cast_to_int64q1(x->sleef_value);
Copy link
Contributor

Choose a reason for hiding this comment

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

can we use static_cast's in the from_quad methods as well?

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure, here we can, although the casting coming from a int64 to lower variants so the current code is also safe

Copy link
Contributor

@juntyr juntyr left a comment

Choose a reason for hiding this comment

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

I left some nits but functionality-wise this looks good to go to me. Thanks @SwayamInSync!

Copy link
Member

@ngoldbaum ngoldbaum left a comment

Choose a reason for hiding this comment

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

Looks good, just one small question inline.

if (pos < maxPrintLen - 1) {
buffer[pos++] = '-';
}
}
Copy link
Member

Choose a reason for hiding this comment

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

Should we also make this change in NumPy?

Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe for the sake of completeness yeah, I am not sure of the actual usecase of -nan
An even important case is -0.0 as I've seen some people use it as signal and it is working correct in numpy

Copy link
Contributor

Choose a reason for hiding this comment

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

-0.0 is, unfortunately, quite important, so that you can go from e.g. -1/inf=-0 back to -1/-0=inf.

-NaN is more niche but worth preserving nonetheless

@SwayamInSync
Copy link
Member Author

Thanks, everyone
Merging this in

@SwayamInSync SwayamInSync merged commit bf28864 into numpy:main Jan 6, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants