Rounding double

[Richard Heathfield]

Philip Potter said:

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.

 

[jacob navia]

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.

 

[Richard Heathfield]

jacob navia said:

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.

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

Quite so. This is indeed the whole point.

<snip>

 

[jacob navia]

jacob navia said:


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


Okay.

cc1: unknown C standard `c99'

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

Your gcc is older than the year 2000. I would suggest that you
stop this theater, get a newer version of gcc, and stop
this stupid attitude.

Using a gcc 2.96 from July 2000 (more than 7 years old) I compile
with
gcc -std=c99 tdouble.c -lm
and obtain good results.

 

[jacob navia]

Philip Potter said:



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!

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!

 

[James Kuyper]

Philip Potter said:



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.

 

[Marco Manfredini]

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.

 

[jacob navia]

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.

 

[James Kuyper]

James Kuyper said: ....

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.

 

[jacob navia]

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.

 

[Richard]

It is quite possible that the OP was unaware of the fact that the
rounding could not be performed exactly. 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. Leaving out the "best available approximation
..." wording in the expectation that it would be inferred by any
reasonable reader is the norm, not the exception, in such
specifications.

The OP's follow-up messages have not clarified whether or not he was
aware of that issue when he posted the original message.

It is typical of here that someone takes a perfectly obvious request and plays
mind games in order to elevate his own views. A quick count of the
number of times "Indeed" is used normally indicates the level of huff
and puff being attained.

The fact that the OP asked about "rounding" *immediately* suggests he is
aware of loss of detail. And no one anywhere has suggested that
"rounding" doesn't give an "approximation".

Mr Heathfield erected a straw man to knock down in an attempt to further
argue with and discredit Jacob.

 

[Richard]

jacob navia said:


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


Okay.

cc1: unknown C standard `c99'

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

You become more ludicrous with every post.

C99 is an accepted standard. Tough titties if you can't be arsed to
download a free compiler which can deal with the solutions to the
problems being prescribed here.

 

[vippstar]

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:
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.h> and <complex.h> that 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.

EXACTLY.

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

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.

 

[Philip Potter]

Philip Potter said:



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!

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]

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 )

 

[Bart]

Bart said:


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.

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:

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]

jacob navia said:

Your gcc is older than the year 2000.

It is nevertheless a compiler that conforms to the C90 Standard. As far as
I'm aware, there are no free compilers available for my platform that
conform to C99.

I would suggest that you
stop this theater, get a newer version of gcc, and stop
this stupid attitude.

Using a gcc 2.96 from July 2000 (more than 7 years old) I compile
with
gcc -std=c99 tdouble.c -lm
and obtain good results.

Results that round correctly? I don't think so.

 

[Richard Heathfield]

jacob navia said:

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.

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.

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.)