Rounding double

[md]

Hi

Does any body know, how to round a double value with a specific number
of digits after the decimal points?

A function like this:

RoundMyDouble (double &value, short numberOfPrecisions)

It then updates the value with numberOfPrecisions after the decimal
point.

Any help is appreciated.

Thanks.
md

[Richard Heathfield]

jacob navia said:

<snip>

Nowhere did the OP say that he wanted 100% accuracy!

The OP said (and I'm quoting this for the *third* time): "Does any body
know, how to round a double value with a specific number of digits after
the decimal points?"

Thus, rounding 0.33 to one decimal place should result in a result with
*one* decimal place, not a couple of dozen decimal places.

>
Now that Mr Heathfield sees that his position is completely untenable,

On the contrary, I maintain that my position is not only tenable but the
best position to take on the available evidence.

he starts modifying the original question, putting more words into the
OP than what he actually said.

On the contrary, I have stuck to the original question, and have not read
into it the same unstated assumptions that some others (including you)
have been making.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Philip Potter]

Richard Heathfield wrote:

Philip Potter said:

>Richard Heathfield wrote:

>>jacob navia said:

Since you provide no information on which compilation options
you used, no information on which system you are running, this
can't be solved really.
The compilation options shouldn't matter, but I'll tell you anyway:

No, they *do* matter. gcc is not a conforming C89, C95 or C99
implementation with no compilation options. With -ansi -pedantic, it's
quite a good C89 compiler. With -std=c99 -pedantic, it's a half-finished
C99 compiler.

I'm sure you know this already.

Yes, it's a fair point. Okay, if I invoke gcc in conforming mode, the code
doesn't compile at all, for a number of reasons. (Clearly, to invoke gcc
in conforming mode means we have to go for C89 or, if you prefer, C90
conformance, since gcc doesn't have a C99 conforming mode.)

So you take a C99 program (for I assume that is what it is since it uses
long long) and compile it with a C89 compiler, and complain when it
doesn't work?

Surely you know better than that?

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

<snip>

>Yes, it's a fair point. Okay, if I invoke gcc in conforming mode, the
code doesn't compile at all, for a number of reasons. (Clearly, to
invoke gcc in conforming mode means we have to go for C89 or, if you
prefer, C90 conformance, since gcc doesn't have a C99 conforming mode.)

Can you stop all this theater?

By "theater", presumably you mean my legitimate objections that the code
doesn't work on my system.

>
Now compile with
gcc -std=c99 jn.c -lm

Okay.

and tell me the results ok?

Okay.

