Zefrem and I both misspoke on this, but I clarified on IRC and this was iirc already fixed as a result.
On Tue, Nov 22, 2016 at 11:33 PM, Darren Duncan <[email protected]> wrote: > And here I thought IEEE floats had distinct values to represent overflows > and underflows that were distinct from both the zeros and the infinities. > -- Darren Duncan > > On 2016-11-22 8:19 PM, Zefram wrote: > >> Zoffix Znet via RT wrote: >> >>> The reason we have a negative floating point zero at all is more due to >>> underlying implementations at whose level such zeros are used to signal >>> various exceptions. >>> >> >> No, that's not what negative zero is about in floating point. (Maybe >> you're thinking of ones-complement integer formats.) In floating point, >> zero doesn't only represent exact zero quantities, it also represents >> underflow, and it's useful to know from which side of zero a quantity >> underflowed. Generally, IEEE 754 provides well defined semantics >> for signed zeroes throughout, which put negative zero on a par with >> positive zero. >> >> Are you able to describe any usecases where the string cast resulting >>> in a positive zero as opposed to negative zero creates a problem? >>> >> >> Getting the right zero particularly matters in trigonometry and in complex >> arithmetic, where the zeroes are on opposite sides of many branch cuts. >> For example: >> >> atan2(0e0, -1) >>> >> 3.14159265358979 >> >>> atan2(-0e0, -1) >>> >> -3.14159265358979 >> >> The above behaviour is correct and desirable. In a situation where the >> arguments come from string input, getting this correct behaviour depends >> on the Str->Num conversion properly supporting signed zeroes. >> >> -zefram >> >> > -- brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
