Rounding double

[James Kuyper]

Re: Rounding double

jacob navia wrote:

James Kuyper wrote:

>jacob navia wrote:
>...

>>This is perfectly OK since double has only 16 decimal digits,
>>and the first ones in your result appear at 1e-21 (if I counted

>>
>Citation please? Where does the C standard impose such requirements
>for all implementations ?

>
I changed my function to use DBL_DIG already. See elsethread

Your program assumes that long long is guaranteed to be sufficiently
large to store the longest integer representable as a double. The use
you made of DBL_DIG doesn't cover the problems that can occur if that
assumption is false, as it is allowed to be for conforming
implementations of C which do not #define __STDC_IEC559__ .

When are you planning on acknowledging that point? I'm getting pretty
tire of typing the name of that macro.

[jacob navia]

Re: Rounding double

Marco Manfredini wrote:

jacob navia wrote:

>Marco Manfredini wrote:

>>Richard Heathfield wrote:
>>>jacob navia said:
>>>>
>>>>Richard Heathfield 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
>>>>
>>>No, I said "someone else". I wouldn't trust you to make a cup of
>>>coffee, let alone a computer program.
>>>>
>>long double roundto(long double value, unsigned digits)
>>{

>>
>This is not my function excuse me.
>>
>My function returned a double, NOT a long double.
>>
>AND THAT IS IMPORTANT!

>
Yes, for your demonstration, because double gracefully removes the cruft
from the end of your "rounded" value and printf does the rest.

We are speaking (read the subject line please) of "Rounding double"

OK????

I have said many times already that to round to double precision
you use higher precision then you round as the last step!

I am not speaking about rounding of long double that is a much
more difficult problem. And please do not CHANGE MY function and
then accuse ME of not being honest!


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Re: Rounding double

Dik T. Winter wrote:

In article <fi51vq$6hb$2@a ioe.orgjacob@nospam.or g writes:
...

double roundto(long double value, unsigned digits)
{
long double fv=fabsl(value) ;
if (fv powl(10.0L,DBL_ DIG) || digits DBL_DIG)
return value; // Out of range
long long p = powl(10.0L, digits);
return roundl(value * p ) / (double)p;
}
>
Supposing long double is extended precision, why should this not
work?

>
Because the return of roundto(6.12345 e+50, 4) should be 6.12300e+50.

This is nonsense. We are speaking of rounding to some place AFTER the
decimal point here!


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Re: Rounding double

Dik T. Winter wrote:

In article <fi4vj0$v9g$1@a ioe.orgjacob@nospam.or g writes:
...

And it IS possible to round correctly a double precision
number. One of the possible solutions is:
>
#include <stdio.h>
#include <math.h>
>
void RoundMyDouble (long double *value, short numberOfPrecisi ons)
>
{
long double fv=fabsl(*value );
if (fv 1e17)
return ;
long long p = powl(10.0L, numberOfPrecisi ons);
*value = (long long)(*value * p + 0.5L) / (double)p;
}

>
This does *not* round correctly. If you round 6.123465e+23 to four
places you should get: 6.123000e+23.

No, we speak about places AFTER the decimal point

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Dik T. Winter]

Re: Rounding double

In article <JrxLDH.ILE@cwi .nl"Dik T. Winter" <Dik.Winter@cwi .nlwrites:
....

This does *not* round correctly. If you round 6.123465e+23 to four
places you should get: 6.123000e+23.

Sorry, I was wrong.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Flash Gordon]

Re: Rounding double

jacob navia wrote, On 22/11/07 23:35:

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 cite (again)
>
F.2 Types
1 The C floating types match the IEC 60559 formats as follows:
— The float type matches the IEC 60559 single format.
— The double type matches the IEC 60559 double format

Now read the introduction to the Annex again, specifically the part that
says "An implementation that defines __STDC_IEC_559_ _ shall conform to
the specifications in this annex." Then note the conditional in that
statement which makes the entire annex optional. Something that has
already been pointed out to you.

