On Saturday, 7 November, 2015 09:08, James K. Lowden wrote:
> On Fri, 06 Nov 2015 22:16:57 -0700
> "Keith Medcalf" wrote:
> > I wrote a function called "ulps" which can be used as an extension to
> > SQLite3
> Bravo, Keith!
> One suggestion, if I may. If you expect "ulps" to be used to
On Fri, 06 Nov 2015 22:16:57 -0700
"Keith Medcalf" wrote:
> I wrote a function called "ulps" which can be used as an extension to
> SQLite3
Bravo, Keith!
One suggestion, if I may. If you expect "ulps" to be used to test for
equality, perhaps it would be more convenient to ignore the sign.
On 23-10-15 16:39, Dominique Devienne wrote:
> On Fri, Oct 23, 2015 at 4:16 PM, Rousselot, Richard A <
> Richard.A.Rousselot at centurylink.com> wrote:
>
>> So I decided to output 1000 digits, because why not? So now I am more
>> perplexed with all these digits showing it is working the
On 11/7/2015 3:47 AM, Luuk wrote:
> I was reading this thread just now.
>
> sqlite> select 9.2+7.9+0+4.0+2.6+1.3-25.0, (9.2+7.9)+(0+4.0+2.6+1.3-25.0);
> 3.5527136788005e-15|0.0
>
> ;)
>
>
> (the reasons are probably explained in the parts of the thread that i
> did not read ;)
Among other
> On Thursday, 22 October, 2015, at 13:45, Rousselot, Richard A
> said:
> Doing the following math, why is it that the results are not all returning
> "yes"?
>
> SELECT
> (9.2+7.9+0+4.0+2.6+1.3),
> case when (9.2+7.9+0+4.0+2.6+1.3)=25.0 then "yes" else
> "no"
On 29 October 2015 at 09:46, SQLite mailing list <
sqlite-users at mailinglists.sqlite.org> wrote:
>
> which I understood to mean, "if you can represent it in decimal, you
> can represent it in binary". I didn't think that was true, but there
> seemed to be concensus that it was.
>
The consensus
On 29 Oct 2015, at 2:09am, SQLite mailing list wrote:
> The consensus was the other way: "If you can represent it in binary, you
> can represent it in decimal."
Well that one is actually true. If you can represent any non-recurring
fraction in binary, in decimal it's a non-recurring fraction
At 23:34 28/10/2015, you wrote:
>---
> > Those binary representations can be converted back into precise decimal
> > representations, but those decimal representations will not be the
> original
> > decimal values, because they were translated from decimal strings into
> > binary floating-point
On 28 Oct 2015, at 11:23pm, SQLite mailing list wrote:
> This can't possibly work. "Fuzzy equality" is not transitive (x is close
> enough to y, y is close enough to z, but x is just far enough from z to be
> non-equal), which would break any indexing scheme.
Oh crumbs. You're right. I
On Thu, 29 Oct 2015 10:09:28 +0800
SQLite mailing list wrote:
> The consensus was the other way: "If you can represent it in binary,
> you can represent it in decimal."
Gah, I see now. Thank you for the clarification.
--jkl
Sorry, I missed out my point:
SQLite version 3.8.10.2 2015-05-20 18:17:19
Enter ".help" for usage hints.
sqlite> CREATE TABLE t(r REAL PRIMARY KEY,t TEXT);
sqlite> INSERT INTO t VALUES (21.0,'twenty one point zero');
sqlite> INSERT INTO t VALUES (9.2+7.9+0+1.0+1.3+1.6, 'calculation');
sqlite>
On 28 Oct 2015, at 10:34pm, SQLite mailing list wrote:
> This explains the deficiency in the SQLite print function, but it doesn't
> have to be that way.
I'm with a previous poster. SQLite is primarily a database system. Its
primary jobs are storage and retrieval. It shouldn't really be
On Wed, 28 Oct 2015 17:52:25 + Simon wrote:
> On 28 Oct 2015, at 5:08pm, James K. Lowden
> wrote:
>
> > If we accept what you say, above, then why should
> >
> >> (9.2+7.8+0+3.0+1.3+1.7)
> >
> > in particular present any problem? There's no division. Each value
> > has an exact decimal
On 10/28/2015 7:25 PM, SQLite mailing list wrote:
> On 28 Oct 2015, at 11:23pm, SQLite mailing list mailinglists.sqlite.org> wrote:
>
>> This can't possibly work. "Fuzzy equality" is not transitive (x is close
>> enough to y, y is close enough to z, but x is just far enough from z to be
>>
On 10/28/2015 6:52 PM, SQLite mailing list wrote:
> However, I would support improvement in its floating point calculations,
> including implementing 'slop' in testing for equality. This is not only for
> use when expressions include the equal sign, but also for cases where
> comparing two
On Wed, Oct 28, 2015 at 6:29 PM, SQLite mailing list <
sqlite-users at mailinglists.sqlite.org> wrote:
> On 10/28/2015 7:25 PM, SQLite mailing list wrote:
>
>> On 28 Oct 2015, at 11:23pm, SQLite mailing list <
>> sqlite-users at mailinglists.sqlite.org> wrote:
>>
>> This can't possibly work.
>
> Those binary representations can be converted back into precise decimal
> representations, but those decimal representations will not be the original
> decimal values, because they were translated from decimal strings into
> binary floating-point values and back into decimal strings.
>
>
On 28 Oct 2015, at 5:08pm, James K. Lowden wrote:
> If we accept what you say, above, then why should
>
>> (9.2+7.8+0+3.0+1.3+1.7)
>
> in particular present any problem? There's no division. Each value
> has an exact decimal representation.
You didn't work it out yourself, did you ?
0.2
>> (9.2+7.8+0+3.0+1.3+1.7)
>in particular present any problem? There's no division. Each value
>has an exact decimal representation. I'm prepared to assert that any
>permutation of their sums also has an exact decimal representation.
>Therefore they should have an exact binary representation,
On Wed, Oct 28, 2015 at 3:52 PM, SQLite mailing list <
sqlite-users at mailinglists.sqlite.org> wrote:
> On 28 Oct 2015, at 10:34pm, SQLite mailing list <
> sqlite-users at mailinglists.sqlite.org> wrote:
> > This explains the deficiency in the SQLite print function, but it doesn't
> > have to be
On Fri, 23 Oct 2015 10:43:44 -0700
Scott Hess wrote:
> You're right, any base-2 representation right of the decimal should be
> precise to represent in base-10. But it's the kind of thing where if
> you find yourself counting on it, you probably made a grave error
> earlier in your design :-).
On Wed, Oct 28, 2015 at 10:08 AM, James K. Lowden
wrote:
> On Fri, 23 Oct 2015 10:43:44 -0700 Scott Hess wrote:
> > You're right, any base-2 representation right of the decimal should be
> > precise to represent in base-10. But it's the kind of thing where if
> > you find yourself counting on
On 23 October 2015 at 23:34, Rousselot, Richard A <
Richard.A.Rousselot at centurylink.com> wrote:
> Scott,
>
> I agree with everything you said but... To me if a program/CPU evaluates
> something internally, then when it reports the result it should be the
> result as it sees it. It shouldn't
t; > > language and stick with it. Either answer my question all in English
> > or
> > > > all in Japanese don't mix it.
> > > >
> > > > I think we are getting to hung up on the details of what is going on
> > > > internally. The real que
; coming from the same program, agree? (i.e. return 22.999999
> not
> > > 23.0)
> > >
> > > Richard
> > >
> > > -Original Message-
> > > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:
> > > sqlite-users-boun
> > Richard
> >
> > -Original Message-
> > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:
> > sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Scott Hess
> > Sent: Friday, October 23, 2015 10:05 AM
&g
On Fri, Oct 23, 2015 at 4:16 PM, Rousselot, Richard A <
Richard.A.Rousselot at centurylink.com> wrote:
> So I decided to output 1000 digits, because why not? So now I am more
> perplexed with all these digits showing it is working the opposite of how I
> expected it. Why is the second set of
On 23 October 2015 at 16:08, Dominique Devienne wrote:
> Another good good way to think of IEEE I was presented once with, and which
> kind of gave me a ah-ah moment, is the fact that numbers with exact
> representation fall on the nodes of grid, and there's plenty of "space" in
> between the
On Fri, Oct 23, 2015 at 3:45 PM, Rousselot, Richard A <
Richard.A.Rousselot at centurylink.com> wrote:
> Anyhow, one last question. If the case statements are evaluating
> something that is not a whole number (or better yet not exactly matching on
> both sides of the equation) . Why is it that
...@mailinglists.sqlite.org] On Behalf Of Scott Hess
Sent: Friday, October 23, 2015 10:05 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Simple Math Question
On Fri, Oct 23, 2015 at 7:39 AM, Dominique Devienne
wrote:
> On Fri, Oct 23, 2015 at 4:16 PM, Rousselot, Rich
On 23 Oct 2015, at 2:45pm, Rousselot, Richard A wrote:
> Sorry, I seemed to kick off a nerd fight. :)
Please don't apologise. It's the most fun we've had in ages.
Simon.
AFAICT system 360 machines had BCD in microcode, just like any other
basic datatype. Z is only the renamed survivor of 360/xx and 370/xxx
"boxes".
At 14:33 23/10/2015, you wrote:
>---
>On Fri, Oct 23, 2015 at 3:08 AM, wrote:
>
> > Computers don't store values in base-10 fractions when they
|no
-Original Message-
From: sqlite-users-bounces at mailinglists.sqlite.org
[mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Dominique
Devienne
Sent: Friday, October 23, 2015 8:54 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Sim
Sorry, I seemed to kick off a nerd fight. :)
Anyhow, one last question. If the case statements are evaluating something
that is not a whole number (or better yet not exactly matching on both sides of
the equation) . Why is it that when displaying the results of the math sqlite
does not
On Thu, Oct 22, 2015 at 09:27:43PM +0100, Simon Slavin wrote:
> Financial software frequently handles all currency amounts as pence or
> cents for the reasons you've just found out.
Most financial processing is done on mainframes which have had fixed point
decimal types (in hardware) since the
gt; >
> > -Original Message-
> > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:
> > sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Scott Hess
> > Sent: Friday, October 23, 2015 10:05 AM
> > To: General Discussion of SQLite Database
&g
...@mailinglists.sqlite.org] On Behalf Of Jim Callahan
Sent: Friday, October 23, 2015 11:19 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Simple Math Question
Pocket calculators and COBOL used binary coded decimal (bcd) numbers to avoid
the representation/round off issues. But this meant another
Pocket calculators and COBOL used binary coded decimal (bcd) numbers to
avoid the representation/round off issues. But this meant another entire
number type (supported with addition, subtraction and having to be type
checked in functions) in addition to integer and floating point; most found
it
ails of what is going on
> > > internally. The real question is why don't the two results, which are
> > > coming from the same program, agree? (i.e. return 22.99
> not
> > > 23.0)
> > >
> > > Richard
> > >
> > > -Ori
gt;
> -Original Message-
> From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:
> sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Jim Callahan
> Sent: Friday, October 23, 2015 11:19 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Si
t; > answers one question in Japanese and another in English. I say pick
> a
> > > > language and stick with it. Either answer my question all in English
> > or
> > > > all in Japanese don't mix it.
> > > >
> > > > I think we are getting
On Oct 23, 2015, at 10:36 AM, Scott Hess wrote:
>
> Indeed, and the cost was the need to have two completely independent math
> systems, one precise and one fast. For obvious reasons over time people
> who did a lot of math just figured out how to make the fast one precise
> enough for their
On Oct 23, 2015, at 7:41 AM, Jean-Christophe Deschamps
wrote:
> AFAICT system 360 machines had BCD in microcode, just like any other basic
> datatype. Z is only the renamed survivor of 360/xx and 370/xxx "boxes".
>
The Motorola 680x0 chips (used in the original Macintosh systems) also had
Discussion of SQLite Database
Subject: Re: [sqlite] Simple Math Question
Pocket calculators and COBOL used binary coded decimal (bcd) numbers to avoid
the representation/round off issues. But this meant another entire number type
(supported with addition, subtraction and having to be type
nglists.sqlite.org [mailto:
> sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Scott Hess
> Sent: Friday, October 23, 2015 10:05 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Simple Math Question
>
> On Fri, Oct 23, 2015 at 7:3
On Fri, Oct 23, 2015 at 9:33 AM, Jay Kreibich wrote:
>
> On Oct 23, 2015, at 7:41 AM, Jean-Christophe Deschamps
> wrote:
>
> > AFAICT system 360 machines had BCD in microcode, just like any other
> basic datatype. Z is only the renamed survivor of 360/xx and 370/xxx
> "boxes".
> >
>
>
> The
;>> Decimal(5910974510923777) * Decimal(2**-48)
Decimal('21.00355271367880')
> -Original Message-
> From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-
> bounces at mailinglists.sqlite.org] On Behalf Of Dominique Devienne
> Sent: Friday, 23
On Fri, Oct 23, 2015 at 10:09 AM, Scott Doctor
wrote:
>
> 17 -> 0x10001 mantissa
>
Not in IEEE binary rep based on the 1/2^i fraction I describe above.
0.17 would be 0/2 + 0/4 + 1/8 (0.125) + ... (whatever 1/2^1 fractions
approximate best the remainder of 0.17 - 0.125). --DD
coded in their engines... but this doesn't make
the current floating point arithmetic broken in any way.
Bert
From: Scott Doctor
Sent: vrijdag 23 oktober 2015 09:30
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Simple Math Question
Something sounds wrong with this floating
On Fri, Oct 23, 2015 at 9:46 AM, Keith Medcalf wrote:
> You are thinking (and typing) in base 10. Computers use this new-fangled
> thing called binary -- base 2.
> The "floating point" type is IEEE 754 double precision binary (base 2)
> floating point.
>
On Thu, Oct 22, 2015 at 11:55 PM, Igor Tandetnik wrote:
> On 10/22/2015 4:25 PM, Rousselot, Richard A wrote:
>
>> FWIW, MySQL and Oracle both return all yes for that query.
>>
>
> In MySQL, 9.2 is a literal of DECIMAL type, which is in fact represented
> as a finite decimal fraction. SQLite
sqlite.org] On Behalf Of Scott Hess
> Sent: Friday, October 23, 2015 10:05 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Simple Math Question
>
> On Fri, Oct 23, 2015 at 7:39 AM, Dominique Devienne
> wrote:
>
> > On Fri, Oct 23, 2015 at 4:16 PM
On Fri, Oct 23, 2015 at 8:19 AM, Jim Callahan <
jim.callahan.orlando at gmail.com> wrote:
> Pocket calculators and COBOL used binary coded decimal (bcd) numbers to
> avoid the representation/round off issues. But this meant another entire
> number type (supported with addition, subtraction and
On Fri, Oct 23, 2015 at 7:39 AM, Dominique Devienne
wrote:
> On Fri, Oct 23, 2015 at 4:16 PM, Rousselot, Richard A <
> Richard.A.Rousselot at centurylink.com> wrote:
> > So I decided to output 1000 digits, because why not? So now I am more
> > perplexed with all these digits showing it is
On Fri, Oct 23, 2015 at 7:41 AM, Jean-Christophe Deschamps wrote:
> AFAICT system 360 machines had BCD in microcode, just like any other basic
> datatype. Z is only the renamed survivor of 360/xx and 370/xxx "boxes".
>
I believe that's true. But only the latest z machines have DFP (Decimal
On Fri, Oct 23, 2015 at 3:08 AM, wrote:
> Computers don't store values in base-10 fractions when they use doubles or
> floats; they use base-2 fractions. This causes that your simple base-10
> fractions can't be stored exactly.
>
?Unless the architecture implements the newest IEEE-754-2008
On 23 Oct 2015, at 2:01am, Keith Medcalf wrote:
>> Financial software frequently handles all currency amounts as pence or
>> cents for the reasons you've just found out. Annoys the heck out of
>> bankers until you have them work problems by hand and seen just how stupid
>> computers really
ite-users-
> bounces at mailinglists.sqlite.org] On Behalf Of Dominique Devienne
> Sent: Friday, 23 October, 2015 02:12
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Simple Math Question
>
> On Fri, Oct 23, 2015 at 10:09 AM, Scott Doctor
> wrote:
> Sent: Friday, 23 October, 2015 01:31
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Simple Math Question
>
> Something sounds wrong with this floating point issue. His example
> consists of two digit numbers with simple addition. The number 1.7 would
> be rep
r, 2015 01:31
>> To: General Discussion of SQLite Database
>> Subject: Re: [sqlite] Simple Math Question
>>
>> Something sounds wrong with this floating point issue. His example
>> consists of two digit numbers with simple addition. The number 1.7 would
>> be rep
Something sounds wrong with this floating point issue. His example
consists of two digit numbers with simple addition. The number 1.7 would
be represented by the value 17 and an exponent of -1, which is an exact
number, same with his other numbers. His math operations should give
exact results
On 22 Oct 2015 at 21:25, Richard A Rousselot wrote:
> I fully expected something like this from a fractional number like 1/3 but
> didn't realize that this would be the case if when the digits were explicitly
> stated and they summed to a whole number. I will use a Cast statement to
> resolve.
Le Thu, 22 Oct 2015 19:45:09 +,
"Rousselot, Richard A" a ?crit :
> Doing the following math, why is it that the results are not all returning
> "yes"?
>
> SELECT
> (9.2+7.9+0+4.0+2.6+1.3),
> case when (9.2+7.9+0+4.0+2.6+1.3)=25.0 then "yes" else "no"
> end,
If I recall, he had a printout of the state at each time unit. The state was
represented as a set of numbers out to 6 decimal points.
He wanted to rerun part of the simulation, so he entered in those super-precise
numbers and let them run, but the model quick diverged because those numbers
On Thu, Oct 22, 2015 at 9:45 PM, Rousselot, Richard A <
Richard.A.Rousselot at centurylink.com> wrote:
> Doing the following math, why is it that the results are not all returning
> "yes"?
>
> SELECT
> (9.2+7.9+0+4.0+2.6+1.3),
> case when
On 22 Oct 2015, at 8:45pm, Rousselot, Richard A wrote:
>(9.2+7.9+0+1.0+1.3+1.6),
If you really are handling a lot of numbers with exactly one decimal place, the
answer is to multiply them all by 10 are part of your input routine, and store
them all as integers. On the other
: [sqlite] Simple Math Question
On Thu, Oct 22, 2015 at 9:45 PM, Rousselot, Richard A < Richard.A.Rousselot at
centurylink.com> wrote:
> Doing the following math, why is it that the results are not all
> returning "yes"?
>
> SELECT
> (9.2+7.9+0+4.0+2
Doing the following math, why is it that the results are not all returning
"yes"?
SELECT
(9.2+7.9+0+4.0+2.6+1.3),
case when (9.2+7.9+0+4.0+2.6+1.3)=25.0 then "yes" else "no" end,
(9.2+7.8+0+3.0+1.3+1.7),
case when
> Financial software frequently handles all currency amounts as pence or
> cents for the reasons you've just found out. Annoys the heck out of
> bankers until you have them work problems by hand and seen just how stupid
> computers really are.
Usually as hundredths (1/100) of a cent -- that is,
riginal Message-
> From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-
> bounces at mailinglists.sqlite.org] On Behalf Of Rousselot, Richard A
> Sent: Thursday, 22 October, 2015 13:45
> To: 'sqlite-users at mailinglists.sqlite.org'
> Subject: [sqlite] Simple M
On 10/22/2015 4:25 PM, Rousselot, Richard A wrote:
> I fully expected something like this from a fractional number like 1/3 but
> didn't realize that this would be the case if when the digits were explicitly
> stated and they summed to a whole number. I will use a Cast statement to
> resolve.
On 10/22/2015 3:45 PM, Rousselot, Richard A wrote:
> Doing the following math, why is it that the results are not all returning
> "yes"?
For the same reason that 0.33 + 0.33 + 0.33 !=
1. 0.33 is only approximately equal to 1/3, and the error
tends to
72 matches
Mail list logo
