On 2019-04-03 11:44, Warren Young wrote:
> As for the non-ASCII characters, they're UTF-8, which is the de facto
> standard character set on the Internet since around the time of The
> Bubble. Ignoring the embedded world, I can't think of an in-support
> OS that doesn't have built-in support for
On 4/5/19 9:50 AM, Joshua Wise wrote:
> Julian dates are definitely floating point numbers, not integers.
Julian dates, if being used to represent a time on a given date would be
a floating point number. A Julian date, if only needing to express a
time to the precision of a whole Day, could be
Julian dates are definitely floating point numbers, not integers.
On Thu, Apr 4, 2019, 3:37 PM James K. Lowden
wrote:
> On Thu, 4 Apr 2019 11:21:41 -0400
> Joshua Wise wrote:
>
> > > On the other hand, what table has a floating point number in its
> > > key?
> > >
> > > How do you even express
Minor correction:
> On 5 Apr 2019, at 09:52, Lifepillar wrote:
>
> select decStr(decAdd(a,60)), case dec(b) when dec(c) then 1 else 0 end from
> t1;
> select decStr(decAdd(a,70)), case dec(c) when dec(b) then 1 else 0 end from
> t1;
> […]
> select count(*), count(dec(b)), decStr(decSum(b)),
On 5 Apr 2019, at 00:18, Simon Slavin wrote:
>
> On 4 Apr 2019, at 10:12pm, Lifepillar wrote:
>
>> This is essentially a pragmatic choice, as the semantics of NULLs is
>> unspecified and ambiguous.
>
> The way SQL handles NULLs may sometimes appear inconsistent, but is the
> result of SQL
On 4 Apr 2019, at 10:12pm, Lifepillar wrote:
> This is essentially a pragmatic choice, as the semantics of NULLs is
> unspecified and ambiguous.
The way SQL handles NULLs may sometimes appear inconsistent, but is the result
of SQL handling rows as sets. Some of the behaviour is, carefully
On 4 Apr 2019, at 21:36, James K. Lowden wrote:
>
> On Thu, 4 Apr 2019 17:30:29 +0200
> Lifepillar wrote:
>
>> On 4 Apr 2019, at 17:15, James K. Lowden
>> wrote:
>>> On Wed, 3 Apr 2019 14:30:52 +0200
>>> Lifepillar wrote:
SQLite3 Decimal is an extension implementing exact decimal
On Thu, 4 Apr 2019 11:21:41 -0400
Joshua Wise wrote:
> > On the other hand, what table has a floating point number in its
> > key?
> >
> > How do you even express the value of such a key for an exact
> > match?
>
> Well I imagine it can be very useful for range queries. Imagine
> Julian
On Thu, 4 Apr 2019 17:30:29 +0200
Lifepillar wrote:
> On 4 Apr 2019, at 17:15, James K. Lowden
> wrote:
> > On Wed, 3 Apr 2019 14:30:52 +0200
> > Lifepillar wrote:
> >> SQLite3 Decimal is an extension implementing exact decimal
> >> arithmetic for SQLite3.
> >
> > What does divide-by-zero
On 4 Apr 2019, at 17:30, Lifepillar wrote:
>
>> You have the option to ignore the error, though, in which case you get +Inf:
>
> sqlite> delete from decTraps where flag = 'Division by zero';
> sqlite> select decStr(decDiv(1,0));
> Infinity
Forgot to mention that in this case a flag is silently
On 4 Apr 2019, at 17:15, James K. Lowden wrote:
>
> On Wed, 3 Apr 2019 14:30:52 +0200
> Lifepillar wrote:
>
>
>> SQLite3 Decimal is an extension implementing exact decimal arithmetic
>> for SQLite3. It is currently unfinished and under development.
> ...
>> I welcome any feedback, from the
> On the other hand, what table has a floating point number in its key?
>
> How do you even express the value of such a key for an exact match?
Well I imagine it can be very useful for range queries. Imagine Julian dates,
coordinate points, rankings, etc.
I suppose in the most common case,
On Wed, 3 Apr 2019 14:30:52 +0200
Lifepillar wrote:
> SQLite3 Decimal is an extension implementing exact decimal arithmetic
> for SQLite3. It is currently unfinished and under development.
...
> I welcome any feedback, from the super-technical to the
> end-user oriented. There is no manual so
On Wed, 3 Apr 2019 11:37:47 -0600
Warren Young wrote:
> Put another way, your defaults are already so large that no
> conceivable physical entity could build a computer big enough to
> simultaneously contain every distinct state your data type represents.
Exactly (as it were).
Physical
On Wed, 3 Apr 2019 17:29:47 -0400
Richard Hipp wrote:
> On 4/3/19, Joshua Wise wrote:
> > From my naive understanding, memcmp() is used to efficiently
> > compare long strings of bytes. But where in SQLite3 is it necessary
> > to compare long strings of floating point numbers? I, of course,
> >
On 4 Apr 2019, at 10:37, Thomas Kurz wrote:
>
> I appreciate your effort towards this extension. In my opinion, however, this
> is (along with bigint-support) a feature that belongs into core (for that
> reason alone to get math operations, comparisons, aggregates, etc. working in
> an
been plans for "decimal math". The
concept looked very useful and I'd suggest taking that idea up again, but this
time for SQLite3 ;-)
- Original Message -
From: Lifepillar
To: sqlite-users@mailinglists.sqlite.org
Sent: Wednesday, April 3, 2019, 14:30:52
Subject: [sqlite] AN
Oh of course, that makes sense. I suppose that means querying on REAL indexes
should be slower than querying on INTEGER indexes, in the current SQLite3
implementation? Has a benchmark of this ever been done?
> On Apr 3, 2019, at 5:29 PM, Richard Hipp wrote:
>
> On 4/3/19, Joshua Wise wrote:
On 4/3/19, Joshua Wise wrote:
> From my naive understanding, memcmp() is used to efficiently compare long
> strings of bytes. But where in SQLite3 is it necessary to compare long
> strings of floating point numbers? I, of course, can imagine SQL queries
> plucking single floating point values
From my naive understanding, memcmp() is used to efficiently compare long
strings of bytes. But where in SQLite3 is it necessary to compare long strings
of floating point numbers? I, of course, can imagine SQL queries plucking
single floating point values from rows or indexes, but I can’t
On 3 Apr 2019, at 19:37, Warren Young wrote:
>
> On Apr 3, 2019, at 6:30 AM, Lifepillar wrote:
>>
>> By default, the precision is limited to 39 digits and exponents must be
>> in the range [-99,999,999,+99,999,999] (for some mathematical
>> operations, the exponent must not exceed 99,999 in
> On 3 Apr 2019, at 20:04, Joshua Thomas Wise
> wrote:
>
>> [Here, I must thank Dr. Hipp, with whom I had a brief email exchange
>> severals moons ago, who convinced me that the IEEE 754 encoding was not
>> an ideal storage format for databases]
>
> I’m curious, what were the reasons behind
> [Here, I must thank Dr. Hipp, with whom I had a brief email exchange
> severals moons ago, who convinced me that the IEEE 754 encoding was not
> an ideal storage format for databases]
I’m curious, what were the reasons behind Dr. Hipp’s opinion on this?
> On Apr 3, 2019, at 1:56 PM, Simon
On 3 Apr 2019, at 6:51pm, Warren Young wrote:
> On Apr 3, 2019, at 6:30 AM, Lifepillar wrote:
>
>> does SQLite support indexes on blobs?
>
> It claims to:
Indeed. Be careful to verify whether, from the perspective of your programming
language, it considers the first or the last byte to be
On Apr 3, 2019, at 6:30 AM, Lifepillar wrote:
>
> does SQLite support indexes on blobs?
It claims to:
$ sqlite3 x.db
SQLite version 3.26.0 2018-12-01 12:34:55
Enter ".help" for usage hints.
sqlite> create table x (a blob);
sqlite> create index xi on x(a);
sqlite> explain query plan select a
On 3 Apr 2019, at 6:37pm, Warren Young wrote:
> I once calculated that 30 digits was enough to give a precise location to
> every particle the size of a grain of sand or larger in the known universe.
> You just need to define as many columns in your database as is needed for
> your physics:
On Apr 3, 2019, at 7:05 AM, Dominique Devienne wrote:
>
> Seems like you're using non-ascii chars in your source code, notably
> the #pragma mark.
I think you’ve got two nits there, not one.
As for the non-ASCII characters, they’re UTF-8, which is the de facto standard
character set on the
On Apr 3, 2019, at 6:30 AM, Lifepillar wrote:
>
> By default, the precision is limited to 39 digits and exponents must be
> in the range [-99,999,999,+99,999,999] (for some mathematical
> operations, the exponent must not exceed 99,999 in absolute value).
That’s enough. :)
I once calculated
> > SQLite3 Decimal is an extension implementing exact decimal arithmetic
> > for SQLite3. It is currently unfinished and under development.
>
>
> I'm curious, what was your motivation for doing this?
> Use cases envisioned for its use?
Mainly financial applications. Beancount’s author
On Wed, Apr 3, 2019 at 2:31 PM Lifepillar wrote:
> [I hope that this kind of announcement is not off-topic here]
>
Not at all, IMHO.
> SQLite3 Decimal is an extension implementing exact decimal arithmetic
> for SQLite3. It is currently unfinished and under development.
I'm curious, what was
[I hope that this kind of announcement is not off-topic here]
SQLite3 Decimal is an extension implementing exact decimal arithmetic
for SQLite3. It is currently unfinished and under development. At this
point anything, including the user interface and the internals, is
subject to change. I am
31 matches
Mail list logo