Here are some references to show it has been pointed out to you

http://groups.google.com/group/comp.lang.c/browse_thread/thread/c6b7ba44fdc33fac/20345b4f241c0201?lnk=st&q=#20345b4f241c0201

http://groups.google.com/group/comp.lang.c/browse_thread/thread/b0954f5dc7300ed6/872a58ce536d7ddb?lnk=st&q=#872a58ce536d7ddb

http://groups.google.com/group/comp.lang.c/browse_thread/thread/8b2025e2e0239a9f/9639c3b8f11ad83d?lnk=st&q=#9639c3b8f11ad83d

That is just a few of the occasions it has been pointed out just in case
the posts in this thread pointing it out have failed to reach you.
--
Flash Gordon

[Marco Manfredini]

Re: Rounding double

jacob navia wrote:

>
I have said many times already that to round to double precision
you use higher precision then you round as the last step!
>
I am not speaking about rounding of long double that is a much
more difficult problem. And please do not CHANGE MY function and
then accuse ME of not being honest!
>
>

If I take your original routine I get:
0.3333333332999 999787382705562 777118757367

using a long double return I get:
0.3333333332999 999999886331369 935987822828

So basically you are saying, your kludge works by converting a value
with a smaller error into a result with a *larger error*. You are hoping
that the current rounding mode does the cleanup, that's all. This is
extremely fragile.

[James Kuyper]

Re: Rounding double

jacob navia wrote:

James Kuyper wrote:

....

>I suppose you could impose the arbitrary requirement digits >= 0, but
>the function has an obvious meaning for digits<0, and that meaning is
>just as useful as the meaning for digits >= 0 (which is not meant to
>imply that it's particularly useful in either case).
>>

>
>
PARSE ERROR.
>
Can you tell me
1) Why you want a negative rounding? What that would mean?

digits== 2 indicates rounding to the nearest multiple of 10^-2==0.01
digits== 1 indicates rounding to the nearest multiple of 10^-1==0.1
digits== 0 indicates rounding to the nearest multiple of 10^0==1.0
digits==-1 would indicate rounding to the nearest multiple of 10^1==10.
digits==-2 would indicate rounding to the nearest multiple of 10^2==100
etc.

It isn't even difficult to modify your algorithm to handle this case.
Please slow down and think more about your messages before posting them.
You're missing some pretty obvious points due to overly rushed posting.

2) Why is not particularly useful?

Because rounding to a specified number of decimal digits makes sense
almost exclusive for character string outputs, and the printf() family
of functions already handles that part of the task quite well.

>Specifying that long double has extended precision is not sufficient,
>even when digits>=0. A conforming implementation of C can use extended
>precision for both double and long double, so long as __STDC_IEC559__
>is not #defined. In that case there's no guarantee that 'p' is big
>enough to store the largest integer that can be stored in a double.

>
So what? This means that you will not get the best results
as with better implementations but you WILL get the BEST
result for THAT implementation.

No, my point was that if 'p' is not big enough to store the longest
integer that can be stored in a double, you will get a result that is
less precise than the best you can get on THAT implementation. That's
because use of 'long long' as an intermediate is not the only possible
way to do it, and some of the other ways allow you to get the full
maximum accuracy.

>As a result, the rounded result will have less accuracy than it should.

>
Fine. Obviously we should use the standard types for longest ints
here intmax_t and not long long

Not needed. If you bother thinking about the hints I dropped, it should
be quite obvious how to perform the task without using any integer type
bigger than int.

[Flash Gordon]

Re: Rounding double

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

James Kuyper wrote:

>jacob navia wrote:

