FEAT: Implementing same_value casting rule in quaddtype
#246
Conversation
| // we could allow, but this will be bad | ||
| // Two values that are different in quad precision, | ||
| // might appear equal when converted to double. |
There was a problem hiding this comment.
| // we could allow, but this will be bad | |
| // Two values that are different in quad precision, | |
| // might appear equal when converted to double. | |
| // we could allow this, but it would be bad | |
| // since two values that are different in quad precision | |
| // might appear equal when converted to double. |
juntyr
left a comment
juntyr
left a comment
There was a problem hiding this comment.
Thanks @SwayamInSync for your work! My comments are mostly nits and extra tests, I'll review again afterwards
New things fixed and added
|
| return Sleef_negq1(QUAD_ZERO); // -0.0 | ||
| if (Sleef_icmpeqq1(result, QUAD_PRECISION_ZERO)) { | ||
| if (Sleef_icmpltq1(*b, QUAD_PRECISION_ZERO)) { | ||
| return Sleef_negq1(QUAD_PRECISION_ZERO); // -0.0 |
There was a problem hiding this comment.
we have a const for negative zero
There was a problem hiding this comment.
There's a subtle issues in using that, we didn't used QUAD_PRECISION_NEG_ZERO anywhere because qutil gave the logical representation but the sign information is stored in the actual IEEE 754 binary format, not in the integer literal itself. Basically the sign is encoded in the high mantissa bits. Simply putting a minus sign in front of 0x0 doesn't create a negative zero representation.
I can replace it with a valid representation maybe in future PRs, for now that is just an artifact in the code.
juntyr
left a comment
juntyr
left a comment
There was a problem hiding this comment.
LGTM with minor nits addressed
2 participants
closes #153
As per the title