question : floating point precision.

[Joon Kim]

Can someone help me please ?
for example, when I read floating point from file (ascii)

0.123456789012345678901234567890

compile following program,
using
pgCC compiler with 64 bit AMD opteron processor,

....
int main()
{
FILE *fp;
double f;
char buff[100];

pf = fopen("filename", "r");
fscanf(pf, "%s", buff);
f = atof(buff);
fclose(fp);

printf("%.32f\n", f);
}

then the result is
0.1234567890123456773XXXXX <- X is different from written file.

Can I extend the precision ?

Thank you.

 

[Keith Thompson]

Can someone help me please ?
for example, when I read floating point from file (ascii)

0.123456789012345678901234567890

compile following program,
using
pgCC compiler with 64 bit AMD opteron processor,

...
int main()
{
FILE *fp;
double f;
char buff[100];

pf = fopen("filename", "r");
fscanf(pf, "%s", buff);
f = atof(buff);
fclose(fp);

printf("%.32f\n", f);
}

then the result is 0.1234567890123456773XXXXX <- X is different from
written file.

Can I extend the precision ?

You can use long double rather than double; on most compilers, that
will give you a few more bits of precision.

Compiling and running this program on your system:

#include <stdio.h>
#include <float.h>

int main(void)
{
printf("FLT_DIG = %d\n", FLT_DIG);
printf("DBL_DIG = %d\n", DBL_DIG);
printf("LDBL_DIG = %d\n", LDBL_DIG);
return 0;
}

will give you an idea of how much precision each of the predefined
floating-point types can provide.

I hope the "..." at the top of your program stands for the #include
directives for <stdio.h> and <stdlib.h>.

Incidentally, the atof() function is dangerous; its behavior is
undefined if the value can't be represented. The strtol(), strtof(),
and strtold() functions are a bit more complicated to use, but unlike
atof() they can be used safely.

Recommended reading: section 14 of the comp.lang.c FAQ,
<http://www.c-faq.com/>.

 

[jacob navia]

Can someone help me please ?
for example, when I read floating point from file (ascii)

0.123456789012345678901234567890

compile following program,
using
pgCC compiler with 64 bit AMD opteron processor,

...
int main()
{
FILE *fp;
double f;
char buff[100];

pf = fopen("filename", "r");
fscanf(pf, "%s", buff);
f = atof(buff);
fclose(fp);

printf("%.32f\n", f);
}

then the result is 0.1234567890123456773XXXXX <- X is different from
written file.

Can I extend the precision ?

Thank you.

Using the lcc-win compiler I obtain this:
d:\lcc\mc77\test>type tscanf.c
#include <qfloat.h>
#include <stdio.h>
int main(void)
{
qfloat qf;
scanf("%qf",&qf);
printf("%110.100qg\n",qf);
}

d:\lcc\mc77\test>lc -O tscanf.c

d:\lcc\mc77\test>dir tscanf.exe
Volume in drive D is Disque_d
Volume Serial Number is F681-0052

Directory of d:\lcc\mc77\test

06/04/2009 10:15 AM 127,285 tscanf.exe
1 File(s) 127,285 bytes
0 Dir(s) 29,381,287,936 bytes free

d:\lcc\mc77\test>tscanf
0.1234567898887765654433213132456787654323455678987654345677655443334565654335456445666

+0.1234567898887765654433213132456787654323455678987654345677655443334565654335456445666
00000000000000000000

105 digits precision in the standard distributrion

 

[Keith Thompson]

Can someone help me please ?
for example, when I read floating point from file (ascii)

0.123456789012345678901234567890 [...]
then the result is 0.1234567890123456773XXXXX <- X is different from
written file.

Can I extend the precision ?

Using the lcc-win compiler I obtain this:
d:\lcc\mc77\test>type tscanf.c
#include <qfloat.h>
#include <stdio.h>
int main(void)
{
qfloat qf;
scanf("%qf",&qf);
printf("%110.100qg\n",qf);
} [...]
105 digits precision in the standard distributrion

A very useful extension, I'm sure, but the OP should be aware that
it's specific to lcc-win.

If you want greater precision than provided by long double without
tying yourself to a single compiler, there are a number of possible
solutions, including the GNU GMP package.

 

[Richard Bos]

Using the lcc-win compiler I obtain this:

#include <qfloat.h>

