On Wednesday, September 05, 2007 Simon Davies wrote:
> [...]
> This resolves down to calling a function vxprintf, which has the following
> line:
>while( realvalue>=10.0 && exp<=350 ){ realvalue *= 0.1; exp++; }
> When this line is reached, realvalue has value 98926650.5 and exp value 0.
>
On 9/5/07, Cory Nelson <[EMAIL PROTECTED]> wrote:
> On 9/5/07, Nuno Lucas <[EMAIL PROTECTED]> wrote:
> > What about defining __STD_IEC_559 before the compilation?
> > Acording to this:
> >
> >http://david.tribble.com/text/cdiffs.htm#C99-iec60559
> >
> > C99 allows one to force the compiler to f
On 9/5/07, Nuno Lucas <[EMAIL PROTECTED]> wrote:
> What about defining __STD_IEC_559 before the compilation?
> Acording to this:
>
>http://david.tribble.com/text/cdiffs.htm#C99-iec60559
>
> C99 allows one to force the compiler to follow the standard, so maybe
> libc does it by default, but the
Hi Nuno,
Have tried your suggestion; added __STD_IEC_559 to preprocessor
definitions for the sqlite project in Visual Studio. Same result.
I noted that the preprocessor macro quoted is applicable to C99 and
not C++. So I then tried specifying that Visual Studio compile the
sqlite code as C rather
On 9/5/07, Simon Davies <[EMAIL PROTECTED]> wrote:
[...]
> in sqlite3VdbeMemStringify.
> This resolves down to calling a function vxprintf, which has the following
> line:
>
>while( realvalue>=10.0 && exp<=350 ){ realvalue *= 0.1; exp++; }
>
[...]
> Interestingly, if the line is changed to
>
Hi All,
Here's my 2p...
on XP and VC++ (for my sins!)
The round function works.
sqlite_column_double() returns 98926650.5
The '01' on the end is introduced by calling sqlite_column_text
(in shell.c).
This results in reaching the line
sqlite3_snprintf(NBFS, z, "%!.15g", pMem->r);
in sq
On Wednesday, September 05, 2007 Arjen Markus wrote:
> Doug Currie wrote:
>>I suspect the bug is in the functions that convert between string and
>>double; that's why I keep harping on Steele and White's (and
>>Clinger's) PLDI 1990 papers. What I don't know is why this bug appears
>>in the binar
John Machin wrote:
On 5/09/2007 10:13 AM, John Stanton wrote:
John Machin wrote:
On 5/09/2007 6:18 AM, John Stanton wrote:
These are regular floating point numbers, and behave accordingly.
Utter nonsense. round(98926650.5, 1) -> 98926650.501 is a BUG.
Precisely, As I said, regul
Doug Currie wrote:
I suspect the bug is in the functions that convert between string and
double; that's why I keep harping on Steele and White's (and
Clinger's) PLDI 1990 papers. What I don't know is why this bug appears
in the binary from sqlite.org but not in the version I build myself
with gc
On 9/5/07, Doug Currie <[EMAIL PROTECTED]> wrote:
>
>
> Clinger's) PLDI 1990 papers. What I don't know is why this bug appears
> in the binary from sqlite.org but not in the version I build myself
> with gcc 3.4.5 from SQLite version 3.4.2 source.
>
>
Note it also appears when I compile SQLite from
On Tuesday, September 04, 2007 John Machin wrote:
> On 5/09/2007 6:18 AM, John Stanton wrote:
>> These are regular floating point numbers, and behave accordingly.
> Utter nonsense. round(98926650.5, 1) -> 98926650.501 is a BUG.
I agree with you that there is a bug here somewhere. But it is
On 5/09/2007 10:13 AM, John Stanton wrote:
John Machin wrote:
On 5/09/2007 6:18 AM, John Stanton wrote:
These are regular floating point numbers, and behave accordingly.
Utter nonsense. round(98926650.5, 1) -> 98926650.501 is a BUG.
Precisely, As I said, regular floating point.
"re
John Machin wrote:
On 5/09/2007 6:18 AM, John Stanton wrote:
These are regular floating point numbers, and behave accordingly.
Utter nonsense. round(98926650.5, 1) -> 98926650.501 is a BUG.
Precisely, As I said, regular floating point.
98926650.5 is representable EXACTLY in "regular
On 5/09/2007 6:18 AM, John Stanton wrote:
These are regular floating point numbers, and behave accordingly.
Utter nonsense. round(98926650.5, 1) -> 98926650.501 is a BUG.
98926650.5 is representable EXACTLY in "regular" floating point.
The round function should calculate a scale factor (10
These are regular floating point numbers, and behave accordingly.
Serena Lien wrote:
I have read some of the postings/faq about the difficulties with the round
function, when certain numbers do not have a finite representation in
binary, which SQLite uses. eg 9.95 is actually 9.9499...etc so tha
On 4/09/2007 7:13 AM, Doug Currie wrote:
On Monday, September 03, 2007 Nuno Lucas wrote:
Maybe some OS specific error? Wasn't there some discussion earlier
about the Microsoft compiler not using the full double precision by
default?
Microsoft C compilers store long doubles in 64 bits, just li
On Monday, September 03, 2007 Nuno Lucas wrote:
> Maybe some OS specific error? Wasn't there some discussion earlier
> about the Microsoft compiler not using the full double precision by
> default?
Microsoft C compilers store long doubles in 64 bits, just like
doubles http://msdn2.microsoft.com/
On Mon, 3 Sep 2007 18:29:55 +0100, you wrote:
>This made me to remember there was a bug some time ago about the
>rounding algorithm (but can't remember at what version it was fixed),
>so I just tested it.
>
>"official" amalgamated sqlite 3.4.0 downloaded from the site some time ago:
>
>SQLite vers
On Monday, September 03, 2007 Nuno Lucas wrote:
> This made me to remember there was a bug some time ago about the
> rounding algorithm (but can't remember at what version it was fixed),
> so I just tested it.
> "official" amalgamated sqlite 3.4.0 downloaded from the site some time ago:
> SQLit
On 9/3/07, Doug Currie <[EMAIL PROTECTED]> wrote:
> On Monday, September 03, 2007 Arjen Markus wrote:
>
> > Serena Lien wrote:
>
> >>round(98926650.5, 1) -> 98926650.501
> >>round(85227887.01, 1) -> 85227887.001
>
> > They are in fact rounded, but the internal binary representation can
> >
On Monday, September 03, 2007 Arjen Markus wrote:
> Serena Lien wrote:
>>Okay, but even if the rounded result does not have a finite binary
>>representation, shouldn't the displayed (human readable) representation be
>>at least truncated to the number of decimal places that were requested in
>>t
On Monday, September 03, 2007 Arjen Markus wrote:
> Serena Lien wrote:
>>round(98926650.5, 1) -> 98926650.501
>>round(85227887.01, 1) -> 85227887.001
> They are in fact rounded, but the internal binary representation can
> not be turned into the appropriate decimal (and human readable)
On 9/3/07, Serena Lien <[EMAIL PROTECTED]> wrote:
> Okay, but even if the rounded result does not have a finite binary
> representation, shouldn't the displayed (human readable) representation be
> at least truncated to the number of decimal places that were requested in
> the round function? Not t
Thanks for pointing out the implementation issues. I was thinking only in
the case where I am asking for a string result, not all the time, ie
sqlite3_column_text, where I would want the string representation of the
rounded number in this format, and did not realize this would require
storing all t
Serena Lien wrote:
Okay, but even if the rounded result does not have a finite binary
representation, shouldn't the displayed (human readable) representation be
at least truncated to the number of decimal places that were requested in
the round function? Not that I am confusing round with trunca
Okay, but even if the rounded result does not have a finite binary
representation, shouldn't the displayed (human readable) representation be
at least truncated to the number of decimal places that were requested in
the round function? Not that I am confusing round with truncate, but surely
it is a
Serena Lien wrote:
I have read some of the postings/faq about the difficulties with the round
function, when certain numbers do not have a finite representation in
binary, which SQLite uses. eg 9.95 is actually 9.9499...etc so that round(
9.95, 1) rounds down.
But, I have found several numbers
I have read some of the postings/faq about the difficulties with the round
function, when certain numbers do not have a finite representation in
binary, which SQLite uses. eg 9.95 is actually 9.9499...etc so that round(
9.95, 1) rounds down.
But, I have found several numbers which don't get rounde
28 matches
Mail list logo
