Re: [sqlite] Question about floating point

[Keith Medcalf]

>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 of Floating-Point Arithmetic
> Authors: Muller, J.-M., Brunie, N., de Dinechin, F.,
>  Jeannerod, C.-P., Joldes, M., Lefèvre, V.,
>  Melquiond, G., Revol, N., Torres, S.
>
> This handbook is a definitive guide to the effective use of
> modern floating-point arithmetic, which has considerably
> evolved, from the frequently inconsistent floating-point number 
> systems of early computing to the recent IEEE 754-2008 standard.

https://doc.lagout.org/science/0_Computer%20Science/3_Theory/Handbook%20of%20Floating%20Point%20Arithmetic.pdf

While it is true there is no exact representation of 1/10th in binary floating 
point, at double precision the epsilon is 1.3877787807814457e-17 which means 
that for all intents and purposes 1/10th is exact to 16.9 decimal places.  
Which is pretty damn good for a format that is only purported to be accurate to 
15 decimal digits.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.




___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[James K. Lowden]

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 because a floating point calculation
> in SQLite, exactly as it is run today, led to the following value:
> 
> 211496.252
> 
> which is typical of such problems. 

What problem?  Rounded to the number of significant digits -- 2 decimal
places in the input -- the number is correct.  

--jkl
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Jens Alfke]

> 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 52 bit integer number and appropriate exponent. This way there 
> should be no rounding errors and one would always have a guaranteed precision 
> of ~15 significant digits.


You’re asking why we don’t use base-10 exponents instead of base-2? It’s 
because calculations on such numbers are much slower and more complex than 
binary. (You might as well ask why integers are stored as binary instead of 
BCD!)

—Jens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Tim Streater]

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
> integer number and appropriate exponent. This way there should be no rounding
> errors and one would always have a guaranteed precision of ~15 significant
> digits.

Possibly:





-- 
Cheers  --  Tim
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Dennis Clarke]

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 application.  IEEE
double-precision floating point is accurate to within 15 decimal
digits.  The example given,


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 of Floating-Point Arithmetic
Authors: Muller, J.-M., Brunie, N., de Dinechin, F.,
 Jeannerod, C.-P., Joldes, M., Lefèvre, V.,
 Melquiond, G., Revol, N., Torres, S.

This handbook is a definitive guide to the effective use of
modern floating-point arithmetic, which has considerably evolved,
from the frequently inconsistent floating-point number systems of
early computing to the recent IEEE 754-2008 standard.

I reviewed this chapter by chapter and have looked over the code and if
people were to study the actual mathematics then this whole discussion
would be moot. Okay ... so enough is enough here.

Dennis Clarke
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Thomas Kurz]

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 of most fractions.

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 
integer number and appropriate exponent. This way there should be no rounding 
errors and one would always have a guaranteed precision of ~15 significant 
digits.


- Original Message - 
From: Keith Medcalf 
To: SQLite mailing list 
Sent: Monday, December 17, 2018, 20:12:29
Subject: [sqlite] Question about floating point


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 
representation -- the actual stored value should presumably be 
211496.252200173) and 211496.260931323 is 8.73114913702011e-11, 
or 3 ULP.

Applying half-even rounding at the second "decimal place" to 211496.252 
(which when multiplied by 100 is 21149625.25494194 which half-even 
rounds to 21149626.0 which when divided by 100 is 211496.260931323 or 
exactly the "nearest representable IEEE-754 double precision floating point 
number" to 211496.26

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin
>Sent: Monday, 17 December, 2018 10:36
>To: SQLite mailing list
>Subject: Re: [sqlite] Question about floating point

>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, led to the following value:

>211496.252

>which is typical of such problems.  Please don't consider that
>there's no problem until you have solved that problem.

>Simon.
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Darren Duncan]

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 accurate to within 15 decimal
digits.  The example given,


211496.26


gives, safely, a margin of 6 order of magnitude.  If the application is
taking sums of 100's of thousands of dollars, it will stay accurate to
within a penny using floating point until there are millions of
entries:

10^15 ÷ 10^8 = 10^7

I doubt the financial application exists that sums milliions of entries
AND cares about the last penny.


In modern days, getting to millions of financial transaction entries in a short 
time is common, and we still care about the last penny, I know from experience. 
-- Darren Duncan

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Keith Medcalf]

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:

>> 211496.260931323
>> 211496.25802094

>> The difference between 211496.252 (which is itself a
>> truncated representation -- the actual stored value should presumably
>> be 211496.252200173) and 211496.260931323 is
>> 8.73114913702011e-11, or 3 ULP.