Yeah, but that's not C. The OP's question was about C.

Richard

 

[jacob navia]

Yeah, but that's not C. The OP's question was about C.

Richard

The #include directive is surely java, yes. Or...
wait it must be lisp of course.

You, and the others here around have nothing to say, nothing
to object but the old stupid remarks.

"It's not C".

Bullshit.

 

[Phil Carmody]

[SNIP - whatever]

Consults killfile....

("jacob navia <[email protected]>" -1000 nil s)

He morphs...

He dies...

Phil

 

[Dik T. Winter]

> >> Can someone help me please ?
> >> for example, when I read floating point from file (ascii)
> >>
> >> 0.123456789012345678901234567890 > [...]
> >> then the result is 0.1234567890123456773XXXXX <- X is different from
> >> written file.
> >>
> >> Can I extend the precision ?

> >
> > Using the lcc-win compiler I obtain this:
> > d:\lcc\mc77\test>type tscanf.c
> > #include <qfloat.h>
> > #include <stdio.h>
> > int main(void)
> > {
> > qfloat qf;
> > scanf("%qf",&qf);
> > printf("%110.100qg\n",qf);
> > } > [...]
> > 105 digits precision in the standard distributrion

>
> A very useful extension, I'm sure, but the OP should be aware that
> it's specific to lcc-win.

I do not even now whether the OP does want what jacob provided, because to
me it is not clear what the OP actually wants.

> If you want greater precision than provided by long double without
> tying yourself to a single compiler, there are a number of possible
> solutions, including the GNU GMP package.

But does he really want more precision, or does he want decimal
floating-point, where what you read is represented exactly within the
program? There are possibly packages for that available, and I do think
that GMP also provides it using the rational number parts of GMP.

 

[jacob navia]

[SNIP - whatever]

Consults killfile....

("jacob navia <[email protected]>" -1000 nil s)

He morphs...

He dies...

Phil

This is a good example of the morons here:

No content, just polemic, unable to argument or to say
anything coherent, they can only mumble something.

 

[user923005]

[SNIP - whatever]

Consults killfile....

  ("jacob navia <[email protected]>" -1000 nil s)

He morphs...

He dies...

Phil

This is a good example of the morons here:

No content, just polemic, unable to argument or to say
anything coherent, they can only mumble something.

To which "this" does the pronoun relate?

 

[Richard Bos]

The #include directive is surely java, yes. Or...
wait it must be lisp of course.

Nope. It's a proprietary extension _to_ C. IOW, it's more or less as

You, and the others here around have nothing to say, nothing
to object but the old stupid remarks.

I didn't _have_ to provide a solution; Keith and Gordon already had, six
hours before you came along with your advertisement.

Richard

 

[jacob navia]

Can someone help me please ?
for example, when I read floating point from file (ascii)

0.123456789012345678901234567890 [...]
then the result is 0.1234567890123456773XXXXX <- X is different from
written file.

Can I extend the precision ?

Using the lcc-win compiler I obtain this:
d:\lcc\mc77\test>type tscanf.c
#include <qfloat.h>
#include <stdio.h>
int main(void)
{
qfloat qf;
scanf("%qf",&qf);
printf("%110.100qg\n",qf);
} [...]
105 digits precision in the standard distributrion

A very useful extension, I'm sure, but the OP should be aware that
it's specific to lcc-win.

If you want greater precision than provided by long double without
tying yourself to a single compiler, there are a number of possible
solutions, including the GNU GMP package.

The GNU MP package is very difficult to install for native windows,
and requires certainly a good expertise of cygwin/mingw configure
and all the associated stuff. The associated files are around 100MB
or more.

Of course this confirms GNU:
GNU is Not Usable



.... at least under windows

 

[jacob navia]

Joon Kim wrote:
Can someone help me please ?
for example, when I read floating point from file (ascii)

0.123456789012345678901234567890 [...]
then the result is 0.1234567890123456773XXXXX <- X is different from
written file.

Can I extend the precision ?

Using the lcc-win compiler I obtain this:
d:\lcc\mc77\test>type tscanf.c
#include <qfloat.h>
#include <stdio.h>
int main(void)
{
qfloat qf;
scanf("%qf",&qf);
printf("%110.100qg\n",qf);
} [...]
105 digits precision in the standard distributrion

A very useful extension, I'm sure, but the OP should be aware that
it's specific to lcc-win.

