> 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
___
Gunter Hick | Software Engineer | Scientific Games International GmbH |
Regarding additional uses for the sign of zero:
Branch Cuts for Complex Elementary Functions, or Much Ado About
Nothing's Sign Bit in The State of the Art in Numerical Analysis,
(eds. Iserles and Powell), Clarendon Press, Oxford, 1987.
https://people.freebsd.org/~das/kahan86branch.pdf
On Wed,
On Wed, Jun 12, 2019 at 12:02 PM David Raymond
wrote:
> https://www.sqlite.org/fileformat2.html#record_format
>
> The storage type of each record is given by an integer. And in the current
> format, all non-negative integers are used.
>
Ouch. Yes, an additional data type was closer to what I
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
--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
On Thu, 13 Jun 2019 at 01:28, Richard Hipp wrote:
> On 6/12/19, Jonathan Brandmeyer wrote:
> > IMO, when acting as a storage engine, SQLite should be good to the last
> > bit.
>
> That is already the case, and has been for 17 years. The question at
> hand is what should SQLite do when the
On 12 Jun 2019, at 10:28pm, James K. Lowden wrote:
> what kind of computation
> would lead to a value in memory representing -0,0?
Here's the classic answer. It's not very impressive or convincing because it
just kicks the can further down the road.
Suppose you have a system like IEEE754
On Wed, 12 Jun 2019 12:57:22 -0400
Richard Hipp wrote:
> On 6/12/19, Thomas Kurz wrote:
> >> For an SQL engine, the next-best-thing to strict binary IEEE754 is
> >> not
> > sloppy binary IEEE754, its probably strict decimal IEEE754.
> >
> > That would be a *really great* improvement!
>
> It
On Wed, 12 Jun 2019 10:28:20 -0600
"Keith Medcalf" wrote:
> Python 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 22:22:05) [MSC v.1916
> 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or
> "license" for more information.
> >>> a = -0.0
> >>> b = 0.0
> >>> print(a,b)
> -0.0 0.0
>
> Really
On 12 Jun 2019, at 9:23pm, Jean-Marie CUAZ wrote:
> A possible solution could be a new function,
> - something like abszero() or trimzero() - acting only on +/- 0.0
Another would be a PRAGMA which sets whether the two values are converted to
text iodentically or differently.
> what should SQLite do when the application asks it to convert
> a -0.0 value into text. It is only the binary-to-text conversion
routine that is at question here.
A possible solution could be a new function,
- something like abszero() or trimzero() - acting only on +/- 0.0
and suppressing
https://www.sqlite.org/fileformat2.html#record_format
The storage type of each record is given by an integer. And in the current
format, all non-negative integers are used.
To me of course that begs the question: Are negative serial types an option?
That would of course mean a full 9 bytes per
James K. Lowden wrote:
> On Wed, 12 Jun 2019 09:35:13 -0400
> Richard Hipp wrote:
>
> > Question: Should SQLite be enhanced to show -0.0 as "-0.0"?
>
> No.
>
> 1. Prior art. I can't think of a single programming language that
> displays -0.0 without jumping through hoops.
I disagree. I
> It would also be a file format change, rendering about 1e12 existing
database files obsolete.
Maybe, but maybe there could be some clever implementation which doesn't break
compatibility. I don't know about the exact internals of how SQlite stores
values in the file. But I think there must be
On Jun 12, 2019, at 10:02 AM, James K. Lowden wrote:
>
> On Wed, 12 Jun 2019 09:35:13 -0400
> Richard Hipp wrote:
>
>> Question: Should SQLite be enhanced to show -0.0 as "-0.0"?
>
> 2. Math. Negative zero is not a mathematical concept.
The best kind of correct:
On Jun 12, 2019, at 10:45 AM, 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
Chrome’s JS
On 6/12/19, Thomas Kurz wrote:
>> For an SQL engine, the next-best-thing to strict binary IEEE754 is not
> sloppy binary IEEE754, its probably strict decimal IEEE754.
>
> That would be a *really great* improvement!
It would also be a file format change, rendering about 1e12 existing
database
> For an SQL engine, the next-best-thing to strict binary IEEE754 is not
sloppy binary IEEE754, its probably strict decimal IEEE754.
That would be a *really great* improvement!
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
In the historical documents of Sqlite4, there has been a note about
"distinguish whether a number is exact or approximate" (or similar). Imho this
information would be more useful than distinguishing between +/- 0.0.
___
sqlite-users mailing list
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 -0.0 as "0.0" or "0": PostgreSQL, MySQL, Oracle, SqlServer
So in my
RUST appears to diddle, but then that is probably the result of the iron oxide
coating:
>type src\main.rs
fn main() {
println!("{} {}", -0.0, 0.0);
println!("{:?} {:?}", -0.0, 0.0);
}
>cargo rr
Compiling demo v0.1.0
Finished release [optimized] target(s) in 0.44s
Running
On Wednesday, 12 June, 2019 10:02, James K. Lowden
wrote:
>1. Prior art. I can't think of a single programming language that
>displays -0.0 without jumping through hoops.
---//--- t.c ---//---
#include
int main(int argc, char** argv)
{
printf("%f %f\n", -0.0, 0.0);
}
---//--- t.c
On 2019/06/12 6:04 PM, Simon Slavin wrote:
On 12 Jun 2019, at 4:35pm, R Smith wrote:
(maybe a sort of CAST target or collation rather than a column "Type")
That's an interesting idea. With a REAL value you get the same things when you
print -0.0 and +0.0. But if you CAST it to a new type
On Wed, Jun 12, 2019, 10:02 AM James K. Lowden
wrote:
> On Wed, 12 Jun 2019 09:35:13 -0400
> Richard Hipp wrote:
>
> > Question: Should SQLite be enhanced to show -0.0 as "-0.0"?
>
> No.
>
> 1. Prior art. I can't think of a single programming language that
> displays -0.0 without jumping
On 12 Jun 2019, at 4:35pm, R Smith wrote:
> (maybe a sort of CAST target or collation rather than a column "Type")
That's an interesting idea. With a REAL value you get the same things when you
print -0.0 and +0.0. But if you CAST it to a new type of I754 then apply
printf to that, you
On Wed, 12 Jun 2019 09:35:13 -0400
Richard Hipp wrote:
> Question: Should SQLite be enhanced to show -0.0 as "-0.0"?
No.
1. Prior art. I can't think of a single programming language that
displays -0.0 without jumping through hoops.
2. Math. Negative zero is not a mathematical
On Wednesday, 12 June, 2019 07:35, Richard Hipp wrote:
>IEEE754 floating point numbers have separate representations for +0.0
>and -0.0. As currently implemented, SQLite always display both
>quantities as just "0.0".
>Question: Should SQLite be enhanced to show -0.0 as "-0.0"? Or,
>would
On 2019/06/12 4:39 PM, Jonathan Brandmeyer wrote:
For an SQL engine, the next-best-thing to strict binary IEEE754 is not
sloppy binary IEEE754, its probably strict decimal IEEE754.
I very much agree on this point, however, unlike the -0.0/+0.0 change,
changing to strict full IEEE754
On 6/12/19, Jonathan Brandmeyer wrote:
> IMO, when acting as a storage engine, SQLite should be good to the last
> bit.
That is already the case, and has been for 17 years. The question at
hand is what should SQLite do when the application asks it to convert
a -0.0 value into text. It is only
IMO, when acting as a storage engine, SQLite should be good to the last
bit. The sign of zero, the least significant bit of any mantissa, and the
payload bits of NaN should all be returned exactly as they were stored.
The history of almost-but-not-quite-IEEE754 arithmetic has been convergence
On 12 Jun 2019, at 2:35pm, Richard Hipp wrote:
> IEEE754 floating point numbers have separate representations for +0.0
> and -0.0.
Like other people I am concerned at confusion when various different parts of
the engine try -0 == +0 or -0 < +0 . I suspect that however you implement it
it
It could be surprising in the example below:
SELECT CAST('-0.0' AS NUMERIC); -- 0.0
SELECT CAST('0.0' AS NUMERIC); -- 0
SELECT CAST('+0.0' AS NUMERIC); -- 0
Best,
Manuel
On Wed, Jun 12, 2019 at 3:57 PM John McKown
wrote:
> On Wed, Jun 12, 2019 at 8:35 AM Richard Hipp wrote:
>
> > IEEE754
On 6/12/19, R Smith wrote:
> Is it any faster or slower?
Adding the ability to show -0.0 slows down our floating-point
benchmark by 0.007% (74,800 CPU cycles out of 943,268,981). For
comparison, the floating-point benchmark is about 17% faster than the
3.28.0 release, due to other unrelated
On Wed, Jun 12, 2019 at 8:35 AM Richard Hipp wrote:
> IEEE754 floating point numbers have separate representations for +0.0
> and -0.0. As currently implemented, SQLite always display both
> quantities as just "0.0".
>
> Question: Should SQLite be enhanced to show -0.0 as "-0.0"? Or,
> would
On 2019/06/12 3:35 PM, Richard Hipp wrote:
IEEE754 floating point numbers have separate representations for +0.0
and -0.0. As currently implemented, SQLite always display both
quantities as just "0.0".
Question: Should SQLite be enhanced to show -0.0 as "-0.0"? Or,
would that create
"...unnecessary confusion", IMHO.
From: sqlite-users on behalf of
Richard Hipp
Sent: Wednesday, June 12, 2019 09:35 AM
To: General Discussion of SQLite Database
Subject: [sqlite] Should SQLite distinguish between +0.0 and -0.0 on output?
IEEE754 floating
IEEE754 floating point numbers have separate representations for +0.0
and -0.0. As currently implemented, SQLite always display both
quantities as just "0.0".
Question: Should SQLite be enhanced to show -0.0 as "-0.0"? Or,
would that create unnecessary confusion?
--
D. Richard Hipp
36 matches
Mail list logo