>> Applying half-even rounding at the second "decimal place" to
>> 211496.252 (which when multiplied by 100 is
>> 21149625.25494194 which half-even rounds to 21149626.0 which
>> when divided by 100 is 211496.260931323 or exactly the
>> "nearest representable IEEE-754 double precision floating point
>> number" to 211496.26

> Which brings up an important point…. When saying "double-precision
> floating point is accurate to within 15 decimal digits” it does NOT
> mean floating point can perfectly represent any number up to 15
> digits long, it means that the delta between intent and
> representation is 15 digits smaller than the largest represented
> digit.  In this case, the delta is 10 digits under the radix point,
> plus another 5 or 6 digits from the other side of the radix point.

> In short, the problem _is_ storage… or at least representation.  And
> that’s before calculations muck everything up further.

Which is why:

sqlite> create table x(x);
sqlite> insert into x values(1.0);
sqlite> insert into x values(1.0e100);
sqlite> insert into x values(1.0);
sqlite> insert into x values(-1.0e100);
sqlite> select sum(x) from x;
0.0

but

sqlite> select sum(x) from (select x from x order by abs(x) desc);
2.0

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.





___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Jay Kreibich]

> 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
> 
> The difference between 211496.252 (which is itself a truncated 
> representation -- the actual stored value should presumably be 
> 211496.252200173) and 211496.260931323 is 
> 8.73114913702011e-11, or 3 ULP.
> 
> Applying half-even rounding at the second "decimal place" to 
> 211496.252 (which when multiplied by 100 is 21149625.25494194 
> which half-even rounds to 21149626.0 which when divided by 100 is 
> 211496.260931323 or exactly the "nearest representable IEEE-754 
> double precision floating point number" to 211496.26


Which brings up an important point…. When saying "double-precision floating 
point is accurate to within 15 decimal digits” it does NOT mean floating point 
can perfectly represent any number up to 15 digits long, it means that the 
delta between intent and representation is 15 digits smaller than the largest 
represented digit.  In this case, the delta is 10 digits under the radix point, 
plus another 5 or 6 digits from the other side of the radix point.

In short, the problem _is_ storage… or at least representation.  And that’s 
before calculations muck everything up further.

  -j


>> 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.
>> 

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Keith Medcalf]

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 
representation -- the actual stored value should presumably be 
211496.252200173) and 211496.260931323 is 8.73114913702011e-11, 
or 3 ULP.

Applying half-even rounding at the second "decimal place" to 211496.252 
(which when multiplied by 100 is 21149625.25494194 which half-even 
rounds to 21149626.0 which when divided by 100 is 211496.260931323 or 
exactly the "nearest representable IEEE-754 double precision floating point 
number" to 211496.26

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin
>Sent: Monday, 17 December, 2018 10:36
>To: SQLite mailing list
>Subject: Re: [sqlite] Question about floating point
>
>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, led to the following value:
>
>211496.252
>
>which is typical of such problems.  Please don't consider that
>there's no problem until you have solved that problem.
>
>Simon.
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Simon Slavin]

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, led to the following value:

211496.252

which is typical of such problems.  Please don't consider that there's no 
problem until you have solved that problem.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Mac: Users receive "database disk image is malformed" errors after restoring database from Time Machine backup

[Daniel Alm]

> 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 database files for analysis? 

Unfortunately, I do not know when exactly the corruption occurs. I will send
you an example of a corrupted database in a separate email.

> Olivier Mascia wrote:
> b) Maybe using WAL is not really useful for your use-case, if really there
> is mostly one very short write transaction per minute.  The default
> journal mode might be perfectly adequate. But surely you chose WAL mode
> for some specific reason.  I just don't instantly spot which one from your
> report. 

The reasoning for using WAL is actually to reduce the number of changes to
the main database. Given that our main DB can be ~100 MB in size, having a
WAL reduces the number of times the main DB needs to change, which would
cause a new copy to be made in the Time Machine backup, increasing its size.
That's also why we allow the WAL to grow up to ~8 MB.

> My best guess here is that TimeMachine somehow captures the sqlite DB 
> files a few milliseconds apart "sometimes" so that a journal file that 
> has just been committed is in the TimeMachine backup captured still in 
> its uncommitted state while the DB itself is in the committed state 
> already (or perhaps vice-versa). 

A corruption due to a race condition between updating the main DB and WAL
_should_ be unlikely: We only do one save per minute, and the WAL only gets
checkpointed into the main DB every few hours. So Time Machine would need to
pass over those two files exactly when a checkpointing operation takes
place, which is fairly unlikely.

