[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: At the edge of LNUM patch
- From: Asko Kauppi <askok@...>
- Date: Wed, 26 Mar 2008 03:07:15 +0200
Doug Currie kirjoitti 25.3.2008 kello 23:27:
On Tuesday, March 25, 2008 Mark Hamburg wrote:
on 3/25/08 1:50 PM, Asko Kauppi at email@example.com wrote:
Mark Hamburg kirjoitti 25.3.2008 kello 18:36:
The patch should kick out of the integer realm at the boundary of
floating-point precision not at the boundary of integer precision.
calculating 2 ^ 63 should result in the value being stored as a
though it could fit into a 64-bit integer.
But this is exactly what it does. The "integer realm" is signed
integers, -2^63 .. +2^63-1 with int64 mode. 2^63 does not fit into a
signed 64-bit integer.
Sorry. I wrote too fast. My point was that even 2 ^ 63 - 1 should
as a double.
Yes, storing any number outside the range -2 ^ 53 to 2 ^ 53 as a
double would avoid the problem.
The easiest way to achieve this is to only use the int32 mode. It
would boost performance on non-FPU platforms, and cause absolutely no
behaviour or accuracy changes on double+int32 configured desktop
machines. I guess the verdict depends on how much value authors
(Roberto et.al.) place on the ability to carry full 64-bit data.