> On Dec 17, 2018, at 1:50 PM, Thomas Kurz wrote:
>
> Can someone explain to me why it has been defined this way? Having 1 bit
> sign, 11 bit exponent, and 52 bit mantissa, I would have stored the (in the
> meantime well known) number 211496.26 as 21149626E-2, i.e. I would have
> stored a
>This thread is getting out of hand. Firstly there is no such binary
>representation ( in this universe ) for a trivial decimal number such
>as one tenth ( 0.10 ) and really folks should refer to the text book
>recently published ( 2nd Edition actually ) where all this is covered
>:
> Handbook
On Mon, 17 Dec 2018 17:35:54 +
Simon Slavin wrote:
> On 17 Dec 2018, at 5:16pm, James K. Lowden
> wrote:
>
> > IEEE
> > double-precision floating point is accurate to within 15 decimal
> > digits.
>
> First, the problem is not storage it's calculation.
>
> Second, the thread was started
The "nearest" representation of 211496.26 is 211496.260931323. The two
representable IEEE-754 double precision floating point numbers bounding
211496.26 are:
211496.260931323
211496.25802094
The difference between 211496.252 (which is itself a truncated
Ok, as there seem to be some experts about floating-point numbers here, there
is one aspect that I never understood:
floats are stored as a fractional part, which is binary encoded, and an
integer-type exponent. The first leads to the famous rounding errors as there
is no exact representation
On 17 Dec 2018, at 5:16pm, James K. Lowden wrote:
> IEEE
> double-precision floating point is accurate to within 15 decimal
> digits.
First, the problem is not storage it's calculation.
Second, the thread was started because a floating point calculation in SQLite,
exactly as it is run today,
On 2018-12-17 9:16 AM, James K. Lowden wrote:
On Sat, 15 Dec 2018 01:24:18 -0800
Darren Duncan wrote:
If yours is a financial application then you should be using exact
numeric types only
Color me skeptical. That very much depends on the application. IEEE
double-precision floating point is
On Monday, 17 December, 2018 12:27, Jay Kreibich wrote:
>> On Dec 17, 2018, at 1:12 PM, Keith Medcalf wrote:
>> The "nearest" representation of 211496.26 is
>> 211496.260931323. The two representable IEEE-754 double
>> precision floating point numbers bounding 211496.26 are:
>>
> On Dec 17, 2018, at 1:12 PM, Keith Medcalf wrote:
>
>
> The "nearest" representation of 211496.26 is 211496.260931323. The
> two representable IEEE-754 double precision floating point numbers bounding
> 211496.26 are:
>
> 211496.260931323
> 211496.25802094
>
>
On 12/17/18 3:19 PM, Darren Duncan wrote:
On 2018-12-17 9:16 AM, James K. Lowden wrote:
On Sat, 15 Dec 2018 01:24:18 -0800
Darren Duncan wrote:
If yours is a financial application then you should be using exact
numeric types only
Color me skeptical. That very much depends on the
On 17 Dec 2018, at 21:50, Thomas Kurz wrote:
> Can someone explain to me why it has been defined this way? Having 1 bit sign,
> 11 bit exponent, and 52 bit mantissa, I would have stored the (in the meantime
> well known) number 211496.26 as 21149626E-2, i.e. I would have stored a 52 bit
>
Gerry Snyder wrote:
< I don't think anyone has pointed out that the "evil" is not floating point,
it is the binary exponent.
Disregarding the “evil” appellation, the fundamental fact is that, with modern
floating point hardware (implementing the IEEE-754 standard), only that subset
of rational
Tim Streater wrote:
[Responding to “There is a lot to like about BCD.”]
> And do any processors/computers have hardware for that these days?
The modern X86 descendent processors from AMD and Intel implement AA{A,D,M,S}
instructions, which do the BCD adjustments associated with addition,
On Sat, 15 Dec 2018 10:35:01 -0700
"Keith Medcalf" wrote:
> And the propensity to apply intermediate rounding still exists.
Yes. The only significant errors I've ever seen using floating point
were not due to the computer, but to the programmer.
--jkl
On Sat, 15 Dec 2018 01:24:18 -0800
Darren Duncan wrote:
> If yours is a financial application then you should be using exact
> numeric types only
Color me skeptical. That very much depends on the application. IEEE
double-precision floating point is accurate to within 15 decimal
digits. The
> Richard Hipp wrote:
> Do you know if the corruption is occurring when TimeMachine makes its
> backup, or is occurring when the backed up database is restored? Can
> you capture some unrestored TimeMachine backups to see if they are
> corrupt?
>
> Can you send us one of your corrupted
On Thu, 13 Dec 2018 16:06:04 -0700
"Keith Medcalf" wrote:
> You cannot do that. The PRIMARY KEY is required to be unique at each
> "step" along the way,
For the OP's benefit, this is longstanding, er, idiosyncrasy of
SQLite. It does not conform to the SQL standard.
The SQL rule is there
On Sun, Dec 16, 2018 at 9:26 PM Thomas Kurz wrote:
> > Good way to overflow your integers.
> > With floating point, that's not a problem.
>
> With int64, it shouldn't be a problem either.
>
>
Well.. are you absolutely sure about that?
Considering these Zimbabwe Dollars amounts mentioned
Hi Team,
What are the possible failure cases of DB write in case of single connection.
Because in my application i needs to handle those cases. Can anyone help me for
the same.
Thank you
___
sqlite-users mailing list
On 17 Dec 2018, at 04:32, D Burgess wrote:
>> Banks still use, as they have for a very long time, Binary Coded
>> Decimal, or some equivalent that does not suffer from a loss of
>> accuracy, so all this foofaraw to do with floating point representation
>> of various amounts of currency does not
On Mon, Dec 17, 2018 at 2:43 AM Tim Streater wrote:
> On 17 Dec 2018, at 04:32, D Burgess wrote:
>
> >> Banks still use, as they have for a very long time, Binary Coded
> >> Decimal, or some equivalent that does not suffer from a loss of
> >> accuracy, so all this foofaraw to do with floating
On 17 Dec 2018, at 9:01am, Prajeesh Prakash
wrote:
> What are the possible failure cases of DB write in case of single connection.
> Because in my application i needs to handle those cases. Can anyone help me
> for the same.
You state that you're using a single connection. I will assume
22 matches
Mail list logo