> Scott Perry wrote:
> Out of curiosity, why aren't you using the SQLite that comes with the OS? 

Using a newer version of SQLite should give us slightly better performance,
especially on older macOS versions (e.g. 10.11). Also, it might have been
easier to link our Swift app with a custom copy of the library than with the
OS-provided one, but I'm not sure about that.



--
Sent from: http://sqlite.1065341.n5.nabble.com/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] add constant to INTEGER PRIMARY KEY

[James K. Lowden]

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 are no "steps".  Each statement is atomic; it is
either executed entirely or not at all.  The contraints on the table
apply to the *user-visible* view of the data: before the update begins,
and after it finishes. They do not apply during the time the DBMS is
updating the data, however it chooses to do so.  

> Letting alone why anyone would want to do such a thing

The following is legal in SQL for a unique column, 

update T set a = a +1

*regardless* of the values in "a".  SQLite is the only DBMS I'm aware
of that prevents the update if "a" is unique and holds consecutive
values.  

That kind of update is neither absurd nor unusual.  An obvious example
is updating all records by 1 day (perhaps because originally
misrecorded).  

--jkl
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[James K. Lowden]

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 example given, 

> 211496.26

gives, safely, a margin of 6 order of magnitude.  If the application is
taking sums of 100's of thousands of dollars, it will stay accurate to
within a penny using floating point until there are millions of
entries:

10^15 ÷ 10^8 = 10^7

I doubt the financial application exists that sums milliions of entries
AND cares about the last penny.   

I've seen advice about using integer arithmetic and implied decimal
points in textbooks.  It's convenient in languages like Cobol, that
support it.  In languages like C, floating point is too convenient --
and accurate -- to ignore.  

I'm sure banks have regulations and approved rounding algorithms.  
In decades of programming on Wall Street, though, we used floating
point for everything.  The only problems I remember involved matching
results between systems when porting: the differences were
insignificant, but because they were visible they had to be explained.
That always took some work.  

--jkl
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[James K. Lowden]

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

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Larry Brasfield]

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, 
subtraction, multiplication and division.  They do not work in 64-bit mode, 
however.  It would be interesting to know why not.

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Larry Brasfield]

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 numbers having a denominator which is a power of 2 can be 
represented.  If that is what you were trying to say, I would point out that it 
is not the representation of the exponent (binary or otherwise) that creates 
the mismatch with (many) rational numbers having a denominator which is a power 
of 10; it is that many such denominators cannot be represented at all when the 
interpretation of the exponent Ne is as 2 ^ Ne.

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Gerry Snyder]

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 point representation
> >> of various amounts of currency does not apply to the real world.
>
> > As do insurance companies and many in the manufacturing world
> (inventory).
> > There is a lot to like about BCD.
>
> And do any processors/computers have hardware for that these days?
>
>
>
I don't think anyone has pointed out that the "evil" is not floating point,
it is the binary exponent.

Just have the exponent be a decimal number, and accept that the mantissa
may have some high-order zeroes.

Gerry Snyder
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Sqlite3 Data Base write failure cases.

[Simon Slavin]

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 your software 
accesses the database only via a single thread, and therefore there can be no 
contention for using that connection.  I will also assume no other program is 
accessing the database at the same time as the software you're concerned about. 
 If those things are not true, post again explaining the exceptions.

For failure cases which can be detected by your software ...

Record the value returned from your _step() or _exec() call.  Check to see 
whether this value is SQLITE_OK ( which is 0 ).  If it is, the command 
succeeded.  If it isn't, it failed, and your program should report the failure 
and react to it.

It's that simple: check to see that the result is 0, and everything else is a 
failure.  You can unpick this slightly, and detect database rule violations 
(e.g. SQLITE_CONSTRAINT == 19 , indicating that you've broken database rules 
you included in the schema) but since your software is meant to be preventing 
all that, it really doesn't matter what the value is, just report or log it and 
quit.

For a list of result codes see



If the command failed, it never the right thing to do to just have your 
software try again.

For failure cases which cannot be detected by your software, read



Simon.


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Tim Streater]

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 apply to the real world.

> As do insurance companies and many in the manufacturing world (inventory).
> There is a lot to like about BCD.

And do any processors/computers have hardware for that these days?


-- 
Cheers  --  Tim
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Sqlite3 Data Base write failure cases.

[Prajeesh Prakash]

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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Digital Dog]

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 earlier, let's compare
max unsigned int64 with sample amount:

2^64
18446744073709551616
11

It seems int64 is easy overflown.

PostgreSQL's NUMERIC data type would be a solution here.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users