I've explained how the regime bits work in one of my recent messages. There are two parameters: total size S and the size of the exponent tail E. The most significant bits of the exponent are expressed in unary ((N+1) 1s, then 0 for non-negative, -N 0s then 1 for negative). The value of the exponent is N*2^E + tail (if abs(N) is too large for the whole tail to fit in the representation, the trailing bits of the tail are assumed to be 0). The mantissa is 1.{remaining bits to the right of the exponent tail} Leo On Mar 27, 2017 12:17, "Mike Speciner" <ms@alum.mit.edu> wrote: You're correct if the integer addition produces "mathematically correct" results and we're talking about 32-bit integers and 64-bit IEEE floats. And the point about javascript is right on. I agree that asinh numbers (particularly when scaled so that they handle denormalized floats) would be problematic for integers. I do like the idea of using asinh in place of log for mapping axes on some graphs/plots. Is there a write-up of posits that actually specifies how the regime bits work--I couldn't really tell from the Gustafson slides. Is there a parameter besides the total number of bits that needs to be specified? --ms On 27-Mar-17 15:06, Dave Dyer wrote:
At 11:50 AM 3/27/2017, Mike Speciner wrote:
No, e.g., int32 x = -1<<31, y = -1 In that case x+y == -1 is definitely not equal to (double)x+(double)y
That's not well behaved in the integer domain either - you ought to get a range exception, but of course you never do.
In cases where the pure integer arithmetic is well behaved, is there any case where the same calculation in IEEE doubles gives a different result?
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun