On 6/13/19 10:51 AM, R Smith wrote:
> On 2019/06/13 4:44 PM, Doug Currie wrote:
>>>
>>> Except by the rules of IEEE (as I understand them)
>>>
>>> -0.0 < 0.0 is FALSE, so -0.0 is NOT "definitely left of true zero"
>>>
>> Except that 0.0 is also an approximation to zero, not "true zero."
>>
>>
> Le 13 juin 2019 à 23:29, Richard Hipp a écrit :
>
> You are right. I had forgotten about that point. This has not been
> changed even now, and so -0.0 does get truncated to +0.0 when it is
> stored in the database file.
Would it cost much, performance-wise, to treat double(-0.0) apart and
On 13 Jun 2019, at 11:08pm, Keith Medcalf wrote:
> Note that even when the column is declared with no affinity that NaNs are
> stored as null. Other than NaN, all other IEEE754 double values (including
> subnormals and +/- Inf) seem to round-trip correctly through the bind_double
> and
Note that even when the column is declared with no affinity that NaNs are
stored as null. Other than NaN, all other IEEE754 double values (including
subnormals and +/- Inf) seem to round-trip correctly through the bind_double
and column_double interface ...
---
The fact that there's a
On Fri., 14 Jun. 2019, 7:43 am Keith Medcalf, wrote:
> On Thursday, 13 June, 2019 15:21, Donald Shepherd <
> donald.sheph...@gmail.com> wrote:
>
> >On Fri, 14 Jun 2019 at 7:11 am, Richard Hipp wrote:
>
> >> On 6/13/19, Donald Shepherd wrote:
>
> >>> Given there's been numerous comments to the
On Thursday, 13 June, 2019 15:21, Donald Shepherd
wrote:
>On Fri, 14 Jun 2019 at 7:11 am, Richard Hipp wrote:
>> On 6/13/19, Donald Shepherd wrote:
>>> Given there's been numerous comments to the effect that SQLite
>>> now supports -0.0 storing and retrieval other than printing,
>>> I'm
On 6/13/19, Donald Shepherd wrote:
>
> When I reported that testing on 3.8.7.2 stored -0.0 but retrieved 0.0, your
> comment on this list was that "SQLite converts integer floating point
> values to actual integers for storage (because that takes up less space on
> disk) and then converts back to
On Fri, 14 Jun 2019 at 07:13, Simon Slavin wrote:
> On 13 Jun 2019, at 10:01pm, Donald Shepherd
> wrote:
>
> > Given there's been numerous comments to the effect that SQLite now
> supports
> > -0.0 storing and retrieval other than printing, I'm curious which version
> > this was implemented in
On Fri, 14 Jun 2019 at 7:11 am, Richard Hipp wrote:
> On 6/13/19, Donald Shepherd wrote:
> >
> > Given there's been numerous comments to the effect that SQLite now
> supports
> > -0.0 storing and retrieval other than printing, I'm curious which version
> > this was implemented in as I wouldn't
On 13 Jun 2019, at 10:01pm, Donald Shepherd wrote:
> Given there's been numerous comments to the effect that SQLite now supports
> -0.0 storing and retrieval other than printing, I'm curious which version
> this was implemented in as I wouldn't mind removing my custom code when we
> move to a
On Thursday, 13 June, 2019 15:01, Donald Shepherd
wrote:
>Given there's been numerous comments to the effect that SQLite now
>supports -0.0 storing and retrieval other than printing, I'm curious
>which version this was implemented in as I wouldn't mind removing my
>custom code when we move to
On 6/13/19, Donald Shepherd wrote:
>
> Given there's been numerous comments to the effect that SQLite now supports
> -0.0 storing and retrieval other than printing, I'm curious which version
> this was implemented in as I wouldn't mind removing my custom code when we
> move to a SQLite version
On Fri, 14 Jun 2019 at 3:28 am, Doug wrote:
> It occurs to me that if there are sqlite applications today requiring the
> functionality of -0.0, they have implemented it so that it works for their
> application. Perhaps, they accomplished that by adding a flag bit or by
> some other means.
>
>
On Thursday, 13 June, 2019 11:28, Doug wrote:
>It occurs to me that if there are sqlite applications today requiring
>the functionality of -0.0, they have implemented it so that it works
>for their application. Perhaps, they accomplished that by adding a
>flag bit or by some other means.
>So
It occurs to me that if there are sqlite applications today requiring the
functionality of -0.0, they have implemented it so that it works for their
application. Perhaps, they accomplished that by adding a flag bit or by some
other means.
So if you do nothing about -0.0, you will break no
Hello,
With the json1 extension, we can escape special characters like '['
from being interpreted as an array index by wrapping the path in
double quotes. But sometimes, it does not work:
sqlite> CREATE TABLE test (data TEXT);
sqlite> INSERT INTO test (data) VALUES ('{}');
sqlite> UPDATE test SET
Perhaps this should be handled the same way as Inf and -Inf. For the purposes
of conversion to text the value should be 0.0. However, for the purposes of
.dump the actual -0.0 should be output just as Inf and -Inf are output as 1e999
and -1e999 respectively, since the purpose of .dump is to
On Thu, Jun 13 2019, Richard Hipp wrote:
> On 6/9/19, Landry Breuil wrote:
>>
>> this broke on sparc64
>>>select 298.2564151;
>> -298.2564151
>>
>
> I cannot reproduce this (perhaps because I do not have access to a
> sparc64 platform running OpenBSD) and do not have any good ideas about
> what
On Wed, 12 Jun 2019 18:40:19 -0400
Richard Hipp wrote:
> On 6/12/19, James K. Lowden wrote:
> > what kind of computation
> > would lead to a value in memory representing -0,0?
>
> 0.0/-1.0
Fine. I suspect the reason -0.0 has never cropped up as an issue in my
experience is that -0.0 ==
On Thu, 13 Jun 2019 10:44:52 -0400
Doug Currie wrote:
> > Except by the rules of IEEE (as I understand them)
> >
> > -0.0 < 0.0 is FALSE, so -0.0 is NOT "definitely left of true zero"
> >
>
> Except that 0.0 is also an approximation to zero, not "true zero."
Sure, because floating point
>
> I do not know if this is the result case in any of the programming
> languages, but in Mathematical terms that is just not true.
>
The related IEEE 754 rules are described here:
https://en.wikipedia.org/wiki/Signed_zero
e
___
sqlite-users mailing
On Thu, Jun 13, 2019, 8:51 AM R Smith wrote:
> On 2019/06/13 4:44 PM, Doug Currie wrote:
> >>
> >> Except by the rules of IEEE (as I understand them)
> >>
> >> -0.0 < 0.0 is FALSE, so -0.0 is NOT "definitely left of true zero"
> >>
> > Except that 0.0 is also an approximation to zero, not "true
On 2019/06/13 4:44 PM, Doug Currie wrote:
Except by the rules of IEEE (as I understand them)
-0.0 < 0.0 is FALSE, so -0.0 is NOT "definitely left of true zero"
Except that 0.0 is also an approximation to zero, not "true zero."
Consider that 1/-0.0 is -inf whereas 1/0.0 is +int
I do not
>
>
> Except by the rules of IEEE (as I understand them)
>
> -0.0 < 0.0 is FALSE, so -0.0 is NOT "definitely left of true zero"
>
Except that 0.0 is also an approximation to zero, not "true zero."
Consider that 1/-0.0 is -inf whereas 1/0.0 is +int
e
On 6/9/19, Landry Breuil wrote:
>
> this broke on sparc64
>>select 298.2564151;
> -298.2564151
>
I cannot reproduce this (perhaps because I do not have access to a
sparc64 platform running OpenBSD) and do not have any good ideas about
what might be causing it. If you can get me a temporary
On 6/13/19 1:29 AM, Hick Gunter wrote:
>> 2. Math. Negative zero is not a mathematical concept.
> -0.0 is "too close to distinguish from, but definitely left of true zero",
> which may be significant in some context
>
Except by the rules of IEEE (as I understand them)
-0.0 < 0.0 is FALSE, so
On Wed, Jun 12, 2019 at 6:45 PM Richard Hipp wrote:
> On 6/12/19, James K. Lowden wrote:
> > 1. Prior art. I can't think of a single programming language that
> > displays -0.0 without jumping through hoops.
>
> Prints -0.0 as "-0.0" or just "-0": glibc, Tcl, Python, Javascript
>
> Prints
27 matches
Mail list logo
