> Roberto Bagnara wrote:
> ...
> > $ a.out
> > 70.9
> > 70.905684341886080801486968994140625
> ...
> > $ ./a.exe
> > 70.9
> > 70.90568434188608080148696899414
...
>
Jim Easton wrote:
> With all due respect, why would you want to? With double you are
> guaranteed only 16 o
On Mon, 2006-03-06 at 18:40 +, Dave Korn wrote:
> This is utter fantasy. Floating point hardware either conforms to IEEE754,
> which specifies the exact algorithms to be used in different rounding modes,
> or it is broken.
.. as Intel found out :))
--
John Skaller
Async PL, Realtime sof
On 06 March 2006 17:36, Phil Betts wrote:
[ This is *still* nothing to do with cygwin. It's a newlib issue. I have
set the Reply-To to take this thread to the talk list and removed the other
lists and Jim and Roberto from the Cc line. ]
> I'm absolutely amazed that you are a professor of comp
Roberto Bagnara wrote on Monday, March 06, 2006 9:30 AM::
>
> what is and what is not noise depends on the application.
> In our applications we systematically use controlled rounding on IEEE
> 754 floating point numbers. In the end, what we obtain (in memory)
> are definite (i.e., provably corre
[ X-Posted and Followups set to newlib list; this is almost certainly not a
cygwin specific issue. To recap:- ]
On 03 March 2006 21:44, Roberto Bagnara wrote:
> Hi there,
>
> the following little program
>
> #include
>
> int main() {
>double d;
>scanf("%lf", &d);
>printf("%.10
x <= 70.905684341886080801486968994140625
DOES imply
x <= 70.90568434188608080148696899414
AND vice-versa!
Even in 64 bits IEEE 754 the representations of the 2 numbers are
identical. Anything beyond the 34th decimal digit is made up by the
printf implementation, i.e. it' sn
Jim Easton wrote:
Dear Mr. Bagnara,
Roberto Bagnara wrote:
...
does this on Linux/i686
$ a.out
70.9
70.905684341886080801486968994140625
and does the following under Cygwin on the same machine:
...
$ ./a.exe
70.9
70.90568434188608080148696899414
Why? Is there a wa
Dear Mr. Bagnara,
Roberto Bagnara wrote:
...
> does this on Linux/i686
>
> $ a.out
> 70.9
> 70.905684341886080801486968994140625
>
> and does the following under Cygwin on the same machine:
...
> $ ./a.exe
> 70.9
> 70.90568434188608080148696899414
>
> Why? Is there a w
skaller wrote:
On Sun, 2006-03-05 at 12:44 +0100, Roberto Bagnara wrote:
Tim Prince wrote:
My
past reading of various relevant documents convinced me that digits
beyond the 17th in formatting of doubles are not required by any
standard to be consistent between implementations. They have no
On Sun, 2006-03-05 at 12:44 +0100, Roberto Bagnara wrote:
> Tim Prince wrote:
> My
> > past reading of various relevant documents convinced me that digits
> > beyond the 17th in formatting of doubles are not required by any
> > standard to be consistent between implementations. They have no us
Tim Prince wrote:
Roberto Bagnara wrote:
Hi there,
the following little program
#include
int main() {
double d;
scanf("%lf", &d);
printf("%.1000g\n", d);
return 0;
}
does this on Linux/i686
$ gcc -W -Wall in.c
$ a.out
70.9
70.905684341886080801486968994140625
and does
Roberto Bagnara wrote:
Hi there,
the following little program
#include
int main() {
double d;
scanf("%lf", &d);
printf("%.1000g\n", d);
return 0;
}
does this on Linux/i686
$ gcc -W -Wall in.c
$ a.out
70.9
70.905684341886080801486968994140625
and does the following unde
Hi there,
the following little program
#include
int main() {
double d;
scanf("%lf", &d);
printf("%.1000g\n", d);
return 0;
}
does this on Linux/i686
$ gcc -W -Wall in.c
$ a.out
70.9
70.905684341886080801486968994140625
and does the following under Cygwin on the same mac
13 matches
Mail list logo