>>James Kuyper wrote:
>>>jacob navia wrote:
>>>>James Kuyper wrote:
>>>>>jacob navia wrote:
>>>>>>James Kuyper wrote:
>>>>>...
>>>>>>Probabl y. Your solution is always the best since you did not
>>>>>>propose any
>>>>>>
>>>>>?
>>>>>I suggesting using sprintf() and sscanf(). I left the details to
>>>>>be worked out by the reader. Was that too obscure a hint for you?
>>>>>
>>>>But he was asking for a function that returns a double, not
>>>>asking about PRINTING a double.
>>>>
>>>OK - so my hint WAS too obscure. Think about it a little while
>>>before you respond again. I'm sure you can figure it out with a
>>>little extra thought. In particular, think about the implications
>>>of the fact that I specified sprintf() rather than printf(), and
>>>sscanf() instead of scanf().

>>
>Have you given any more thought to my hint? If not, why did you quote it?
>>
>Note: Richard Heathfield has been saying this is impossible, I've been
>saying it is possible. That's because we're referring to two different
>things. It is impossible in binary floating point formats to represent
>exactly an arbitrary floating point value rounded to a specified
>number of decimal digits. That's simply because 10 is not a power of
>2. That's what Richard was talking about.
>>
>However, it is possible to calculate a result that is as close to the
>ideally rounded value as is permitted by the precision of the floating
>point type, which is what I'm talking about.

At least your solution has a correct intermediate result, although the
final result could well be inaccurate as you acknowledge.

>>double roundto(long double value, unsigned digits)
>>{
>> long double fv=fabsl(value) ;
>> if (fv powl(10.0L,DBL_ DIG) || digits DBL_DIG)
>> return value; // Out of range
>> long long p = powl(10.0L, digits);
>> return roundl(value * p ) / (double)p;
>>}
>>>
>>Supposing long double is extended precision, why should this not
>>work?

>>
>Well, it unnecessarily fails to work when digits is negative.

>
???
It is unsigned, how can it be negative?

Where did the OP specify only a positive number?

>I suppose you could impose the arbitrary requirement digits >= 0, but
>the function has an obvious meaning for digits<0, and that meaning is
>just as useful as the meaning for digits >= 0 (which is not meant to
>imply that it's particularly useful in either case).
>>

>
>
PARSE ERROR.
>
Can you tell me
1) Why you want a negative rounding? What that would mean?

Tell me to the nearest million what your sales figures are for the last
year...

2) Why is not particularly useful?

Because if you are doing further arithmetic on the number you have
errors and if not you can just output it to the correct number of digits.

>Specifying that long double has extended precision is not sufficient,
>even when digits>=0. A conforming implementation of C can use extended
>precision for both double and long double, so long as __STDC_IEC559__
>is not #defined. In that case there's no guarantee that 'p' is big
>enough to store the largest integer that can be stored in a double.

>
So what? This means that you will not get the best results
as with better implementations but you WILL get the BEST
result for THAT implementation.

double and long double could be exactly the same, or long long could be
too small.

>As a result, the rounded result will have less accuracy than it should.

>
Fine. Obviously we should use the standard types for longest ints
here intmax_t and not long long

Which still might not be long enough.

Point taken.

You still need more work to understand the problems.
--
Flash Gordon

[Flash Gordon]

Re: Rounding double

jacob navia wrote, On 23/11/07 00:01:

James Kuyper wrote:

>jacob navia wrote:

>>Mark McIntyre wrote:

>...

>>>I copy-pasted this exact code, and compiled under gcc 4.1.2:
>>>>
>>>thelinux clc_tests $ ./a.out 0.33
>>>1374389535.0 000000000000000 000: 0 decimals 1374389535.0000 000000000000
>>>1374389535.0 000000000000000 000: 1 decimals 1374389535.0000 000000000000
>>>>
>>>I'm giving this one a 'strange' score of 'high'
>>>>
>>>
>>Yes, because stdlib.h is missing. You need it for the prototype of atof.
>>You saw the warning and then you spread nonsense, like all
>>your posts.

>>
>Why was it missing?

>
In lcc-win wasn't missing since it is in stdlib.h