cc1: unknown C standard `c99'

So - do you have a *portable* solution or don't you?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Philip Potter said:

<snip>

So you take a C99 program (for I assume that is what it is since it uses
long long) and compile it with a C89 compiler, and complain when it
doesn't work?

I don't have a C99 compiler. Neither, I would venture to suggest, do you.
If the code requires C99 conformance, that in itself is sufficient to
render the code almost valueless (quite apart from the fact that it
doesn't solve the problem that the OP posed), since almost nobody has a
conforming C99 compiler.

Surely you know better than that?

Almost nobody has a conforming C99 compiler. It is a very good bet indeed
that the OP does not have a conforming C99 compiler. It is therefore very
poor form indeed to post code that relies on C99 features as a proposed
solution to the OP's problem.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

Richard Heathfield wrote:

>
But rounding is an operation that yields an exact result. 0.33, rounded to
one decimal place, is *precisely* 0.3, not 0.299999999999998 or
0.300000000000001 (no, I didn't count the 9s and 0s - I just held the key
down!). If the result is not exact, it isn't a rounding. It's merely an
approximation to a rounding.

>because of the nature of
floating point, but will be billions of times more accurate than
doing no rounding because 'it can't be done'.

Oh, it can be done all right - it's just that it can't be done using
floating point. More precisely, you can't store 0.33 rounded to one
decimal place in a floating point number (unless you use a radix that
makes it possible, in which case there are other numbers you can't store).

We all know that Heathfield. O.3 is not representable,
so what?

We use the best approximation to it!

Pi is not representable nor "e" (the base of natural logarithms).

So WHAT?

We use the best approximation.

0.1 is not representable. SO WHAT?
We use the best approximation.

AND SO ON.

You go on and on repeating the same thing:

"Floating point numbers are an approximation, not the true result".

We all know that. That doesn't mean that approximations to the true
result are impossible, and that we can't give the OP an approximation
to the true result!

>

>If I have a measurement X somewhere along a 1m stick (0.0 to 1.0) and
I want to find the nearest 10cm mark to X (eg X is 0.78, the nearest
will be 0.8), then it's clear than I can round 0.78 to 1 decimal (or
1/10) to get 0.8.

Right.

>The result, being stored in floating point binary,
may be out by a billionth of a micron or so. So what? My pencil mark
on the stick will not be that accurate.

Indeed, but the result will still be out.

That is floating point! It is intrinsic to the nature of floating
point, and all your argumentation is just a boring remake
of the "floating point is always an approximation" mantra.

>The point is such a rounding can be done and has a useful purpose.

Yes, it can, but only by adopting a different representation. A double
simply can't cut it.

A double can have a precision of e-14 or e-15.
This allows to give the radius of the earth to a precision of a few
nanometers!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

>>
But rounding is an operation that yields an exact result. 0.33, rounded
to one decimal place, is *precisely* 0.3, not 0.299999999999998 or
0.300000000000001 (no, I didn't count the 9s and 0s - I just held the
key down!). If the result is not exact, it isn't a rounding. It's merely
an approximation to a rounding.

>>because of the nature of
floating point, but will be billions of times more accurate than
doing no rounding because 'it can't be done'.

Oh, it can be done all right - it's just that it can't be done using
floating point. More precisely, you can't store 0.33 rounded to one
decimal place in a floating point number (unless you use a radix that
makes it possible, in which case there are other numbers you can't
store).

We all know that Heathfield. O.3 is not representable,
so what?

So the original problem is insoluble, and another approach must be found,
such as the approach I suggested in my very first reply. Pretending that
0.3 *is* representable in a double (without switching to a radix that
makes other numbers unrepresentable) is silly.

<snip>

>>The result, being stored in floating point binary,
may be out by a billionth of a micron or so. So what? My pencil mark
on the stick will not be that accurate.

Indeed, but the result will still be out.

That is floating point! It is intrinsic to the nature of floating
point,

Quite so. This is indeed the whole point.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

Richard Heathfield wrote:

>
If the OP is happy to take 0.2999999999999999999999998 as the result of
rounding 0.33 to one decimal place, that's fine - but he has not (yet)
said so.

Look that result is
-0.0000000000000000000000002 or 2e-25 different from the true
result. At this precision you can measure the radius of the earth
to the radius of an electron or more!

Floating point is floating point, we all know that Heathfield.
But the correct answer for this questions is surely a function
similar to the one I am proposing.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Marco Manfredini]

jacob navia wrote:

In general, 100% exact results using floating point are impossible,
as you know very well.

In general 100% exact results using floating point are possible,
provided you do not perform operations which return inexact results.
1.0 + 1.0 has an exact representation, and so has 1234.75 and you may
even "round" a partial result or parameter (i.e. declare it exact) and
design your computation that no inexact results are created. This is
useful if you need a reliable error estimate on you result. IEEE 754
even allows you to arm a trap if an inexact result occurs during a
computation.

--
IYesNo yes=YesNoFactory.getFactoryInstance().YES;
yes.getDescription().equals(array[0].toUpperCase());

[jacob navia]

Richard Heathfield wrote:

Philip Potter said:

<snip>

>So you take a C99 program (for I assume that is what it is since it uses
long long) and compile it with a C89 compiler, and complain when it
doesn't work?

I don't have a C99 compiler.

Then you can't compile C code according to the standard.
That's bad for you, specially since a better version of gcc
would compile this code without any problems.

Neither, I would venture to suggest, do you.
If the code requires C99 conformance, that in itself is sufficient to
render the code almost valueless (quite apart from the fact that it
doesn't solve the problem that the OP posed), since almost nobody has a
conforming C99 compiler.

gcc conforms very well, IBM's compiler also, and many other compilers
like Comeau, and Intel. Other compiler like lcc-win are advanced
in their complicance. You just hate any progress in C and want to
come back more than 15 years back to the times of C89!

>Surely you know better than that?

Almost nobody has a conforming C99 compiler.

This is not true and you know it.

It is a very good bet indeed
that the OP does not have a conforming C99 compiler. It is therefore very
poor form indeed to post code that relies on C99 features as a proposed
solution to the OP's problem.

C99 is the current standard, and I hate this people that always have
in their mouths "Standard C" and then do not mean with that the
standard as accepted by the standards body!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Marco Manfredini wrote:

jacob navia wrote:

>In general, 100% exact results using floating point are impossible,
as you know very well.

In general 100% exact results using floating point are possible,
provided you do not perform operations which return inexact results.

Yeah. Division for instance!

1.0 + 1.0 has an exact representation, and so has 1234.75 and you may
even "round" a partial result or parameter (i.e. declare it exact) and
design your computation that no inexact results are created. This is
useful if you need a reliable error estimate on you result. IEEE 754
even allows you to arm a trap if an inexact result occurs during a
computation.

Have you ever tried to trap on "inexact"?

You can't do any square roots, or any mathematical work!

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[James Kuyper]

Richard Heathfield wrote:

Philip Potter said:

<snip>

>So you take a C99 program (for I assume that is what it is since it uses
long long) and compile it with a C89 compiler, and complain when it
doesn't work?

I don't have a C99 compiler. Neither, I would venture to suggest, do you.
If the code requires C99 conformance, that in itself is sufficient to
render the code almost valueless (quite apart from the fact that it
doesn't solve the problem that the OP posed), since almost nobody has a
conforming C99 compiler.

If the only features of C99 that it uses are features that are widely
supported by compilers in their C99 modes, then the fact that those
modes are not fully conforming is not sufficient to render the code
valueless.

[jacob navia]

James Kuyper wrote:

Richard Heathfield wrote:

>Philip Potter said:

<snip>

>>So you take a C99 program (for I assume that is what it is since it uses
long long) and compile it with a C89 compiler, and complain when it
doesn't work?

I don't have a C99 compiler. Neither, I would venture to suggest, do
you. If the code requires C99 conformance, that in itself is
sufficient to render the code almost valueless (quite apart from the
fact that it doesn't solve the problem that the OP posed), since
almost nobody has a conforming C99 compiler.

If the only features of C99 that it uses are features that are widely
supported by compilers in their C99 modes, then the fact that those
modes are not fully conforming is not sufficient to render the code
valueless.

C99 *IS* the standard as defined by ISO/ANSI. If we say that this group
discussed "standard c" as repeated by this "regulars" over and over
let's stay within STANDARD C!

I have been working like 10 years in the implementation of a C99
compliant compiler and I think it is time to use that!

And if it doesn't run with Mr Heathfield machine/system/compiler I do
not care.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[James Kuyper]

Richard Heathfield wrote:

James Kuyper said:

....

>However, you cannot justify
assuming that he had that misconception just because he failed to
specify that he wanted the best available floating point approximation
to the rounded number.

On the other hand, answering *all* the questions people *don't* ask would
take infinite time. We're not mind readers.

No, but we should be able to read ordinary English (and technical
English) and interpret it in conventional fashion as implying, as it
normally does, a great many unstated assumptions. Stating all applicable
assumptions would also take infinite time. Even explicitly stating only
the most important assumptions that are conventionally left unstated
would make the questions unreadable.

[Marco Manfredini]

jacob navia wrote:

Marco Manfredini wrote:

>jacob navia wrote:

>>In general, 100% exact results using floating point are impossible,
as you know very well.

In general 100% exact results using floating point are possible,
provided you do not perform operations which return inexact results.

Yeah. Division for instance!

Most signal processing algorithms are designed to work without divisions
for instance. Division by 2 occurs, but this is also exact unless you
lose the lsb in de-normalization.

>

>1.0 + 1.0 has an exact representation, and so has 1234.75 and you may
even "round" a partial result or parameter (i.e. declare it exact)
and design your computation that no inexact results are created. This
is useful if you need a reliable error estimate on you result. IEEE
754 even allows you to arm a trap if an inexact result occurs during
a computation.

Have you ever tried to trap on "inexact"?

You can't do any square roots, or any mathematical work!

And you didn't understand the argument. You can prepare a computation by
isolating the inexact part, estimate the error and continue with the
exact part, guarded by the trap. At the end you can prove that your
result is exact to 10^-9, which is much better than "looks plausible to
me if I printf it, I think"

--
IYesNo yes=YesNoFactory.getFactoryInstance().YES;
yes.getDescription().equals(array[0].toUpperCase());

[jacob navia]

jacob navia wrote:

I have been working like 10 years in the implementation of a C99
compliant compiler and I think it is time to use that!

Replace 10 by "many"...

Incredible the kind of nonsense I say when I get angry.

Excuse me.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[vippstar]

On Nov 23, 3:36 pm, jacob navia <[e-mail]:

jacob navia wrote:

I have been working like 10 years in the implementation of a C99
compliant compiler and I think it is time to use that!

Replace 10 by "many"...

Incredible the kind of nonsense I say when I get angry.

The trick is not to improve your wording when angry, but to avoid
getting angry.

I believe no more posts need to be done, for it will lead to more
inaccuracies and 'flame wars' from Mr Heathfield, Mr Navia or some
other regular.
I find it rather amusing that c.l.c regulars have been arguing for
something so trivial in nature for 150 posts now.

[Flash Gordon]

jacob navia wrote, On 23/11/07 11:34:

Kai-Uwe Bux wrote:

>Richard Heathfield wrote:

>>jacob navia said:

<snip>

2: As you can see, my solution works in your machine. Either RH is not
telling the truth (unlikely) or he is using some minor error in the
code to trip about.
If your code has an error, however minor, then it is broken, in which
case
I suggest you post a fixed version. The version you posted *does not
work*
on my system. Quite apart from the fact that you are trying to solve an
impossible problem (the problem, remember, is that of rounding the
value of a double to a specified number of decimal places, which
simply can't be
done), you are trying to solve it in a way that produces bizarrely
incorrect results on at least one system.

Hm. I wonder if this might be a matter of interpreting the problem.

The C standard says about sqrt() that it computed the nonnegative square
root. C++ inherits this requirement. If your interpretation of the
rounding
problem is correct and if we transfer it to the other arithmetic
operations, then there can be no conforming implementations. In fact,
even
elementary school arithmetic (+,-,*,/) cannot be done correctly under
that
interpretation. However, that interpretation of the specs is not the only
possible.

Actually, there can be *lots* of conforming implementations if N1256 is
to be believed, since section 5.2.4.2.2 paragraph 5 says:
| The accuracy of the floating-point operations (+, -, *, /) and of the
| library functions in <math.hand <complex.hthat return
| floating-point results is implementation-de�ned, as is the accuracy of
| the conversion between floating-point internal representations and
| string representations performed by the library functions in
| <stdio.h>, <stdlib.h>, and <wchar.h>. The implementation may state
| that the accuracy is unknown.

So it is explicitly allowed to be less than 100% accurate.

I am arguing precisely this since the beginning of this thread.
All trascendental functions, sqrt, pow, whatever. All of them yield
approximations of their real results.

Yes, and the specification allows for this, the OPs specification on the
other hand does not.

The solution I proposed is surely not the best one but it is a first
try after a summary discussion here.

It also does not meet the stated requirements. That the requirements are
impossible means you need to explain why they are impossible (and this
has been explained) not provide code that fails to meet the requirements
without stating this.

>A different interpretation of floating point computations is that an
operation (say multiplication, addition, sqrt, or rounding to a given
number of decimal places) should yield a double (or float or whatever
types
are topical in the corresponding newsgroup) that is closest to the exact
mathematical result. If I recall correctly, this is by and large the
position taken by IEEE754.

EXACTLY.

It is not the position taken by the C standard, which just required that
the accuracy be defined by the implementation.

>When this (reasonable) interpretation is adopted, the problem of
rounding to
a fixed number of decimals is solvable (and it is indeed not different
from
any other computational problem). And if you don't adopt an
interpretation
like that, floating point arithmetic in general is "impossible".

This is exactly my position.

It fails to allow for the empirical evidence that most people asking for
things like this are not aware that they are not possible, so they need
to have this explained so they can work out how to deal with the problem.

As I pointed out else-thread, the OP might be adding up millions of such
numbers and be required to produce a final result within a given
accuracy and your method would not guarantee this.
--
Flash Gordon

[Philip Potter]

Richard Heathfield wrote:

Philip Potter said:

<snip>

>So you take a C99 program (for I assume that is what it is since it uses
long long) and compile it with a C89 compiler, and complain when it
doesn't work?

I don't have a C99 compiler. Neither, I would venture to suggest, do you.

So? If you don't have a C compiler, you don't try a FORTRAN compiler
instead to see if it works.

If the code requires C99 conformance, that in itself is sufficient to
render the code almost valueless (quite apart from the fact that it
doesn't solve the problem that the OP posed), since almost nobody has a
conforming C99 compiler.

I know you dislike many features of C99 and also like to talk about the
lack of uptake of C99; however that is not a valid reason to compile
code which uses "long long" under C89 and complain that it doesn't work.
Of course it doesn't work, it's not C89 code!

>Surely you know better than that?

Almost nobody has a conforming C99 compiler. It is a very good bet indeed
that the OP does not have a conforming C99 compiler. It is therefore very
poor form indeed to post code that relies on C99 features as a proposed
solution to the OP's problem.

If that is your problem with Jacob's program then say so. The fact that
Jacob's code is broken in C89 might be something you personally dislike,
but if it works in C99 it is perfectly topical regardless of the number
of working C99 distributions in existence.

[jacob navia]

vi******@gmail.com wrote:

On Nov 23, 3:36 pm, jacob navia <[e-mail]:

>jacob navia wrote:

>>I have been working like 10 years in the implementation of a C99
compliant compiler and I think it is time to use that!

Replace 10 by "many"...

Incredible the kind of nonsense I say when I get angry.

The trick is not to improve your wording when angry, but to avoid
getting angry.

I believe no more posts need to be done, for it will lead to more
inaccuracies and 'flame wars' from Mr Heathfield, Mr Navia or some
other regular.
I find it rather amusing that c.l.c regulars have been arguing for
something so trivial in nature for 150 posts now.

That is easy to say but...

What is YOUR opinion in this matter?

(Hereby I promise not to start any flame war with your
answer )
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Bart]

On Nov 23, 12:41 pm, Richard Heathfield <[e-mail]:

Bart said:

Of course the result will be approximate

But rounding is an operation that yields an exact result. 0.33, rounded to
one decimal place, is *precisely* 0.3, not 0.299999999999998 or
0.300000000000001 (no, I didn't count the 9s and 0s - I just held the key
down!). If the result is not exact, it isn't a rounding. It's merely an
approximation to a rounding.

Maybe the problem is the precise meaning of 'rounding'. Call it
nearest to 1/1000 or whatever and then the inaccuracies can be
tolerated.

Otherwise there would doubt cast over the whole world of floating
point arithmetic.

>

The point is such a rounding can be done and has a useful purpose.

Yes, it can, but only by adopting a different representation. A double
simply can't cut it.

Example: I have values 0.156 and 0.456. The sum is 0.612.

Printing out using 2 decimals, the user will see: 0.16 + 0.46 = 0.61!
By simply rounding to 2 decimals, and then calculating with 0.16 and
0.46, the result 0.62 will now make sense.

This calculation can be done with doubles and will work within wide
limits. You would need a lot of additions for the inaccuracy to have
an effect.
BTW I am on Jacob's side on this. He seems a practically minded chap
(like me). Perhaps instead of bullying, his solution can be refined
until it's acceptable.

His code (one version) I think wouldn't work with negative values (an
fabs() and a sign() is needed somewhere). It also seems to rely on an
integer intermediate value which would overflow sometimes; an fint()
is needed in there. (Sorry don't know the C equivalents: fint(x) would
convert 31.459 to 31.000)

Bart

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

>>
If the OP is happy to take 0.2999999999999999999999998 as the result of
rounding 0.33 to one decimal place, that's fine - but he has not (yet)
said so.

Look that result is
-0.0000000000000000000000002 or 2e-25 different from the true
result.

I'm well aware of this. Nevertheless, it does not match the OP's stated
objective.

At this precision you can measure the radius of the earth
to the radius of an electron or more!

This is not relevant. It is certainly true that we can get very, very close
to 0.3, and nobody is disputing that.

Floating point is floating point, we all know that Heathfield.
But the correct answer for this questions is surely a function
similar to the one I am proposing.

The correct answer was given very early on in the thread.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

>Philip Potter said:

<snip>

>>So you take a C99 program (for I assume that is what it is since it
uses long long) and compile it with a C89 compiler, and complain when
it doesn't work?

I don't have a C99 compiler.

Then you can't compile C code according to the standard.

Do you have a compiler that conforms to C99? If not, then neither can you.

<snip>

>Almost nobody has a conforming C99 compiler.

This is not true and you know it.

If I knew it not to be true, I would not have said it. I certainly believe
it to be true.

<snip>

C99 is the current standard,

It's the current de jure standard, yes - but C90 is still the de facto
standard.

and I hate this people that always have
in their mouths "Standard C" and then do not mean with that the
standard as accepted by the standards body!

If you can come up with a working C99 solution, fine - at least it'll work
for those very few people who have C99-conforming compilers. But you have
not yet done so. (I'm not talking about the bizarre results on my
platform. I'm talking about the results that you claim are "close enough",
but which do not meet the OP's requirement.)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

James Kuyper said:

Richard Heathfield wrote:

>Philip Potter said:

<snip>

>>So you take a C99 program (for I assume that is what it is since it
uses long long) and compile it with a C89 compiler, and complain when
it doesn't work?

I don't have a C99 compiler. Neither, I would venture to suggest, do
you. If the code requires C99 conformance, that in itself is sufficient
to render the code almost valueless (quite apart from the fact that it
doesn't solve the problem that the OP posed), since almost nobody has a
conforming C99 compiler.

If the only features of C99 that it uses are features that are widely
supported by compilers in their C99 modes, then the fact that those
modes are not fully conforming is not sufficient to render the code
valueless.

Indeed. That's why I said "almost valueless". :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

James Kuyper said:

Richard Heathfield wrote:

>James Kuyper said:

...

>>However, you cannot justify
assuming that he had that misconception just because he failed to
specify that he wanted the best available floating point approximation
to the rounded number.

On the other hand, answering *all* the questions people *don't* ask
would take infinite time. We're not mind readers.

No, but we should be able to read ordinary English (and technical
English) and interpret it in conventional fashion as implying, as it
normally does, a great many unstated assumptions. Stating all applicable
assumptions would also take infinite time. Even explicitly stating only
the most important assumptions that are conventionally left unstated
would make the questions unreadable.

Then we are at the stage where the OP needs to clarify his requirements,
because it seems to me that the conventional interpretation that I and
some others here have used is diametrically opposite to your conventional
interpretation (or at least the conventional interpretation that you are
defending).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Philip Potter said:

Richard Heathfield wrote:

>Philip Potter said:

<snip>

>>So you take a C99 program (for I assume that is what it is since it
uses long long) and compile it with a C89 compiler, and complain when
it doesn't work?

I don't have a C99 compiler. Neither, I would venture to suggest, do
you.

So? If you don't have a C compiler, you don't try a FORTRAN compiler
instead to see if it works.

Right. But you might try gcc in non-conforming mode, and that is what I
(and several other people in this thread) have done.

>

>If the code requires C99 conformance, that in itself is sufficient to
render the code almost valueless (quite apart from the fact that it
doesn't solve the problem that the OP posed), since almost nobody has a
conforming C99 compiler.

I know you dislike many features of C99 and also like to talk about the
lack of uptake of C99; however that is not a valid reason to compile
code which uses "long long" under C89 and complain that it doesn't work.
Of course it doesn't work, it's not C89 code!

Like others here, I used gcc in non-conforming mode in an effort to compile
the code. Anyone who claims he used gcc in *conforming* mode is mistaken,
since the code requires C99 features that are not available in any
conforming gcc mode. This is because gcc does not have a mode that
conforms to C99.

>>Surely you know better than that?

Almost nobody has a conforming C99 compiler. It is a very good bet
indeed that the OP does not have a conforming C99 compiler. It is
therefore very poor form indeed to post code that relies on C99 features
as a proposed solution to the OP's problem.

If that is your problem with Jacob's program then say so.

No, that's a side issue. The principal problem with the program is that it
does not solve the OP's problem.

The fact that
Jacob's code is broken in C89 might be something you personally dislike,
but if it works in C99 it is perfectly topical regardless of the number
of working C99 distributions in existence.

I can certainly agree with that. I have not said, and do not claim, that
the code is off-topic.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

Richard Heathfield wrote:

Philip Potter said:

>Richard Heathfield wrote:

>>Philip Potter said:

<snip>

So you take a C99 program (for I assume that is what it is since it
uses long long) and compile it with a C89 compiler, and complain when
it doesn't work?
I don't have a C99 compiler. Neither, I would venture to suggest, do
you.

So? If you don't have a C compiler, you don't try a FORTRAN compiler
instead to see if it works.

Right. But you might try gcc in non-conforming mode, and that is what I
(and several other people in this thread) have done.

And that of course doesn't work. And instead of saying

>>I do not have a c99 compiler and I do not want to have one<<

you say:

"Jacob's code doesn't work and I get nonsense results"

Very honest.

Like others here, I used gcc in non-conforming mode in an effort to compile
the code. Anyone who claims he used gcc in *conforming* mode is mistaken,
since the code requires C99 features that are not available in any
conforming gcc mode. This is because gcc does not have a mode that
conforms to C99.

and gcc -std=c99 is wrong or what?

>The fact that
Jacob's code is broken in C89 might be something you personally dislike,
but if it works in C99 it is perfectly topical regardless of the number
of working C99 distributions in existence.

I can certainly agree with that. I have not said, and do not claim, that
the code is off-topic.

You were claiming that it produced nonsense results. At the end we see
that you were deliberately misusing gcc.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

>Philip Potter said:

>>Richard Heathfield wrote:
Philip Potter said:

<snip>

So you take a C99 program (for I assume that is what it is since it
uses long long) and compile it with a C89 compiler, and complain when
it doesn't work?
I don't have a C99 compiler. Neither, I would venture to suggest, do
you.
So? If you don't have a C compiler, you don't try a FORTRAN compiler
instead to see if it works.

Right. But you might try gcc in non-conforming mode, and that is what I
(and several other people in this thread) have done.

And that of course doesn't work.

Right.

And instead of saying

>>I do not have a c99 compiler and I do not want to have one<<

I'd love one, actually. Do you have one?

you say:

"Jacob's code doesn't work and I get nonsense results"

Very honest.

But that *is* what I observed. I was using gcc extensions, which seems to
be what everyone else was doing too. And it is certainly true that the
code doesn't work, because it *doesn't do what was required*. The fact
that it gave weird results on my system isn't all that important, but I
was sufficiently puzzled to ask other people what results they were
getting.

>Like others here, I used gcc in non-conforming mode in an effort to
compile the code. Anyone who claims he used gcc in *conforming* mode is
mistaken, since the code requires C99 features that are not available in
any conforming gcc mode. This is because gcc does not have a mode that
conforms to C99.

and gcc -std=c99 is wrong or what?

No, it's not wrong - but it doesn't invoke a C99-conforming compiler.
Calling a switch "-std=c99" does not magically provide C99 conformance.

>>The fact that
Jacob's code is broken in C89 might be something you personally
dislike, but if it works in C99 it is perfectly topical regardless of
the number of working C99 distributions in existence.

I can certainly agree with that. I have not said, and do not claim, that
the code is off-topic.

You were claiming that it produced nonsense results.

On my system, it did.

At the end we see that you were deliberately misusing gcc.

If you can come up with a set of switches that makes the code work on the
gcc implementation currently installed on my system, I'm all ears.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

Richard Heathfield wrote:

If you can come up with a set of switches that makes the code work on the
gcc implementation currently installed on my system, I'm all ears.

What is that implementation?
It must be older than 2000!

The best thing would be for you to iunstall an up to date
version.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

>If you can come up with a set of switches that makes the code work on
the gcc implementation currently installed on my system, I'm all ears.

What is that implementation?

2.95.3

It must be older than 2000!

So? It still works just fine with properly written, portable code.

The best thing would be for you to iunstall an up to date
version.

Why? So that I can compile a misconceived non-solution to an insoluble
problem? I don't see the point.

When GNU finally get a conforming C99 implementation together, that'll be
worth an upgrade. Until then, I see no reason to break a working system.
(We have seen quite recently that there are versions of gcc later than
2.95.3 that incorporate exciting new bugs not present in the older version
- but I don't need that kind of excitement.)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bart]

On Nov 22, 5:39 am, md <[e-mail]:

Hi

Does any body know, how to round a double value with a specific number
of digits after the decimal points?

A function like this:

RoundMyDouble (double &value, short numberOfPrecisions)

It then updates the value with numberOfPrecisions after the decimal
point.

Any help is appreciated.

Thanks.
md

If you accept the fact that such a rounding will not be exact (the
error depending partly on the magnitude of the values), then code such
as the following (modified from Jacob Navia's code posted elsewhere)
might be of use:

#include <stdio.h>
#include <math.h>

void RoundMyDouble (long double *value, short numberOfPrecisions)

{
long long p = powl(10.0L, numberOfPrecisions);
*value = floor(*value * p + 0.5L) / (double)p;
}

int main(void) /* demo */
{
long double v = 3.1415926535897932384626L;
short int ndp = 0;
while(ndp < 20)
{
long double newv = v;
RoundMyDouble(&newv, ndp);
printf("%.21Lf, \"rounded\" to %hd decimals, is %.21Lf\n",
(v),
ndp++,
newv);
}

return 0;
}

With this code, rounding a value such as 5.288123 to 3 decimals (for
which you would expect 5.288) might actually produce 5.287999999... or
5.2880000000...044 or whatever. Whatever it is, it will be the best
approximation to 5.288. Printing this to a limited number of decimals
should display 5.288000... however)

(In fact reading "5.288" into a double you will run into the same
problem.

If accuracy is essential, and you are rounding to 4 decimals for
example, then multiply by 10000 and work with integers, or doubles
containing integral values.

Bart

[Mark McIntyre]

jacob navia wrote:

Mark McIntyre wrote:

>jacob navia wrote:

>>This is perfectly OK since double has only 16 decimal digits,

This is incorrect. The ISO standard requires a double to have at least
10 digits, but specifies no upper bound.

5.2.4.2.2 Characteristics of floating types
8. The values given in the following list shall be replaced by
constant expressions with implementation-defined values that are
greater or equal in magnitude (absolute value) to those shown, with
the same sign:
FLT_DIG 6
DBL_DIG 10
LDBL_DIG 10

There are a couple of worked examples showing 15 digits, and one
footnote that references the ISO/IEC floating point standard, but
nothing else normative.

That "footnote" is Annex F, and it IS normative.

I don't disagree. Please read what I wrote more carefully.

You may also want to reread annex F, and note that the entire annex is
optional. Did you think that an annex would explicitly contradict an
earlier chapter, and nobody noticed before?

[Mark McIntyre]

Flash Gordon wrote:

Yes, there are *real* situations where you will get
complaints for an error of 1 penny in a result in the 10s of millions.

I gather you've worked with the Japanese central bank. :-)

[Mark McIntyre]

jacob navia wrote:

Mark McIntyre wrote:

>jacob navia wrote:

>>>Could someone else please share with us the result they get when
they drive this function with inputs of 0.33 and 1 ? I'm getting
some very, very strange results here.

>>d:\lcc\mc68\test>type tdouble3.c

I copy-pasted this exact code, and compiled under gcc 4.1.2:

thelinux clc_tests $ ./a.out 0.33
1374389535.0000000000000000000: 0 decimals 1374389535.0000000000000000
1374389535.0000000000000000000: 1 decimals 1374389535.0000000000000000

I'm giving this one a 'strange' score of 'high'

Yes, because stdlib.h is missing. You need it for the prototype of atof.

Oh, I see - its MY fault that you posted nonsense code, and claimed it
worked.
Perhaps you want to gang an bile yer heid, ye great plooter?

[Mark McIntyre]

Philip Potter wrote:

Richard Heathfield wrote:

>Thanks, Mark, for doing that. I used the exact same code, except that
I read ahead in the thread and added <stdlib.h>

:-) I found it far more amusing to compile the precise code posted.

I'm disappointed with the misleading results here which suggest that the
LHS has trailing cruft which the RHS doesn't, when both have such cruft.

Quite - if you print 'em both to 19dp...

mark@thelinux clc_tests $ ./a.out 0.33
0.3300000000000000155: 0 decimals 0.0000000000000000000
0.3300000000000000155: 1 decimals 0.2999999999999999889
0.3300000000000000155: 2 decimals 0.3300000000000000155
0.3300000000000000155: 3 decimals 0.3300000000000000155

I especially like the second answer.

[jacob navia]

Mark McIntyre wrote:

jacob navia wrote:

>Mark McIntyre wrote:

>>jacob navia wrote:
Could someone else please share with us the result they get when
they drive this function with inputs of 0.33 and 1 ? I'm getting
some very, very strange results here.

d:\lcc\mc68\test>type tdouble3.c

I copy-pasted this exact code, and compiled under gcc 4.1.2:

thelinux clc_tests $ ./a.out 0.33
1374389535.0000000000000000000: 0 decimals 1374389535.0000000000000000
1374389535.0000000000000000000: 1 decimals 1374389535.0000000000000000

I'm giving this one a 'strange' score of 'high'

Yes, because stdlib.h is missing. You need it for the prototype of atof.

Oh, I see - its MY fault that you posted nonsense code, and claimed it
worked.
Perhaps you want to gang an bile yer heid, ye great plooter?

I got tired of #including math.h and finding out that atof
wasn't there but in stdlib.h. So I put it in math.h in lcc-win.
This is of course not the case with gcc, that has it in stdlib.

This minor flaw doesn't make all the code "nonsense" as you
say. Just keep calm
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Mark McIntyre]

jacob navia wrote:

(nothing of substance)

oh look. Another interminable thread in which Jacob insists he's right,
and everybody else, irrespective of pedigree, learning and training, is
wrong. Nobody but him knows how to invoke their compiler properly.
Nobody knows how floating point works. etc etc etc

What a boring person.

[Philip Potter]

jacob navia wrote:

Mark McIntyre wrote:

>Oh, I see - its MY fault that you posted nonsense code, and claimed it
worked.
Perhaps you want to gang an bile yer heid, ye great plooter?

I got tired of #including math.h and finding out that atof
wasn't there but in stdlib.h. So I put it in math.h in lcc-win.
This is of course not the case with gcc, that has it in stdlib.

This minor flaw doesn't make all the code "nonsense" as you
say. Just keep calm

Perhaps people would keep calmer if you didn't accuse them of "spreading
nonsense".

[Ian Collins]

jacob navia wrote:

>
I got tired of #including math.h and finding out that atof
wasn't there but in stdlib.h. So I put it in math.h in lcc-win.
This is of course not the case with gcc, that has it in stdlib.

Which is where it belongs, it isn't a math function, it is a string
conversion function.

--
Ian Collins.

[Gordon Burditt]

>pgp@medusa-s2:~/tmp$ gcc -std=c99 -pedantic -W -Wall -lm jn.c -ojn

>jn.c:16: warning: unused parameter 'argc'
pgp@medusa-s2:~/tmp$ ./jn 0.33
0.3300000000000000155: 0 decimals 0.0000000000000000
0.3300000000000000155: 1 decimals 0.3000000000000000
0.3300000000000000155: 2 decimals 0.3300000000000000
0.3300000000000000155: 3 decimals 0.3300000000000000
0.3300000000000000155: 4 decimals 0.3300000000000000
0.3300000000000000155: 5 decimals 0.3300000000000000
0.3300000000000000155: 6 decimals 0.3300000000000000
0.3300000000000000155: 7 decimals 0.3300000000000000
0.3300000000000000155: 8 decimals 0.3300000000000000
0.3300000000000000155: 9 decimals 0.3300000000000000
0.3300000000000000155: 10 decimals 0.3300000000000000
0.3300000000000000155: 11 decimals 0.3300000000000000
0.3300000000000000155: 12 decimals 0.3300000000000000
0.3300000000000000155: 13 decimals 0.3300000000000000
0.3300000000000000155: 14 decimals 0.3300000000000000

I'm disappointed with the misleading results here which suggest that the
LHS has trailing cruft which the RHS doesn't, when both have such cruft.

None of the floating-point numbers printed here can be represented
exactly in binary floating point, except zero. For debugging
purposes, I recommend a better output format, say %300.200f ,
enough to ensure that you can have enough digits to exactly represent
the number you get as a result (this is quite a bit more than
FLT_DIG, DBL_DIG, or LDBL_DIG, as appropriate to the type being
used). Or perhaps someone is using base-10 floating point.

[Gordon Burditt]

>Nowhere did the OP say that he wanted 100% accuracy!

>
The OP said (and I'm quoting this for the *third* time): "Does any body
know, how to round a double value with a specific number of digits after
the decimal points?"

Thus, rounding 0.33 to one decimal place should result in a result with
*one* decimal place, not a couple of dozen decimal places.

In other words, to round to one decimal place to get a result with
*one* decimal place, you round to the nearest multiple of 0.5 . To
round to N decimal places, you round to the nearst multiple of
2.0**-N, where ** is an exponentiation operator.

Somehow I don't think this is what was meant.

[Gordon Burditt]

>Quite - if you print 'em both to 19dp...

>
mark@thelinux clc_tests $ ./a.out 0.33
0.3300000000000000155: 0 decimals 0.0000000000000000000
0.3300000000000000155: 1 decimals 0.2999999999999999889
0.3300000000000000155: 2 decimals 0.3300000000000000155
0.3300000000000000155: 3 decimals 0.3300000000000000155

I especially like the second answer.

You still aren't printing enough digits by a long shot (hint: if
the last non-zero digit after the decimal point isn't 5, and the
value isn't an exact integer, it's not exactly representable in
binary floating point):

0.33 as double:
Before: 0.329999999999999960031971113494364544749259948730 468750000000
Value: 0.330000000000000015543122344752191565930843353271 484375000000
After: 0.330000000000000071054273576010018587112426757812 500000000000

0.3 as double:
Before: 0.299999999999999933386618522490607574582099914550 781250000000
Value: 0.299999999999999988897769753748434595763683319091 796875000000
After: 0.300000000000000044408920985006261616945266723632 812500000000

Your values do seem to match the closest representable value.

[santosh]

In article <13*************@corp.supernews.com>, Mark McIntyre
<ma**********@spamcop.netwrote on Saturday 24 Nov 2007 5:01 am:

jacob navia wrote:

(nothing of substance)

oh look. Another interminable thread in which Jacob insists he's
right, and everybody else, irrespective of pedigree, [ ... ]

?

<snip>

[James Kuyper]

Richard Heathfield wrote:

James Kuyper said:

....

>If the only features of C99 that it uses are features that are widely
supported by compilers in their C99 modes, then the fact that those
modes are not fully conforming is not sufficient to render the code
valueless.

Indeed. That's why I said "almost valueless". :-)

I still disagree, even with the 'almost'. Compilers that have a mode in
which they implement most features of C99 are now widely available.

[Richard Heathfield]

James Kuyper said:

Richard Heathfield wrote:

>James Kuyper said:

...

>>If the only features of C99 that it uses are features that are widely
supported by compilers in their C99 modes, then the fact that those
modes are not fully conforming is not sufficient to render the code
valueless.

Indeed. That's why I said "almost valueless". :-)

I still disagree, even with the 'almost'. Compilers that have a mode in
which they implement most features of C99 are now widely available.

If a formal, verifiable list were available of which C99 features are
supported by *all* current mainstream hosted C implementations (including
the big iron compilers), then you'd have the makings of a point, because
it would then be possible to write portable C99 programs.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[James Kuyper]

Richard Heathfield wrote:
....

Like others here, I used gcc in non-conforming mode in an effort to compile

You deliberately choose the wrong non-conforming mode, when it was quite
clear what the correct non-conforming mode was.

the code. Anyone who claims he used gcc in *conforming* mode is mistaken,
since the code requires C99 features that are not available in any
conforming gcc mode. This is because gcc does not have a mode that
conforms to C99.

It has a mode which conforms to C99 pretty closely; well enough to make
this code work as intended. It is your free choice to not to use that
mode for code which obviously requires it, simply because that mode is
not fully conforming. That doesn't qualify as a valid objection to
Jacob's code.

[James Kuyper]

Richard Heathfield wrote:

jacob navia said:

>Richard Heathfield wrote:

>>If you can come up with a set of switches that makes the code work on
the gcc implementation currently installed on my system, I'm all ears.

What is that implementation?

2.95.3

>It must be older than 2000!

So? It still works just fine with properly written, portable code.

For your specific definitions of "properly written" and "portable". It
fails other definitions, ones that allow for C99-specific features that
are correctly implemented by a wide variety of easily available compilers.

[James Kuyper]

Richard Heathfield wrote:

James Kuyper said:

....

>No, but we should be able to read ordinary English (and technical
English) and interpret it in conventional fashion as implying, as it
normally does, a great many unstated assumptions. Stating all applicable
assumptions would also take infinite time. Even explicitly stating only
the most important assumptions that are conventionally left unstated
would make the questions unreadable.

Then we are at the stage where the OP needs to clarify his requirements,
because it seems to me that the conventional interpretation that I and
some others here have used is diametrically opposite to your conventional
interpretation (or at least the conventional interpretation that you are
defending).

The convention I'm familiar with accepts that most floating point
operations are inexact, and therefore does not require wording that
explicitly addresses that inexactness. A norm of "best approximation
that can be calculated with reasonable efficiency" is considered to be
implicit unless there's an explicit statement establishing either
stronger or weaker accuracy requirements.

I'm not sure what your convention is; from this one example I would
guess that you assume that perfect accuracy is implied unless there are
explicit statements to the contrary. You apply this assumption even when
perfect accuracy is clearly impossible, thereby justifying your
assumption that the author was too stupid to be aware of the
impossibility. This might be the case, but a more plausible assumption
is that he was using the more normal convention.

These conventions are incompatible, but not diametrically opposed. The
diametrical opposite of your convention would be that perfect inaccuracy
is always considered to be implied unless there are explicit statements
to the contrary. The normal convention is intermediate between these two
extreme positions, making it harder to describe what it's diametrical
opposite would be.

[James Kuyper]

Keith Thompson wrote:
....

Either (A) the OP really wants the exact result, and wasn't aware
that it's impossible, or (B) the OP wants an approximate result, and
wasn't aware that it's not particularly useful, or (C) the OP wants
an approximate result, and knows that it's actually useful to him
for some reason that none of us can figure out and he hasn't chosen
to share with us.

My guess is that (A) is the most likely scenario.

My guess would be (B).

[Richard Heathfield]

James Kuyper said:

Richard Heathfield wrote:
...

>Like others here, I used gcc in non-conforming mode in an effort to
compile

You deliberately choose the wrong non-conforming mode, when it was quite
clear what the correct non-conforming mode was.

Steady on there, James. "Deliberately"? That sounds a little heavy to me.
Perhaps you'd be so kind as to tell me what *you* think *my*
implementation's "correct" non-conforming mode is (setting aside, for the
time being, my view that "correct" and "non-conforming" contradict each
other). Once you've told me what options I should tell my implementation
to use, I'll happily use those options and report back to you.

>the code. Anyone who claims he used gcc in *conforming* mode is
mistaken, since the code requires C99 features that are not available in
any conforming gcc mode. This is because gcc does not have a mode that
conforms to C99.

It has a mode which conforms to C99 pretty closely; well enough to make
this code work as intended. It is your free choice to not to use that
mode for code which obviously requires it, simply because that mode is
not fully conforming. That doesn't qualify as a valid objection to
Jacob's code.

You appear to have misunderstood my response. I was getting weird results
here, *knowing* that I'd invoked gcc in non-conforming mode, so I asked
other people to check the code out, to see whether the results could be
duplicated.

The portability of the code is a very minor issue, compared to the more
serious issue that it doesn't achieve the required objective even on
platforms where it runs as intended by its programmer.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

James Kuyper said:

Richard Heathfield wrote:

>James Kuyper said:

...

>>No, but we should be able to read ordinary English (and technical
English) and interpret it in conventional fashion as implying, as it
normally does, a great many unstated assumptions. Stating all
applicable assumptions would also take infinite time. Even explicitly
stating only the most important assumptions that are conventionally
left unstated would make the questions unreadable.

Then we are at the stage where the OP needs to clarify his requirements,
because it seems to me that the conventional interpretation that I and
some others here have used is diametrically opposite to your
conventional interpretation (or at least the conventional interpretation
that you are defending).

The convention I'm familiar with accepts that most floating point
operations are inexact,

The convention I'm familiar with is that we believe what people say unless
or until we have reason to believe they are lying or mistaken. I believed
what the OP said. If you choose to believe that he was lying or mistaken,
that's entirely up to you.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999