Rounding double

[Mark McIntyre]

Re: Rounding double

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]

Re: Rounding double

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]

Re: Rounding double

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]

Re: Rounding double

>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.330000000000 0000155: 0 decimals 0.0000000000000 000
>0.330000000000 0000155: 1 decimals 0.3000000000000 000
>0.330000000000 0000155: 2 decimals 0.3300000000000 000
>0.330000000000 0000155: 3 decimals 0.3300000000000 000
>0.330000000000 0000155: 4 decimals 0.3300000000000 000
>0.330000000000 0000155: 5 decimals 0.3300000000000 000
>0.330000000000 0000155: 6 decimals 0.3300000000000 000
>0.330000000000 0000155: 7 decimals 0.3300000000000 000
>0.330000000000 0000155: 8 decimals 0.3300000000000 000
>0.330000000000 0000155: 9 decimals 0.3300000000000 000
>0.330000000000 0000155: 10 decimals 0.3300000000000 000
>0.330000000000 0000155: 11 decimals 0.3300000000000 000
>0.330000000000 0000155: 12 decimals 0.3300000000000 000
>0.330000000000 0000155: 13 decimals 0.3300000000000 000
>0.330000000000 0000155: 14 decimals 0.3300000000000 000
>
>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]

Re: Rounding double

>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]

Re: Rounding double

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

>
>mark@thelinu x clc_tests $ ./a.out 0.33
>0.330000000000 0000155: 0 decimals 0.0000000000000 000000
>0.330000000000 0000155: 1 decimals 0.2999999999999 999889
>0.330000000000 0000155: 2 decimals 0.3300000000000 000155
>0.330000000000 0000155: 3 decimals 0.3300000000000 000155
>
>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.3299999999999 999600319711134 943645447492599 487304687500000 00
Value: 0.3300000000000 000155431223447 521915659308433 532714843750000 00
After: 0.3300000000000 000710542735760 100185871124267 578125000000000 00

0.3 as double:
Before: 0.2999999999999 999333866185224 906075745820999 145507812500000 00
Value: 0.2999999999999 999888977697537 484345957636833 190917968750000 00
After: 0.3000000000000 000444089209850 062616169452667 236328125000000 00

Your values do seem to match the closest representable value.

[santosh]

Re: Rounding double

In article <13keomc774gb73 9@corp.supernew s.com>, Mark McIntyre
<markmcintyre@s pamcop.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]

Re: Rounding double

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]

Re: Rounding double

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]

Re: Rounding double

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]

Re: Rounding double

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]

Re: Rounding double

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]

Re: Rounding double

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]

Re: Rounding double

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. "Deliberate ly"? 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]

Re: Rounding double

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