Your original code posted here did not include stdlib.h, it started:
--------------------
d:\lcc\mc68\tes t>type tdouble3.c
#include <stdio.h>
#include <float.h>
#include <math.h>

double roundto(long double value, unsigned digits)
--------------------
The above is a direct copy and paste from your post.
--
Flash Gordon

[James Kuyper]

Re: Rounding double

Dik T. Winter wrote:

In article <fi51vq$6hb$2@a ioe.orgjacob@nospam.or g writes:
...

double roundto(long double value, unsigned digits)
{
long double fv=fabsl(value) ;
if (fv powl(10.0L,DBL_ DIG) || digits DBL_DIG)
return value; // Out of range
long long p = powl(10.0L, digits);
return roundl(value * p ) / (double)p;
}
>
Supposing long double is extended precision, why should this not
work?

>
Because the return of roundto(6.12345 e+50, 4) should be 6.12300e+50.

I think the OP was talking about the number of digits after the decimal
point in %f format, not in %e format.

[James Kuyper]

Re: Rounding double

jacob navia wrote:

James Kuyper wrote:

>jacob navia wrote:

>>Mark McIntyre wrote:

>...

>>>I copy-pasted this exact code, and compiled under gcc 4.1.2:
>>>>
>>>thelinux clc_tests $ ./a.out 0.33
>>>1374389535.0 000000000000000 000: 0 decimals 1374389535.0000 000000000000
>>>1374389535.0 000000000000000 000: 1 decimals 1374389535.0000 000000000000
>>>>
>>>I'm giving this one a 'strange' score of 'high'
>>>>
>>>
>>Yes, because stdlib.h is missing. You need it for the prototype of atof.
>>You saw the warning and then you spread nonsense, like all
>>your posts.

>>
>Why was it missing?

>
In lcc-win wasn't missing since it is in stdlib.h

I wasn't asking why atof was missing, I was asking why

#include <stdlib.h>

was missing.

[CBFalconer]

Re: Rounding double

jacob navia wrote:

Walter Roberson wrote:

>jacob navia <jacob@nospam.o rgwrote:

>>Richard Heathfield wrote:
>>>jacob navia said:

>>

>>>>Who cares?

>>

>>>People who don't wish to mislead to OP by giving incorrect advice.

>>

>>Incorrect advice happens only when they read your posts.

>>
>Incorrect advice also happens when people read some of *my* posts,
>so your "only" would appear to be incorrect.
>>
>I don't know of -any- poster here who has a perfect advice posting
>record (though some average much higher quality than others.)

>
And there are others that do not give ANY solution, limiting
themselves to say why the solutions presented in some cases not
asked for would not work
>
I used the original solution and fixed it for double precision,

< it is surely not the best solution.

>
But instead of proposing a better solution this people limit
to talking nonsense without ever proposing anything else.
>
Then I get angry start getting mad at heathfield and this
degrades.

No, you didn't propose a better solution. You proposed a solution
that is invalid on all the newsgroups posted (long since snipped),
and thoroughly off-topic. You then objected to being corrected.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home .att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Re: Rounding double

jacob navia wrote:

Mark McIntyre wrote:
>

.... snip ...

>

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

>
Yes, because stdlib.h is missing. You need it for the prototype
of atof. You saw the warning and then you spread nonsense, like
all your posts.

Oh well done. Someone responds to your post, and you then come
back with a nasty dig, thus gaining many friends in the newsgroup.
You really needed that final sentence.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home .att.net>
Try the download section.


--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Re: Rounding double

Richard Heathfield wrote:

jacob navia said:
>

.... snip ...

>

>And it IS possible to round correctly a double precision number.

>
Show me 0.33 rounded to one decimal place.

Hunh? How about:

double r = 0.33, s;

s = (int)((r * 10.0) + 0.5) / 10.0;

which, according to me, gives the desired value in s within the
accuracy limits of doubles. I suspect it might even work for C++.
:-)

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home .att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com