Read that as "sorry i replied to wrong Scott... mine was meant to be a
reply to Scott Hess". Long working days and small and keyboardless mobile
devices are not helping me. Sorry again
Il 23/ott/2015 19:40, "Alessandro Marzocchi"
ha scritto:
> Sorry, i replied to wrong Scott Hess... mine was
Sorry, i replied to wrong Scott Hess... mine was meant to be a reply to his
message...
" Internally, they are base-2 scientific notation,
so asking for more significant digits in the base-10 representation won't
help - base-10 fractional numbers cannot always be represented precisely in
base-2,
Scott actually all base2 fractions are rapresentable as base10
fractions... 10 is divisable by 2.
As for Richard try to think about this... computer does 2 base
calculations as we usually do calculation in base 10. But the same would
happend to us when talking about different bases..
Let's
12 okt 2015, om 20:22, R.Smith:
>
> On 2015-10-12 07:40 PM, Richard Hipp wrote:
>> On 10/12/15, R.Smith wrote:
>>> More explicitly - would these be valid queries:
>>>
>>> SELECT props.*
>>>FROM (
>>> SELECT 1 as id, JSON_OBJECT('i',5,'n','James') AS obj UNION
>>> ALL
>>> SELECT
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
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 report something different.
So using your analogy, I ask a English speaking person a two interrelated
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
Dominique,
Thanks for that idea but now I have more questions?
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 equations evaluating to a "yes" when it
is
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
SQL is a storage and retrieval engine with limited calculation abilities in
support of storage, retrieval and reporting.
You can store numbers as integers, text or floating point and the calling
language can use whatever subroutines to translate and manipulate the
numbers.
If the calling
I didn't see this go through, so I'm sending it again. I got an Alexa spam, so
maybe that's part of it.
I ran the following code on my ARM processor:
double c25 = 0.0;
c25 += 9.2;
c25 += 7.9;
c25 += 0.0;
c25 += 4.0;
c25 += 2.6;
c25 += 1.3;
double n25 = 25.0;
double c23 = 0.0;
c23 +=
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
On Fri, Oct 23, 2015 at 10:45 AM, Alessandro Marzocchi <
alessandro.marzocchi at gmail.com> wrote:
> Scott actually all base2 fractions are rapresentable as base10
> fractions... 10 is divisable by 2.
> As for Richard try to think about this... computer does 2 base
> calculations as we
On Fri, Oct 23, 2015 at 9:33 AM, Marc L. Allen
wrote:
> I ram the following code on my ARM processor:
>
> double c25 = 0.0;
> c25 += 9.2;
> c25 += 7.9;
> c25 += 0.0;
> c25 += 4.0;
> c25 += 2.6;
> c25 += 1.3;
> double n25 = 25.0;
>
It might be illustrative to use the web app at
On Fri, Oct 23, 2015 at 10:47 AM, Hick Gunter wrote:
> Once the binary representation of an integer value becomes longer than the
> mantissa, even integers will start to fall into the space in between
> adjacent floating point values...
>
> asql> select (9007199254740992.0 + 1.0) -
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 :-).
-scott
On Fri, Oct 23, 2015 at 10:40 AM, Alessandro
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
I ram the following code on my ARM processor:
double c25 = 0.0;
c25 += 9.2;
c25 += 7.9;
c25 += 0.0;
c25 += 4.0;
c25 += 2.6;
c25 += 1.3;
double n25 = 25.0;
double c23 = 0.0;
c23 += 9.2;
c23 += 7.8;
c23 += 0.0;
c23 += 3.0;
c23 += 1.3;
c23 += 1.7;
double n23 = 23.0;
On Fri, Oct 23, 2015 at 9:34 AM, 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
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
IEEE754 is an extension that is located in the ext/misc of the standard
distribution. Of course, before equality testing the numbers must be
"normalized" so they have the same exponent ...
SQLite version 3.9.1 2015-10-22 18:06:40
Enter ".help" for usage hints.
Connected to a transient
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
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.
This is also why those other -not lite- engines have a decimal type, processed
using much slower integer logic
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
In one case, you asked "When I add these imprecise values together, do they
equal this other precise value?" In the other case you asked "When I add
these imprecise values together, what is the decimal expansion?" and then
you noticed that the decimal expansion did not equal that precise value.
>> 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 nodes for values which cannot be exactly
>>
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
>17 -> 0x10001 mantissa
>-1 -> 0xf exponent ( or however many bits the exponent is represented by
>exact
Still thinking in decimal...
Value = mantissa * 2 ^ exponent
And not
Vale = mantissa * 10 ^ exponent
___
Gunter Hick
Software Engineer
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
sqlite> select ieee754(1.7);
ieee754(7656119366529843,-52)
or ?00011011001100110011001100110011001100110011001100110011 for the mantissa.
Note that it is an infinitely repeating fraction.
> -Original Message-
> From: sqlite-users-bounces at mailinglists.sqlite.org
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.
SQLite does not use decimal floating point (IEEE 854-1987) or General Decimal
Arithmetic
17 -> 0x10001 mantissa
-1 -> 0xf exponent ( or however many bits the exponent is
represented by
exact
Scott Doctor
scott at scottdoctor.com
On 10/23/2015 12:46 AM, Keith Medcalf wrote:
> You are thinking (and typing) in base 10. Computers use this new-fangled
> thing called
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
Le Mon, 19 Oct 2015 08:41:28 +0200,
"Gert Venter" a ?crit :
> I also received an eMail from alexa within 15 minutes after registering.
>
> GAV
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
>
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.
44 matches
Mail list logo
