On Wednesday, 19 February, 2020 21:24, ethan he wrote:
>There is a SQLITE DATABASE has “MeslocallD”(INTEGER PRIMARY KEY
>AUTOINCREMENT),
>Is that possible to delete the data but still keep the MeslocallD
>consistence?
Assuming that by "consistence" you mean the high-water mark for inserted rowi
Hi,
There is a SQLITE DATABASE has “MeslocallD”(INTEGER PRIMARY KEY AUTOINCREMENT),
Is that possible to delete the data but still keep the MeslocallD consistence?
Thanks for your help
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
On Jan 4, 2020, at 12:23 AM, Mike King wrote:
>
> This is the subject:
>
> Hex Password with System.Data.Sqlite (.Net Core)
My Python-fu sucks, but I don’t think that can match the administrivia rule:
https://gitlab.com/mailman/mailman/blob/master/src/mailman/rules/administrivia.py
It lo
On 4 Jan 2020, at 7:23am, Mike King wrote:
> This is the subject:
>
> Hex Password with System.Data.Sqlite (.Net Core)
I suppose the bot thought you wanted to change your password for accessing the
mailing list.
___
sqlite-users mailing list
sqlite-u
This is the subject:
Hex Password with System.Data.Sqlite (.Net Core)
Very to the point I’d say :)
Cheers
On Fri, 3 Jan 2020 at 23:10, Warren Young wrote:
> On Jan 2, 2020, at 3:47 PM, Mike King wrote:
> >
> > ...suspected administrivia! (not sure what that is -
> > I guess it's a US Englis
On Jan 2, 2020, at 3:47 PM, Mike King wrote:
>
> ...suspected administrivia! (not sure what that is -
> I guess it's a US English word but it's certainly not an English one).
It’s not defined in any of the mainstream dictionaries I have on my phone —
three of them, because I’m a word nerd — but
On Thursday, 2 January, 2020 15:48, Mike King wrote:
>I'm porting some code from .Net 4.8 to .Net Core 3.1 using the latest
>System.Data.Sqlite. How do I change / set a database password if my
>password is a byte array? It looks like I can use Pragma Key= if my
>password is text but I use hex pa
I tend to use my hobby code as an excuse to play with and learn the stuff
that I don’t use in the daily grind. It also helps me keep up to date
(hence .Net core 3.1). So, to answer your question encryption is important
:)
Cheers
Mike
On Fri, 3 Jan 2020 at 01:27, Simon Slavin wrote:
> On 3 Jan
On 3 Jan 2020, at 12:44am, Mike King wrote:
> Ok thanks. As this is a hobby project I don't have any cash for commercial
> extensions.
So the question becomes whether you actually need encryption in your hobby
project, or you were just using encryption because you started off with an
encrypted
Ok thanks. As this is a hobby project I don't have any cash for commercial
extensions.
Cheers
On Fri, 3 Jan 2020 at 00:18, Joe Mistachkin wrote:
>
> Mike King wrote:
> >
> > Should I be using a specific encryption extension? When I used the .Net
> > Framework SQLite lib I always used the encryp
Mike King wrote:
>
> Should I be using a specific encryption extension? When I used the .Net
> Framework SQLite lib I always used the encryption that came with it.
>
The CryptoAPI-based encryption included with System.Data.SQLite is a
legacy feature, has known issues, and is officially unsuppo
I'll be honest I'm not sure. I'm using the whatever encryption comes with
the nuget package for Core 3.1.
Should I be using a specific encryption extension? When I used the .Net
Framework SQLite lib I always used the encryption that came with it.
Cheers
On Thu, 2 Jan 2020 at 22:57, Joe Mistachki
Which encryption extension are you using?
Sent from my iPhone
> On Jan 2, 2020, at 5:48 PM, Mike King wrote:
>
> Hi,
>
> This is my third attempt to send the following message to the list and each
> time it gets rejected as suspected administrivia! (not sure what that is -
> I guess it's a U
Hi,
This is my third attempt to send the following message to the list and each
time it gets rejected as suspected administrivia! (not sure what that is -
I guess it's a US English word but it's certainly not an English one).
I'm porting some code from .Net 4.8 to .Net Core 3.1 using the latest
S
IfNull works beautifully to allow
for this. Why it works with Max(idate) on the first select, I don't know, but,
if I take it out, it does not. Thanks.
> Doug
> > -Original Message-
> > From: sqlite-users, on
Jose Isaias Cabrera
> > Sent: Monday, November 18,
alf Of Jose Isaias Cabrera
> Sent: Monday, November 18, 2019 12:11 PM
> To: 'SQLite mailing list'
> Subject: Re: [sqlite] Question about: Adding a record to a table
> with select failure
>
>
> Doug, on Monday, November 18, 2019 12:31 PM, wrote...
> Jose Isaias Ca
Peter da Silva, on Monday, November 18, 2019 08:07 PM, wrote...
>
> Assuming I'm understanding what the original message was about.
>
> Isn't this what BEGIN; INSERT OR IGNORE; UPDATE; COMMIT is the right tool for?
The original message was about adding a new record using old values from an
exist
Thanks, Keith.
Keith Medcalf, on Monday, November 18, 2019 07:25 PM, wrote...
>
>
> On Monday, 18 November, 2019 15:01, Jose Isaias Cabrera, on
>
> >Keith Medcalf, on Monday, November 18, 2019 04:27 PM, wrote...
> >>
> >> This relies on two implementation details particular to SQLite3 which
> >>
Simon Slavin, on Monday, November 18, 2019 05:14 PM, wrote...
> Being completely serious, whenever I see "undocumented" or "implementation
> dependent" or
> "optimization side-effect", or a SQL statement I can't parse in my head, I
> usually decide
> to do it in my programming language instead.
Assuming I'm understanding what the original message was about.
Isn't this what BEGIN; INSERT OR IGNORE; UPDATE; COMMIT is the right tool for?
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailm
On Monday, 18 November, 2019 15:01, Jose Isaias Cabrera
wrote:
>Keith Medcalf, on Monday, November 18, 2019 04:27 PM, wrote...
>>
>> This relies on two implementation details particular to SQLite3 which
>> hold at present, but may of course change at any time:
>> (1) that selecting a non-aggreg
Not sure this helps, a way to a conditionally insert based on if record
already exists, is a select with literals left outer joined to the maybe
record and use a where test value is null.
Something like this pseudo SQL
insert into T (valueA, valueB') (select 'ValueA', 'ValueB' left outer
join T
On 18 Nov 2019, at 10:00pm, Jose Isaias Cabrera wrote:
> Thanks Keith. So, you are saying that this is a bad INSERT, and I don't know
> much to argue, but is working. If I take out the first IfNull, and there is
> not, at least one instance of 'p006' in the table, the INSERT never works. I
>
t;SELECT (a,b,c,d,e,idate) from t where a = "p006"
> >
> >Doesn't the where clause that cannot be satisfied in both cases guarantee
> >that no rows will be selected, when there are no records in the database?
> >Doug
> >
> >> -Original Message-
> >
ot an aggregate causing "all hell to break
loose".
--
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 On
>Behalf Of Doug
>Sent: Monday, 18 November, 20
Doug, on Monday, November 18, 2019 02:48 PM, wrote...
>
> I'm really confused now. I don't understand the semantics of:
> SELECT IfNull('p006', Max(idate)),
>IfNull(b, 1),
>IfNull(c, 2),
>'y',
>IfNull(e, 4),
>'2019-20-12'
> FROM t
> WHERE a = 'p006';
>
>
rera
> Sent: Monday, November 18, 2019 12:11 PM
> To: 'SQLite mailing list'
> Subject: Re: [sqlite] Question about: Adding a record to a table
> with select failure
>
>
> Doug, on Monday, November 18, 2019 12:31 PM, wrote...
> Jose Isaias Ca
Doug, on Monday, November 18, 2019 12:31 PM, wrote...
Jose Isaias Cabrera
[clip]
> > >
> > > INSERT INTO t (a, b, c, d, e, idate)
> > > SELECT IfNull('p006', Max(idate)),
> > >IfNull(b, 1),
> > >IfNull(c, 2),
> > >'y',
> > >IfNull(e, 4),
> > >'2019-20-
> -Original Message-
> From: sqlite-users
> On Behalf Of Jose Isaias Cabrera
> Sent: Saturday, November 16, 2019 10:43 AM
> To: SQLite mailing list
> Subject: Re: [sqlite] Question about: Adding a record to a table
> with select failure
>
>
> Jake Thaw,
Jake Thaw, on Saturday, November 16, 2019 08:39 AM, wrote...
>
> One approach might be something like this:
>
> INSERT INTO t (a, b, c, d, e, idate)
> SELECT 'p006',
>Coalesce(b, 1),
>Coalesce(c, 2),
>'y',
>Coalesce(e, 4),
>'2019-20-12'
> FRO
One approach might be something like this:
INSERT INTO t (a, b, c, d, e, idate)
SELECT 'p006',
Coalesce(b, 1),
Coalesce(c, 2),
'y',
Coalesce(e, 4),
'2019-20-12'
FROM (SELECT 1)
LEFT JOIN
(SELECT a, b, c, e FROM t WHERE a = 'p006' ORDER BY idate DESC LI
On 15 Nov 2019, at 9:04pm, Jose Isaias Cabrera wrote:
> CASE
> SELECT a from t WHERE a = 'p006' idate desc limit 1
>WHEN a = NULL
>THEN 'p006',1,2,'y',4,'2019-02-12'
>ELSE SELECT a, b, c, 'y', e, '2019-20-12' from t WHERE a = 'p006' idate
> desc limit 1
>END
The thing af
Doug, on Friday, November 15, 2019 11:42 AM, wrote...
>
> WRT Jose's original context, and just for my enlightment, what happens with
> the following:
>
> insert into t (a, b, c, d, e, idate)
> SELECT a, b, c, 'y', e, '2019-02-12' FROM t WHERE a = 'p999';
>
> where p999 does not define a record?
Simon Slavin, on Friday, November 15, 2019 11:58 AM, wrote...
>
> On 15 Nov 2019, at 4:48pm, Jose Isaias Cabrera, on
>
> > It does not get inserted.
>
> The SELECT returns zero lines. Therefore zero lines get inserted. You might
> like to try
> one where the SELECT returns more than one line.
On 15 Nov 2019, at 4:48pm, Jose Isaias Cabrera wrote:
> It does not get inserted.
The SELECT returns zero lines. Therefore zero lines get inserted. You might
like to try one where the SELECT returns more than one line.
___
sqlite-users mailing list
Doug, on Friday, November 15, 2019 11:42 AM, wrote...
>
> WRT Jose's original context, and just for my enlightment, what happens with
> the following:
>
> insert into t (a, b, c, d, e, idate)
> SELECT a, b, c, 'y', e, '2019-02-12' FROM t WHERE a = 'p999';
>
> where p999 does not define a record?
WRT Jose's original context, and just for my enlightment, what happens with the
following:
insert into t (a, b, c, d, e, idate)
SELECT a, b, c, 'y', e, '2019-02-12' FROM t WHERE a = 'p999';
where p999 does not define a record? Is a new record inserted with values of
a,b,c, and e null?
> -O
I noticed that this has been fixed now (
https://www.sqlite.org/src/info/db9acef14d492121). Thanks!
Best,
Manuel
On Fri, May 10, 2019 at 12:09 PM Manuel Rigger
wrote:
> Hi everyone,
>
> I was surprised by how the ROUND function handles "Inf" REAL values.
>
> A REAL infinity value can be created
Hi everyone,
I was surprised by how the ROUND function handles "Inf" REAL values.
A REAL infinity value can be created by using an overly-large number:
SELECT 1e5000; -- Inf
When casting infinity to an integer value, the largest integer is returned,
which seems intuitive to me:
SELECT CAST(1e5
That wasn't "endian" argument, this is an arithmetic operation question,
avoiding extra operations in the common case of small (mag < 2^56)
operands. Since I posted that I've figured out some other optimizations
that work better the way they laid it out, and it makes more sense now.
On Thu, Jan
On 03/01/2019 22:22, Peter da Silva wrote:
Why is the exponent in the low bits, since it forces unnecessary shifts for
integer operations?
That's easy, because the high bits are closer to the barrel shifter, so
it takes less time for the electron to get there![1][2]
Cheers,
Why is the exponent in the low bits, since it forces unnecessary shifts for
integer operations?
On Thu., 3 Jan. 2019, 03:34 Pavlos Christoforou Happy new year all,
>
> Have not followed the full thread, in case it has not been mentioned
> already:
>
> http://dec64.com/
>
>
> Cheers
>
>
> On Tue,
Happy new year all,
Have not followed the full thread, in case it has not been mentioned
already:
http://dec64.com/
Cheers
On Tue, 18 Dec 2018 at 02:42, Keith Medcalf wrote:
> >This thread is getting out of hand. Firstly there is no such binary
> >representation ( in this universe ) for a t
On Sat, 15 Dec 2018 at 15:10, Frank Millman wrote:
> On Dec 15, 2018, at 08.58, Jay Kreibich wrote:
>
> > > On Dec 15, 2018, at 12:49 AM, Frank Millman
> wrote:
> > >
> > > I know that floating point is not precise and not suitable for
> financial uses. Even so, I am curious about the following
On Sun, 16 Dec 2018 at 05:00, Pierre Tempel wrote:
> > “... programs which rely on [the O_CREAT and O_EXCL flags of
> > open(2) to work on filesystems accessed via NFS version 2] for
> > performing locking tasks will contain a race condition. The solution
> > for performing atomic file locking us
On Dec 20, 2018, at 3:38 PM, Igor Tandetnik wrote:
>
> On 12/20/2018 1:34 PM, Dennis Clarke wrote:
>> A more interesting topic of discussion would be the speed and complexity
>> of circuitry designed for another number base such as 5 or even decimal.
>
> https://en.wikipedia.org/wiki/Ternary_com
On 12/20/2018 1:34 PM, Dennis Clarke wrote:
A more interesting topic of discussion would be the speed and complexity
of circuitry designed for another number base such as 5 or even decimal.
https://en.wikipedia.org/wiki/Ternary_computer
--
Igor Tandetnik
__
On 12/19/18 7:51 PM, James K. Lowden wrote:
On Tue, 18 Dec 2018 17:34:29 -0500
Dennis Clarke wrote:
some serious reading and experiments are needed to get a good
handle on why numerical computation is as much art as it is science.
If we wander into the problem without sufficient study and VERY
On Tue, 18 Dec 2018 17:34:29 -0500
Dennis Clarke wrote:
> some serious reading and experiments are needed to get a good
> handle on why numerical computation is as much art as it is science.
> If we wander into the problem without sufficient study and VERY
> careful consideration then we are doom
On Wed, Dec 19, 2018 at 4:57 PM Keith Medcalf wrote:
>
>
> >All I meant was that with a decimal exponent, the units could be
> >dollars,
> >and additions and subtractions of cents would be exact (assuming the
> >mantissa has enough bits), with no worries about rounding. Which is
> >the
> >basis f
>All I meant was that with a decimal exponent, the units could be
>dollars,
>and additions and subtractions of cents would be exact (assuming the
>mantissa has enough bits), with no worries about rounding. Which is
>the
>basis for this whole discussion.
This is called fixed point. All that is r
On Mon, Dec 17, 2018 at 10:04 AM Larry Brasfield
wrote:
> 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 (
Apologies ... I should have included a link to Jean-Michel Muller's work
on "Elementary Functions" and on preserving monotonicity and always
getting correctly rounded results when implementing the elementary
functions in floating-point arithmetic.
https://link.springer.com/book/10.1007/978-1-489
On 12/18/18 6:01 AM, R Smith wrote:> On 2018/12/17 11:53 PM, Dennis
Clarke wrote:
>>
>> 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 b
Although the problem is well known by the readers, may be someone would like
remember the basics (somethin written by me some years ago -in spanish-).
http://www.zator.com/Cpp/E2_2_4a.htm
If you want "play" whiths the numbers in IEE754 this page bay be the fun
(unfortuately, the original is not l
On Mon, Dec 17, 2018 at 2:50 PM Thomas Kurz wrote:
> 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 f
On 12/18/18 6:21 AM, R Smith wrote:
>
> I'm not even going to touch on silly/stupid programming and
> calculations that round along the intermediate steps, those have been
> mentioned already, they are evil and it isn't the fault of the storage
> medium.
Actually, periodically rounding IS a valid
On 2018/12/18 1:21 AM, James K. Lowden wrote:
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.
Wha
On 2018/12/17 11:53 PM, Dennis Clarke wrote:
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 )
>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 b
> 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
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
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.
. 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
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 a
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:
>> 21149
> 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
ys 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 floatin
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, l
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 ex
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
___
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,
subtrac
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
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 po
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 a
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,
On 2018-12-16 6:54 AM, Wout Mertens wrote:
I'd also like to point out a problem with integer money: inflation. For USD
it's been OK so far, but imagine having to handle the Zimbabwean Dollar,
which ended up having 100 trillion dollar notes. Good way to overflow your
integers.
With floating point
> 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.
>
> Cheers,
>
On 2018-12-15 2:15 AM, Frank Millman wrote:
On 2018-12-14 11:24 AM, Darren Duncan wrote:
If yours is a financial application then you should be using exact numeric types
only, such as integers that represent multiples of whatever quantum you are
using, such as cents; fractional numbers are a di
On 2018-12-17 02:41, Simon Slavin wrote:
On 16 Dec 2018, at 2:54pm, Wout Mertens wrote:
imagine having to handle the Zimbabwean Dollar, which ended up having
100 trillion dollar notes. Good way to overflow your integers.
Indeed. But when the crisis started in the early 2000s, the currency
w
Ah, the luxuries of not programming in JavaScript ;)
Anyway, using int64 would not have been sufficient to represent, say, tax
numbers for the country, especially if you worked with cents.
Whereas 53 bits of precision gets you a very long way and can even handle
deflation
The
Wout.
On Sun, D
> Good way to overflow your integers.
> With floating point, that's not a problem.
With int64, it shouldn't be a problem either.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/s
--Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Wout Mertens
>Sent: Sunday, 16 December, 2018 07:55
>To: SQLite mailing list
>Subject: Re: [sqlite] Question about floating point
>
>On Sat, Dec 15, 2018 at 7:13 PM Keith Med
On 16 Dec 2018, at 2:54pm, Wout Mertens wrote:
> imagine having to handle the Zimbabwean Dollar, which ended up having 100
> trillion dollar notes. Good way to overflow your integers.
Indeed. But when the crisis started in the early 2000s, the currency was
devalued by 1000. Then ten zeros we
On Sat, Dec 15, 2018 at 7:13 PM Keith Medcalf wrote:
>
> >And yet ... here we are. The post which started this thread summed
> >currency amounts and reached a total of 211496.252 .
>
> >Yes, you can say 'that would have been rounded before it was
> >printed'. But then you're into the ol
The only way I can think of to have a large counter in a lock is to lock
access to a file containing a counter and I don't know if not-a-file-system
semantics support that.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailingl
It might be worth investigating some other projects that use lock
files. Git, as mentioned locks the index with a lock file, but AFAIK
without counting. As a reference for the NFS issue, see
https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html
section 7.11.2.1, which says
On 12/15/18, Pierre Tempel wrote:
>
> Hm. Doesn't this mean the proposed solution still works, but with
> directories instead of files for the sake of atomicity? I.e. for each
> lock type, create a unique dir name (e.g. ".1.lock") and stat for all
> lock types when changing levels?
I think you pr
No. Unfortunately, if all you have is the presence or absence of a
directory to determine if the file is locked, then that is only one
bit of information. And there is no way to encode all the other
locking states in a single bit.
Hm. Doesn't this mean the proposed solution still works, but with
On Saturday, 15 December, 2018 10:54, Simon Slavin wrote:
>On 15 Dec 2018, at 5:35pm, Keith Medcalf wrote:
>> Fast forward 25 years and you would these days be hard pressed to
>find a computer that DOES NOT use proper IEEE-754 floating point and
>that DOES NOT default to a minimum of double pre
On 15 Dec 2018, at 5:35pm, Keith Medcalf wrote:
> Fast forward 25 years and you would these days be hard pressed to find a
> computer that DOES NOT use proper IEEE-754 floating point and that DOES NOT
> default to a minimum of double precision representation and that DOES NOT use
> extended pr
On Friday, 14 December, 2018 23:49, Frank Millman wrote:
> I know that floating point is not precise and not suitable for
> financial uses.
This is debatable. In the "old days" of what was called "fast floating point"
it was certainly true since the epsilon of a "fast floating point" number
On 12/15/18, Pierre Tempel wrote:
>
> First, dot-file actually uses a directory, however, the comments don't seem
> to give a reason for this. Why is a directory created, instead of a more
> (arguably) traditional lock file (see e.g. git)? dotlockLock creates the
> directory with permissions set t
Hi,
I'm currently working with a system where dot-file is the only applicable
SQLITE_ENABLE_LOCKING_STYLE and I'm trying to understand how this is
implemented exactly. So I've read through the implementation of this
locking strategy and a few questions came to mind:
First, dot-file actually uses
On 15 Dec 2018, at 10:15am, Frank Millman wrote:
> Simon Slavin says ‘Currency amounts should be stored as integers’. Does this
> apply to sqlite3 specifically, or is that your recommendation for all
> databases?
For anything that goes near a computer. I used to work with international
banki
On 15 Dec 2018, at 10:15, Frank Millman wrote:
Simon Slavin says ‘Currency amounts should be stored as integers’.
Does this apply to sqlite3 specifically, or is that your
recommendation for all databases?
It doesn't matter whether a database is involved.
Using integers for currency amounts i
On 2018-12-14 11:24 AM, Darren Duncan wrote:
>
> If yours is a financial application then you should be using exact numeric
> types
only, such as integers that represent multiples of whatever quantum you are
using, such as cents; fractional numbers are a display or user input format
only, and
On 15 Dec 2018, at 9:24am, Darren Duncan wrote:
> If yours is a financial application then you should be using exact numeric
> types only, such as integers that represent multiples of whatever quantum you
> are using, such as cents; fractional numbers are a display or user input
> format only,
If yours is a financial application then you should be using exact numeric types
only, such as integers that represent multiples of whatever quantum you are
using, such as cents; fractional numbers are a display or user input format
only, and in those cases they are character strings. -- Darren
1 - 100 of 922 matches
Mail list logo
