It depends on the FP rounding mode. If rounding mode is FE_TOWARDZERO/FE_UPWARD/FE_TONEAREST then the case you gave is the only one I'm aware of. If rounding mode is FE_DOWNWARD (towards negative infinity) then other calculations that result in a zero will give a -0.0.
because if the length is 0, it get's transformed into 0.0 instead of -0.0
There are a few corner cases, in particular because it's possible to have
(+ 1.0 x (length L))
and I really want to avoid the runtime check of (length L) == 0 if possible.
So I took a look, asked there, and now your opinion confirms what I got so far. My C is not very good, so it's nice to have a example of how the rounding directions are used. Luckily Chez Scheme only uses the default rounding and it's probably correct to cut a few corners. I'll take a looks for a few days in case there is some surprise.
I'm not sure you can avoid the check, but you could probably avoid a branch with some clever trick - maybe using AVX-512 mask instructions.
A very recent AVX-512 extension has a `vfixupimm` instruction[1] which can adjust special floating point values. You could use this to adjust all zeroes to -0. It isn't very obvious how to use though.
__m128d _mm_fixupimm_sd (__m128d a, __m128d b, __m128i c, int imm8)
* The `imm8` is for error reporting - we can set it to zero to ignore errors (qnan).
* The arguments `a` and `b` are a floating point value - they can be the same value.
* The instruction first checks `b` and turns any denormals into zero if the MXCSR.DAZ flag is set.
* It then categorizes `b` as one of {QNAN, SNAN, ZERO, ONE, NEG_INF, POS_ING, NEG_VALUE, POS_VALUE}
* The argument c is an array of 8 nybbles (32-bit int) and is looked up based on the categorization of b {QNAN = 0 ... POS_VALUE = 7}
* The nybbles denote which value to place into the result:
0x0 : a
0x1 : b (with denormals as zero if DAZ flag is set)
0x2 : QNaN(src)
0x3 : QNAN_Indefinite
0x4 : -INF
0x5 : +INF
0x6 : b < 0 ? -INF : +INF
0x7 : -0
0x8 : +0
0x9 : -1
0xA : +1
0xB : 1/2
0xC : 90.0
0xD : PI/2
0xE : MAX_FLOAT
0xF : -MAX_FLOAT
So to turn positive zeroes into negative zeroes, you want to set the nybble to 7 where the categorization is zero (bits 11..8) in c. This would mean you want `c` to be equal to `0x700`. So usage would be:
This function would turn an int64_t into a double and any zeroes into -0.0, with no branches.
Unfortunately I'm unable to test properly as Compiler Explorer is giving SIGILL - presumably because it's running on some instance which doesn't support this instruction.
Obviously given how recent this instruction is, it's probably not viable for your use-case, but maybe something to consider in future when it's more widely available.
i would guess that because of how *** * floats are in binary computers, you have something like -0.0000000000000000000000000000000000001 and when you round it you end up with -0.0. Same goes for positive value, you're just not used to write the + sign before every number, so seeing the minus feels strange.
It depends on the FP rounding mode. If rounding mode is FE_TOWARDZERO/FE_UPWARD/FE_TONEAREST then the case you gave is the only one I'm aware of. If rounding mode is FE_DOWNWARD (towards negative infinity) then other calculations that result in a zero will give a -0.0.
Here's an example of -1.0f + 1.0f resulting in -0.0: https://godbolt.org/z/5qvqsdh9P
Thanks! [Sorry for the delay.]
---
FYI: For more context, I'm trying to send a PR to Chez Scheme (and indirectly to Racket) https://github.com/cisco/ChezScheme/pull/959 to reduce expressions like
where the "fixnums" are small integers and "flonums" are double.It's fine, unless you have the case
because if the length is 0, it get's transformed into 0.0 instead of -0.0There are a few corner cases, in particular because it's possible to have
and I really want to avoid the runtime check of (length L) == 0 if possible.So I took a look, asked there, and now your opinion confirms what I got so far. My C is not very good, so it's nice to have a example of how the rounding directions are used. Luckily Chez Scheme only uses the default rounding and it's probably correct to cut a few corners. I'll take a looks for a few days in case there is some surprise.
I'm not sure you can avoid the check, but you could probably avoid a branch with some clever trick - maybe using AVX-512 mask instructions.
A very recent AVX-512 extension has a `vfixupimm` instruction[1] which can adjust special floating point values. You could use this to adjust all zeroes to -0. It isn't very obvious how to use though.
So to turn positive zeroes into negative zeroes, you want to set the nybble to 7 where the categorization is zero (bits 11..8) in c. This would mean you want `c` to be equal to `0x700`. So usage would be: This function would turn an int64_t into a double and any zeroes into -0.0, with no branches.Unfortunately I'm unable to test properly as Compiler Explorer is giving SIGILL - presumably because it's running on some instance which doesn't support this instruction.
Obviously given how recent this instruction is, it's probably not viable for your use-case, but maybe something to consider in future when it's more widely available.
[1]:https://www.intel.com/content/www/us/en/docs/intrinsics-guid...
i would guess that because of how *** * floats are in binary computers, you have something like -0.0000000000000000000000000000000000001 and when you round it you end up with -0.0. Same goes for positive value, you're just not used to write the + sign before every number, so seeing the minus feels strange.
You're answering a question that OP did not ask.
What happens if we take the smallest (as in closest to zero) negative subnormal and add it to itself?
Copying the example by sparkie, something like this? https://godbolt.org/z/xhdnb9ax3 I get +0.0 if I comment the round to negative option.