I do not even now whether the OP does want what jacob provided, because to
me it is not clear what the OP actually wants.

If you want greater precision than provided by long double without
tying yourself to a single compiler, there are a number of possible
solutions, including the GNU GMP package.

But does he really want more precision, or does he want decimal
floating-point, where what you read is represented exactly within the
program? There are possibly packages for that available, and I do think
that GMP also provides it using the rational number parts of GMP.

The original poster said:

> Can I extend the precision ?

> Thank you.

How can you say "It is unclear what he wants" ???

 

[squeamz]

[SNIP - whatever]

Consults killfile....

  ("jacob navia <[email protected]>" -1000 nil s)

He morphs...

He dies...

You masturbate a lot, don't you?

 

[jacob navia]

Nope. It's a proprietary extension _to_ C. IOW, it's more or less as
relevant to a general solution as #include <windows.h>.

The C standard specifies in Appendix J "Common extensions"
J.5.6:

<quote>
Additional floating types may have more range or precision than long
double, may be used for evaluating expressions of other floating types,
and may be used to define float_t or double_t.
<end quote>

Got it?

Before answering nonsense, read the standard FIRST!

 

[Beej Jorgensen]

The GNU MP package is very difficult to install for native windows,
[snip]
GNU is Not Usable

Heh!

I've only ever used GNU MP for fun (little crypto learning programs),
but I have to say my experience with it was pretty painless (under
Linux, though, not Windows.)

Windows is proprietary, so it wouldn't surprise me in the least if it
gets some backhanded treatment from the FSF...

-Beej

PS. Nothing in this post should be construed as taking sides for or
against Windows, Linux, GNU, FSF, GNU MP, or wombats. It is, however, a
pro-crypto post.

 

[Keith Thompson]

The C standard specifies in Appendix J "Common extensions"
J.5.6:

<quote>
Additional floating types may have more range or precision than long
double, may be used for evaluating expressions of other floating types,
and may be used to define float_t or double_t.
<end quote>

Got it?

Before answering nonsense, read the standard FIRST!

Section J.5 also talks about writable string literals, "asm" and
"fortran" as keywords, and predefined macro names not starting with an
underscore most of which can break strictly conforming code.

We all know qfloat is an extension. Richard's statement that it's
"not C" is, in my opinion, a bit of an exaggeration, but nothing worse
than that. The important point is that it's not portable or standard
C, something that the OP might not have inferred from your followup.

jacob, go back to your article, and imagine it being read by someone
who doesn't know that qfloat is non-standard. You mentioned that it
works with lcc-win, but not that it doesn't work with compilers other
than lcc-win. The fact that you used lcc-win could easily have been
just an added detail rather than

Later, you scoffed that GMP is difficult to use under Windows. How
difficult is qfloat to use on any system other than Windows?

I'm 99% certain that this will fall on deaf ears, but *try* to be a
little less paranoid. Not every criticism is a personal attack.

 

[Keith Thompson]

jacob, go back to your article, and imagine it being read by someone
who doesn't know that qfloat is non-standard. You mentioned that it
works with lcc-win, but not that it doesn't work with compilers other
than lcc-win. The fact that you used lcc-win could easily have been
just an added detail rather than

.... a critical piece of information. (I meant to finish that sentence
before posting.)

[...]

 

[Dik T. Winter]

> Dik T. Winter wrote: ....
>
> The original poster said:
> How can you say "It is unclear what he wants" ???

It is unclear because my impression (with the example he gave) was that he
did not understand that the internal workings of floating-point are in
binary. He specified as an example a 30 decimal digits floating-point
number. He did *not* specify that that was something like the maximum he
would wish. He also did not specify why he was bothered by the differences.
Did he want to do arithmetic with those numbers? I presume so, otherwise
reading them as a string and printing them as such would be sufficient.

Even your qfloat can not guarantee that with a 30 digit decimal number that
has been read in, (a * a) / a == a.

 

[jacob navia]

The GNU MP package is very difficult to install for native windows,
[snip]
GNU is Not Usable

Heh!

I've only ever used GNU MP for fun (little crypto learning programs),
but I have to say my experience with it was pretty painless (under
Linux, though, not Windows.)

Windows is proprietary, so it wouldn't surprise me in the least if it
gets some backhanded treatment from the FSF...

That is what I was saying: windows support is non existing