I think 'atan' can get the angle but it is not the four quadrant angle.
Is there any function that i can get the angle from pi to pi? or I
have to use some if ... else?
I know in Matlab, we use 'atan2( )'
Also, is there any function to get the round value, similar with floor
and ceil, such like:
round(3.1) = 3
round(3.6) = 4
thanks..
Vol 29 3185
Vol <vo********@gmail.com> wrote: I think 'atan' can get the angle but it is not the four quadrant angle. Is there any function that i can get the angle from pi to pi? or I have to use some if ... else? I know in Matlab, we use 'atan2()'
atan2() also exists in C, although I can't say whether it's identical
to the MatLab function you're referencing.

Christopher BensonManica  I *should* know what I'm talking about  if I
ataru(at)cyberspace.org  don't, I need to know. Flames welcome.
Vol wrote: I think 'atan' can get the angle but it is not the four quadrant angle. Is there any function that i can get the angle from pi to pi? or I have to use some if ... else? I know in Matlab, we use 'atan2( )'
Also, is there any function to get the round value, similar with floor and ceil, such like:
round(3.1) = 3 round(3.6) = 4
thanks..
Vol
atan2(y,x) exists in C (and Matlab and Octave and Python and ...
I think all of these simply call the C function).
Take care because atan2(0,0) is undefined, some
implementations will return 0, some will crash (I think the DS2K does
a Morris Dance).
If you need to round x use floor(x + 0.5). (If you care about why
this is not perfect you already know why)
 William Hughes
William Hughes ha scritto: Vol wrote:
I think 'atan' can get the angle but it is not the four quadrant angle. Is there any function that i can get the angle from pi to pi? or I have to use some if ... else? I know in Matlab, we use 'atan2( )'
Also, is there any function to get the round value, similar with floor and ceil, such like:
round(3.1) = 3 round(3.6) = 4
thanks..
Vol atan2(y,x) exists in C (and Matlab and Octave and Python and ... I think all of these simply call the C function). Take care because atan2(0,0) is undefined, some implementations will return 0, some will crash (I think the DS2K does a Morris Dance).
If you need to round x use floor(x + 0.5). (If you care about why this is not perfect you already know why)
Can you tell me why?

Devaraja (Xdevaraja87^gmail^c0mX)
Linux Registerd User #338167 http://counter.li.org
DevarajA wrote: William Hughes ha scritto: Vol wrote:
I think 'atan' can get the angle but it is not the four quadrant angle. Is there any function that i can get the angle from pi to pi? or I have to use some if ... else? I know in Matlab, we use 'atan2( )'
Also, is there any function to get the round value, similar with floor and ceil, such like:
round(3.1) = 3 round(3.6) = 4
thanks..
Vol atan2(y,x) exists in C (and Matlab and Octave and Python and ... I think all of these simply call the C function). Take care because atan2(0,0) is undefined, some implementations will return 0, some will crash (I think the DS2K does a Morris Dance).
If you need to round x use floor(x + 0.5). (If you care about why this is not perfect you already know why)
Can you tell me why?
It is possible if x is less than 0.5 (but very close) for
x+0.5 to be greater than or equal to 1 in which case
floor(x+0.5) will be 1 rather than 0.
Also, it is not in general possible to represent a decimal
fraction exactly, so an implementation may represent
0.4999999999999999
as a floating point number greater than or equal to 0.5
in which case
floor(0.4999999999999999 + 0.5)
will be 1 rather than 0.
Question. Do you care?
William Hughes
William Hughes ha scritto:
[cut]
It is possible if x is less than 0.5 (but very close) for x+0.5 to be greater than or equal to 1 in which case floor(x+0.5) will be 1 rather than 0.
Also, it is not in general possible to represent a decimal fraction exactly, so an implementation may represent
0.4999999999999999
as a floating point number greater than or equal to 0.5 in which case
floor(0.4999999999999999 + 0.5)
will be 1 rather than 0.
Ok, thank you. Question. Do you care?
Yes. I like precision.

Devaraja (Xdevaraja87^gmail^c0mX)
Linux Registerd User #338167 http://counter.li.org
DevarajA wrote
(in article <43**********************@reader4.news.tin.it>): Question. Do you care?
Yes. I like precision.
Then you definitely need to read this: http://docs.sun.com/source/8063568/ncg_goldberg.html

Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it."  George Bernard Shaw
DevarajA wrote: William Hughes ha scritto: [cut]
It is possible if x is less than 0.5 (but very close) for x+0.5 to be greater than or equal to 1 in which case floor(x+0.5) will be 1 rather than 0.
Also, it is not in general possible to represent a decimal fraction exactly, so an implementation may represent
0.4999999999999999
as a floating point number greater than or equal to 0.5 in which case
floor(0.4999999999999999 + 0.5)
will be 1 rather than 0.
Ok, thank you.
Question. Do you care?
Yes. I like precision.
How much?
William Hughes wrote: DevarajA wrote:
William Hughes ha scritto:
Vol wrote:
I think 'atan' can get the angle but it is not the four quadrant angle. Is there any function that i can get the angle from pi to pi? or I have to use some if ... else? I know in Matlab, we use 'atan2( )'
Also, is there any function to get the round value, similar with floor and ceil, such like:
round(3.1) = 3 round(3.6) = 4
thanks..
Vol atan2(y,x) exists in C (and Matlab and Octave and Python and ... I think all of these simply call the C function). Take care because atan2(0,0) is undefined, some implementations will return 0, some will crash (I think the DS2K does a Morris Dance).
If you need to round x use floor(x + 0.5). (If you care about why this is not perfect you already know why)
Can you tell me why?
It is possible if x is less than 0.5 (but very close) for x+0.5 to be greater than or equal to 1 in which case floor(x+0.5) will be 1 rather than 0.
Also, it is not in general possible to represent a decimal fraction exactly, so an implementation may represent
0.4999999999999999
as a floating point number greater than or equal to 0.5 in which case
floor(0.4999999999999999 + 0.5)
will be 1 rather than 0.
Question. Do you care?
William Hughes
Your example is a little flawed. First, 0.5 is exactly representable in
binary floating point. Your constant, 0.4999999999999999 looks like
4.9999999999999989e01 on my machine. Less than 0.5 of course. If you're
curious, the binary of the 64bit double is..
00111111110111111111111111111111111111111111111111 11111111111110
...The binary of 0.5 is..
00111111111000000000000000000000000000000000000000 00000000000000
...Close, no cigar.
If you add one more '9' to the constant it will "round up" to 0.5 and
your example will be true. As it is, floor(0.4999999999999999 + 0.5)
yields 0.0, not 1.0 here at my house.
Question. Do you care?

Joe Wright
"Everything should be made as simple as possible, but not simpler."
 Albert Einstein 
Joe Wright wrote: William Hughes wrote: DevarajA wrote:
William Hughes ha scritto:
Vol wrote:
>I think 'atan' can get the angle but it is not the four quadrant angle. >Is there any function that i can get the angle from pi to pi? or I >have to use some if ... else? >I know in Matlab, we use 'atan2( )' > >Also, is there any function to get the round value, similar with floor >and ceil, such like: > >round(3.1) = 3 >round(3.6) = 4 > >thanks.. > >Vol atan2(y,x) exists in C (and Matlab and Octave and Python and ... I think all of these simply call the C function). Take care because atan2(0,0) is undefined, some implementations will return 0, some will crash (I think the DS2K does a Morris Dance).
If you need to round x use floor(x + 0.5). (If you care about why this is not perfect you already know why)
Can you tell me why?
It is possible if x is less than 0.5 (but very close) for x+0.5 to be greater than or equal to 1 in which case floor(x+0.5) will be 1 rather than 0.
Also, it is not in general possible to represent a decimal fraction exactly, so an implementation may represent
0.4999999999999999
as a floating point number greater than or equal to 0.5 in which case
floor(0.4999999999999999 + 0.5)
will be 1 rather than 0.
Question. Do you care?
William Hughes Your example is a little flawed. First, 0.5 is exactly representable in binary floating point. Your constant, 0.4999999999999999 looks like 4.9999999999999989e01 on my machine. Less than 0.5 of course. If you're curious, the binary of the 64bit double is..
00111111110111111111111111111111111111111111111111 11111111111110
..The binary of 0.5 is..
00111111111000000000000000000000000000000000000000 00000000000000
..Close, no cigar.
If you add one more '9' to the constant it will "round up" to 0.5 and your example will be true. As it is, floor(0.4999999999999999 + 0.5) yields 0.0, not 1.0 here at my house.
And this is a counterexample to my statement
so an implementation may represent
0.4999999999999999
as a floating point number greater than or equal to 0.5
how?
William Hughes wrote: Joe Wright wrote:
William Hughes wrote:
DevarajA wrote:
William Hughes ha scritto:
>Vol wrote: > > > >>I think 'atan' can get the angle but it is not the four quadrant angle. >>Is there any function that i can get the angle from pi to pi? or I >>have to use some if ... else? >>I know in Matlab, we use 'atan2( )' >> >>Also, is there any function to get the round value, similar with floor >>and ceil, such like: >> >>round(3.1) = 3 >>round(3.6) = 4 >> >>thanks.. >> >>Vol > > > >atan2(y,x) exists in C (and Matlab and Octave and Python and ... >I think all of these simply call the C function). >Take care because atan2(0,0) is undefined, some >implementations will return 0, some will crash (I think the DS2K does >a Morris Dance). > >If you need to round x use floor(x + 0.5). (If you care about why >this is not perfect you already know why) >
Can you tell me why? It is possible if x is less than 0.5 (but very close) for x+0.5 to be greater than or equal to 1 in which case floor(x+0.5) will be 1 rather than 0.
Also, it is not in general possible to represent a decimal fraction exactly, so an implementation may represent
0.4999999999999999
as a floating point number greater than or equal to 0.5 in which case
floor(0.4999999999999999 + 0.5)
will be 1 rather than 0.
Question. Do you care?
William Hughes
Your example is a little flawed. First, 0.5 is exactly representable in binary floating point. Your constant, 0.4999999999999999 looks like 4.9999999999999989e01 on my machine. Less than 0.5 of course. If you're curious, the binary of the 64bit double is..
001111111101111111111111111111111111111111111111 1111111111111110
..The binary of 0.5 is..
001111111110000000000000000000000000000000000000 0000000000000000
..Close, no cigar.
If you add one more '9' to the constant it will "round up" to 0.5 and your example will be true. As it is, floor(0.4999999999999999 + 0.5) yields 0.0, not 1.0 here at my house. And this is a counterexample to my statement
so an implementation may represent
0.4999999999999999
as a floating point number greater than or equal to 0.5
how?
I thought I was clear. Again, evaluation of 0.4999999999999999 does not
evaluate to double >= to 0.5 but if evaluated to float it may round up
to 0.5 but there is no case that I know of where it will be greater than
0.5. Is there such a case?

Joe Wright
"Everything should be made as simple as possible, but not simpler."
 Albert Einstein 
Joe Wright wrote: William Hughes wrote: Joe Wright wrote:
William Hughes wrote:
DevarajA wrote:
>William Hughes ha scritto: > > >>Vol wrote: >> >> >> >>>I think 'atan' can get the angle but it is not the four quadrant angle. >>>Is there any function that i can get the angle from pi to pi? or I >>>have to use some if ... else? >>>I know in Matlab, we use 'atan2( )' >>> >>>Also, is there any function to get the round value, similar with floor >>>and ceil, such like: >>> >>>round(3.1) = 3 >>>round(3.6) = 4 >>> >>>thanks.. >>> >>>Vol >> >> >> >>atan2(y,x) exists in C (and Matlab and Octave and Python and ... >>I think all of these simply call the C function). >>Take care because atan2(0,0) is undefined, some >>implementations will return 0, some will crash (I think the DS2K does >>a Morris Dance). >> >>If you need to round x use floor(x + 0.5). (If you care about why >>this is not perfect you already know why) >> > >Can you tell me why? >
It is possible if x is less than 0.5 (but very close) for x+0.5 to be greater than or equal to 1 in which case floor(x+0.5) will be 1 rather than 0.
Also, it is not in general possible to represent a decimal fraction exactly, so an implementation may represent
0.4999999999999999
as a floating point number greater than or equal to 0.5 in which case
floor(0.4999999999999999 + 0.5)
will be 1 rather than 0.
Question. Do you care?
William Hughes
Your example is a little flawed. First, 0.5 is exactly representable in binary floating point. Your constant, 0.4999999999999999 looks like 4.9999999999999989e01 on my machine. Less than 0.5 of course. If you're curious, the binary of the 64bit double is..
001111111101111111111111111111111111111111111111 1111111111111110
..The binary of 0.5 is..
001111111110000000000000000000000000000000000000 0000000000000000
..Close, no cigar.
If you add one more '9' to the constant it will "round up" to 0.5 and your example will be true. As it is, floor(0.4999999999999999 + 0.5) yields 0.0, not 1.0 here at my house. And this is a counterexample to my statement
so an implementation may represent
0.4999999999999999
as a floating point number greater than or equal to 0.5
how? I thought I was clear. Again, evaluation of 0.4999999999999999 does not evaluate to double >= to 0.5 but if evaluated to float it may round up to 0.5 but there is no case that I know of where it will be greater than 0.5. Is there such a case?
I do not know.
reread carefully
so an implementation may represent
Note that this says may. The word "may" does not indicate that
any given implementation does, or indeed that there exists an
implemenation that does. It just means that according to the
standard this is possible.
Note rounding up to 0.5 will probably cause floor(.49999999999999999 +
0.5)
to be 1, so the question of whether any implementation chooses a value
greater than 0.5 is entirely academic.
William Hughes
William Hughes wrote: Joe Wright wrote:
William Hughes wrote:
Joe Wright wrote:
William Hughes wrote:
>DevarajA wrote: > > > >>William Hughes ha scritto: >> >> >> >>>Vol wrote: >>> >>> >>> >>> >>>>I think 'atan' can get the angle but it is not the four quadrant angle. >>>>Is there any function that i can get the angle from pi to pi? or I >>>>have to use some if ... else? >>>>I know in Matlab, we use 'atan2( )' >>>> >>>>Also, is there any function to get the round value, similar with floor >>>>and ceil, such like: >>>> >>>>round(3.1) = 3 >>>>round(3.6) = 4 >>>> >>>>thanks.. >>>> >>>>Vol >>> >>> >>> >>>atan2(y,x) exists in C (and Matlab and Octave and Python and ... >>>I think all of these simply call the C function). >>>Take care because atan2(0,0) is undefined, some >>>implementations will return 0, some will crash (I think the DS2K does >>>a Morris Dance). >>> >>>If you need to round x use floor(x + 0.5). (If you care about why >>>this is not perfect you already know why) >>> >> >>Can you tell me why? >> > > >It is possible if x is less than 0.5 (but very close) for >x+0.5 to be greater than or equal to 1 in which case >floor(x+0.5) will be 1 rather than 0. > >Also, it is not in general possible to represent a decimal >fraction exactly, so an implementation may represent > > 0.4999999999999999 > >as a floating point number greater than or equal to 0.5 >in which case > > floor(0.4999999999999999 + 0.5) > >will be 1 rather than 0. > >Question. Do you care? > > William Hughes >
Your example is a little flawed. First, 0.5 is exactly representable in binary floating point. Your constant, 0.4999999999999999 looks like 4.9999999999999989e01 on my machine. Less than 0.5 of course. If you're curious, the binary of the 64bit double is..
0011111111011111111111111111111111111111111111 111111111111111110
..The binary of 0.5 is..
0011111111100000000000000000000000000000000000 000000000000000000
..Close, no cigar.
If you add one more '9' to the constant it will "round up" to 0.5 and your example will be true. As it is, floor(0.4999999999999999 + 0.5) yields 0.0, not 1.0 here at my house. And this is a counterexample to my statement
so an implementation may represent
0.4999999999999999
as a floating point number greater than or equal to 0.5
how?
I thought I was clear. Again, evaluation of 0.4999999999999999 does not evaluate to double >= to 0.5 but if evaluated to float it may round up to 0.5 but there is no case that I know of where it will be greater than 0.5. Is there such a case?
I do not know.
reread carefully
so an implementation may represent
Note that this says may. The word "may" does not indicate that any given implementation does, or indeed that there exists an implemenation that does. It just means that according to the standard this is possible.
Note rounding up to 0.5 will probably cause floor(.49999999999999999 + 0.5) to be 1, so the question of whether any implementation chooses a value greater than 0.5 is entirely academic.
William Hughes
I haven't trimmed this post so that others might see everything. In any
case, this my last comment on the matter. You apparently can't read what
I write. There is no case that I know where 0.4999999999999999 will
result in a value greater than 0.5 . And you don't either. Nor does
anyone else.
Happy Turkey Day.

Joe Wright
"Everything should be made as simple as possible, but not simpler."
 Albert Einstein 
Joe Wright wrote: William Hughes wrote: Joe Wright wrote:
William Hughes wrote:
Joe Wright wrote:
>William Hughes wrote: > > >>DevarajA wrote: >> >> >> >>>William Hughes ha scritto: >>> >>> >>> >>>>Vol wrote: >>>> >>>> >>>> >>>> >>>>>I think 'atan' can get the angle but it is not the four quadrant angle. >>>>>Is there any function that i can get the angle from pi to pi? or I >>>>>have to use some if ... else? >>>>>I know in Matlab, we use 'atan2( )' >>>>> >>>>>Also, is there any function to get the round value, similar with floor >>>>>and ceil, such like: >>>>> >>>>>round(3.1) = 3 >>>>>round(3.6) = 4 >>>>> >>>>>thanks.. >>>>> >>>>>Vol >>>> >>>> >>>> >>>>atan2(y,x) exists in C (and Matlab and Octave and Python and ... >>>>I think all of these simply call the C function). >>>>Take care because atan2(0,0) is undefined, some >>>>implementations will return 0, some will crash (I think the DS2K does >>>>a Morris Dance). >>>> >>>>If you need to round x use floor(x + 0.5). (If you care about why >>>>this is not perfect you already know why) >>>> >>> >>>Can you tell me why? >>> >> >> >>It is possible if x is less than 0.5 (but very close) for >>x+0.5 to be greater than or equal to 1 in which case >>floor(x+0.5) will be 1 rather than 0. >> >>Also, it is not in general possible to represent a decimal >>fraction exactly, so an implementation may represent >> >> 0.4999999999999999 >> >>as a floating point number greater than or equal to 0.5 >>in which case >> >> floor(0.4999999999999999 + 0.5) >> >>will be 1 rather than 0. >> >>Question. Do you care? >> >> William Hughes >> > >Your example is a little flawed. First, 0.5 is exactly representable in >binary floating point. Your constant, 0.4999999999999999 looks like >4.9999999999999989e01 on my machine. Less than 0.5 of course. If you're >curious, the binary of the 64bit double is.. > >0011111111011111111111111111111111111111111111 111111111111111110 > >..The binary of 0.5 is.. > >0011111111100000000000000000000000000000000000 000000000000000000 > >..Close, no cigar. > >If you add one more '9' to the constant it will "round up" to 0.5 and >your example will be true. As it is, floor(0.4999999999999999 + 0.5) >yields 0.0, not 1.0 here at my house. And this is a counterexample to my statement
so an implementation may represent
0.4999999999999999
as a floating point number greater than or equal to 0.5
how?
I thought I was clear. Again, evaluation of 0.4999999999999999 does not evaluate to double >= to 0.5 but if evaluated to float it may round up to 0.5 but there is no case that I know of where it will be greater than 0.5. Is there such a case?
I do not know.
reread carefully
so an implementation may represent
Note that this says may. The word "may" does not indicate that any given implementation does, or indeed that there exists an implemenation that does. It just means that according to the standard this is possible.
Note rounding up to 0.5 will probably cause floor(.49999999999999999 + 0.5) to be 1, so the question of whether any implementation chooses a value greater than 0.5 is entirely academic.
William Hughes I haven't trimmed this post so that others might see everything. In any case, this my last comment on the matter. You apparently can't read what I write. There is no case that I know where 0.4999999999999999 will result in a value greater than 0.5 . And you don't either. Nor does anyone else.
Happy Turkey Day.
I haven't tried this but a float (not double) on a PIC C compiler (such
as HiTech C) might simply because it doesn't use the IEEE floating
point due to optimising for speed/space (hey, the PIC is a very small 8
bit machine).
Other than weird compilers not accurately implementing floats on 8 bit
machines there are also weird machines like the CDC and Cray which has
non IEEE conforming binary representation of floats. On these machines
the result may or may not be correct. Anyone have access to one of
these and print out their binary representation like Joe did?
On 20051124, sl*******@yahoo.com <sl*******@gmail.com> wrote: Joe Wright wrote: William Hughes wrote: > Joe Wright wrote: > >>William Hughes wrote: >> >>>Joe Wright wrote: >>> >>> >>>>William Hughes wrote: >>>> >>>> >>>>>DevarajA wrote: >>>>> >>>>> >>>>> >>>>>>William Hughes ha scritto: >>>>>> >>>>>> >>>>>> >>>>>>>Vol wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>I think 'atan' can get the angle but it is not the four quadrant angle. >>>>>>>>Is there any function that i can get the angle from pi to pi? or I >>>>>>>>have to use some if ... else? >>>>>>>>I know in Matlab, we use 'atan2( )' >>>>>>>> >>>>>>>>Also, is there any function to get the round value, similar with floor >>>>>>>>and ceil, such like: >>>>>>>> >>>>>>>>round(3.1) = 3 >>>>>>>>round(3.6) = 4 >>>>>>>> >>>>>>>>thanks.. >>>>>>>> >>>>>>>>Vol >>>>>>> >>>>>>> >>>>>>> >>>>>>>atan2(y,x) exists in C (and Matlab and Octave and Python and ... >>>>>>>I think all of these simply call the C function). >>>>>>>Take care because atan2(0,0) is undefined, some >>>>>>>implementations will return 0, some will crash (I think the DS2K does >>>>>>>a Morris Dance). >>>>>>> >>>>>>>If you need to round x use floor(x + 0.5). (If you care about why >>>>>>>this is not perfect you already know why) >>>>>>> >>>>>> >>>>>>Can you tell me why? >>>>>> >>>>> >>>>> >>>>>It is possible if x is less than 0.5 (but very close) for >>>>>x+0.5 to be greater than or equal to 1 in which case >>>>>floor(x+0.5) will be 1 rather than 0. >>>>> >>>>>Also, it is not in general possible to represent a decimal >>>>>fraction exactly, so an implementation may represent >>>>> >>>>> 0.4999999999999999 >>>>> >>>>>as a floating point number greater than or equal to 0.5 >>>>>in which case >>>>> >>>>> floor(0.4999999999999999 + 0.5) >>>>> >>>>>will be 1 rather than 0. >>>>> >>>>>Question. Do you care? >>>>> >>>>> William Hughes >>>>> >>>> >>>>Your example is a little flawed. First, 0.5 is exactly representable in >>>>binary floating point. Your constant, 0.4999999999999999 looks like >>>>4.9999999999999989e01 on my machine. Less than 0.5 of course. If you're >>>>curious, the binary of the 64bit double is.. >>>> >>>>0011111111011111111111111111111111111111111111 111111111111111110 >>>> >>>>..The binary of 0.5 is.. >>>> >>>>0011111111100000000000000000000000000000000000 000000000000000000 >>>> >>>>..Close, no cigar. >>>> >>>>If you add one more '9' to the constant it will "round up" to 0.5 and >>>>your example will be true. As it is, floor(0.4999999999999999 + 0.5) >>>>yields 0.0, not 1.0 here at my house. >>> >>> >>> >>>And this is a counterexample to my statement >>> >>> so an implementation may represent >>> >>> 0.4999999999999999 >>> >>> as a floating point number greater than or equal to 0.5 >>> >>>how? >>> >> >>I thought I was clear. Again, evaluation of 0.4999999999999999 does not >>evaluate to double >= to 0.5 but if evaluated to float it may round up >>to 0.5 but there is no case that I know of where it will be greater than >>0.5. Is there such a case? > > > I do not know. > > reread carefully > > so an implementation may represent > > Note that this says may. The word "may" does not indicate that > any given implementation does, or indeed that there exists an > implemenation that does. It just means that according to the > standard this is possible. > > Note rounding up to 0.5 will probably cause floor(.49999999999999999 + > 0.5) > to be 1, so the question of whether any implementation chooses a value > greater than 0.5 is entirely academic. > > William Hughes > I haven't trimmed this post so that others might see everything. In any case, this my last comment on the matter. You apparently can't read what I write. There is no case that I know where 0.4999999999999999 will result in a value greater than 0.5 . And you don't either. Nor does anyone else.
Happy Turkey Day.
I haven't tried this but a float (not double) on a PIC C compiler (such as HiTech C) might simply because it doesn't use the IEEE floating point due to optimising for speed/space (hey, the PIC is a very small 8 bit machine). Other than weird compilers not accurately implementing floats on 8 bit machines there are also weird machines like the CDC and Cray which has non IEEE conforming binary representation of floats. On these machines the result may or may not be correct. Anyone have access to one of these and print out their binary representation like Joe did?
It's still hard to imagine a floatingpoint format in which 0.5 does not
have an exact representation. Any system based on binary, it's
1*(2**1), and even with a decimal [bcd] system it's 5*(10**1).
It's theoretically possible that a very bad system might get .49999... >
..5 due to cumulative rounding error [say, .4+.09+.009+.0009+.00009...],
but unlikely.
Joe Wright wrote: William Hughes wrote: Joe Wright wrote:
William Hughes wrote:
Joe Wright wrote:
>William Hughes wrote: > > >>DevarajA wrote: >> >> >> >>>William Hughes ha scritto: >>> >>> >>> >>>>Vol wrote: >>>> >>>> >>>> >>>> >>>>>I think 'atan' can get the angle but it is not the four quadrant angle. >>>>>Is there any function that i can get the angle from pi to pi? or I >>>>>have to use some if ... else? >>>>>I know in Matlab, we use 'atan2( )' >>>>> >>>>>Also, is there any function to get the round value, similar with floor >>>>>and ceil, such like: >>>>> >>>>>round(3.1) = 3 >>>>>round(3.6) = 4 >>>>> >>>>>thanks.. >>>>> >>>>>Vol >>>> >>>> >>>> >>>>atan2(y,x) exists in C (and Matlab and Octave and Python and ... >>>>I think all of these simply call the C function). >>>>Take care because atan2(0,0) is undefined, some >>>>implementations will return 0, some will crash (I think the DS2K does >>>>a Morris Dance). >>>> >>>>If you need to round x use floor(x + 0.5). (If you care about why >>>>this is not perfect you already know why) >>>> >>> >>>Can you tell me why? >>> >> >> >>It is possible if x is less than 0.5 (but very close) for >>x+0.5 to be greater than or equal to 1 in which case >>floor(x+0.5) will be 1 rather than 0. >> >>Also, it is not in general possible to represent a decimal >>fraction exactly, so an implementation may represent >> >> 0.4999999999999999 >> >>as a floating point number greater than or equal to 0.5 >>in which case >> >> floor(0.4999999999999999 + 0.5) >> >>will be 1 rather than 0. >> >>Question. Do you care? >> >> William Hughes >> > >Your example is a little flawed. First, 0.5 is exactly representable in >binary floating point. Your constant, 0.4999999999999999 looks like >4.9999999999999989e01 on my machine. Less than 0.5 of course. If you're >curious, the binary of the 64bit double is.. > >0011111111011111111111111111111111111111111111 111111111111111110 > >..The binary of 0.5 is.. > >0011111111100000000000000000000000000000000000 000000000000000000 > >..Close, no cigar. > >If you add one more '9' to the constant it will "round up" to 0.5 and >your example will be true. As it is, floor(0.4999999999999999 + 0.5) >yields 0.0, not 1.0 here at my house. And this is a counterexample to my statement
so an implementation may represent
0.4999999999999999
as a floating point number greater than or equal to 0.5
how?
I thought I was clear. Again, evaluation of 0.4999999999999999 does not evaluate to double >= to 0.5 but if evaluated to float it may round up to 0.5 but there is no case that I know of where it will be greater than 0.5. Is there such a case?
I do not know.
reread carefully
so an implementation may represent
Note that this says may. The word "may" does not indicate that any given implementation does, or indeed that there exists an implemenation that does. It just means that according to the standard this is possible.
Note rounding up to 0.5 will probably cause floor(.49999999999999999 + 0.5) to be 1, so the question of whether any implementation chooses a value greater than 0.5 is entirely academic.
William Hughes I haven't trimmed this post so that others might see everything. In any case, this my last comment on the matter. You apparently can't read what I write. There is no case that I know where 0.4999999999999999 will result in a value greater than 0.5 . And you don't either. Nor does anyone else.
Happy Turkey Day.
When discussing putative behaviour of C code there are
four common issues:
1. Behaviour dictated by the standard
2. Behaviour on common hosted implementations
3. Behaviour on nonhosted/embedded implementations
4. Behaviour on my implementation (depressingly often
i386/Microsoft vcc)
Aswers to 1. are important because these must apply to any
conforming implementation. However, in some ways the standard
is quite lax. E.g. RAND_MAX = 15 is legal, but no implementation
would provide such a thing. The answer to 1. is what
is commonly meant by "an implementation may"
Answers to 2. are important because this is what a user
may be expected to see. Of course "common" is context
dependent and a matter of opinoion. Are Cray and CDC
machines common? Should a machine designed in the
60's be considered common?
Answers to 3 can be important because this is a very
important sector for C programming, because
behaviours are often very different here, and because the
requirements of the standard are significantly different
for nonhosted systems.
Answers to 4 are usually irrelevant, and often very
wrong. Usually these take the form of examples
against a more general statment.
You said that i=1,i++ + i++ was undefined behaviour
but I tried it on my system and it gave 3 just like it
should.
My initial statement was a mix of 1 and 2 (I am
not familiar with the systems in 3). The standard
allows .4999999999999999 to be converted to a floating
point value > 0.5, but this is very unlikely. On the
other hand it is likely that some systems may convert
0.4999999999999999 to 0.5. (It is certain that some
systems will convert 0.49999999999999999 to 0.5)
The upshot is that is is likely that
floor(0.4999999999999999 +0.5) will equal 1 on some
systems (and certain that floor(0.49999999999999999 +0.5)
will equal 1 on some systems).
Your initial statement was pure 4.
You are wrong, You said that 0.4999999999999999
could be converted to a number greater than or equal
to 0.5. but I tried it on my sytem and it wasn't.
Your later statemenst mixed in some irrelevant 2
No system will convert 0.4999999999999999 to
a number greater than 0.5 (irrelevant because
mine was a staetment about legality (1.) not
whether the behaviour was common, and because
an alternate behaviour (converting to 0.5) was
both reasonable and leads to the same
undesirable result).
William Hughes
"sl*******@yahoo.com" <sl*******@gmail.com> writes:
[...] I haven't tried this but a float (not double) on a PIC C compiler (such as HiTech C) might simply because it doesn't use the IEEE floating point due to optimising for speed/space (hey, the PIC is a very small 8 bit machine). Other than weird compilers not accurately implementing floats on 8 bit machines there are also weird machines like the CDC and Cray which has non IEEE conforming binary representation of floats. On these machines the result may or may not be correct. Anyone have access to one of these and print out their binary representation like Joe did?
Note that recent Cray machines use IEEE floating point; I think only
the vector machines (T90, SV1, etc.) use Cray floating point.

Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jordan Abel wrote: On 20051124, sl*******@yahoo.com <sl*******@gmail.com> wrote: Joe Wright wrote: William Hughes wrote: > Joe Wright wrote: > >>William Hughes wrote: >> >>>Joe Wright wrote: >>> >>> >>>>William Hughes wrote: >>>> >>>> >>>>>DevarajA wrote: >>>>> >>>>> >>>>> >>>>>>William Hughes ha scritto: >>>>>> >>>>>> >>>>>> >>>>>>>Vol wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>I think 'atan' can get the angle but it is not the four quadrant angle. >>>>>>>>Is there any function that i can get the angle from pi to pi? or I >>>>>>>>have to use some if ... else? >>>>>>>>I know in Matlab, we use 'atan2( )' >>>>>>>> >>>>>>>>Also, is there any function to get the round value, similar with floor >>>>>>>>and ceil, such like: >>>>>>>> >>>>>>>>round(3.1) = 3 >>>>>>>>round(3.6) = 4 >>>>>>>> >>>>>>>>thanks.. >>>>>>>> >>>>>>>>Vol >>>>>>> >>>>>>> >>>>>>> >>>>>>>atan2(y,x) exists in C (and Matlab and Octave and Python and ... >>>>>>>I think all of these simply call the C function). >>>>>>>Take care because atan2(0,0) is undefined, some >>>>>>>implementations will return 0, some will crash (I think the DS2K does >>>>>>>a Morris Dance). >>>>>>> >>>>>>>If you need to round x use floor(x + 0.5). (If you care about why >>>>>>>this is not perfect you already know why) >>>>>>> >>>>>> >>>>>>Can you tell me why? >>>>>> >>>>> >>>>> >>>>>It is possible if x is less than 0.5 (but very close) for >>>>>x+0.5 to be greater than or equal to 1 in which case >>>>>floor(x+0.5) will be 1 rather than 0. >>>>> >>>>>Also, it is not in general possible to represent a decimal >>>>>fraction exactly, so an implementation may represent >>>>> >>>>> 0.4999999999999999 >>>>> >>>>>as a floating point number greater than or equal to 0.5 >>>>>in which case >>>>> >>>>> floor(0.4999999999999999 + 0.5) >>>>> >>>>>will be 1 rather than 0. >>>>> >>>>>Question. Do you care? >>>>> >>>>> William Hughes >>>>> >>>> >>>>Your example is a little flawed. First, 0.5 is exactly representable in >>>>binary floating point. Your constant, 0.4999999999999999 looks like >>>>4.9999999999999989e01 on my machine. Less than 0.5 of course. If you're >>>>curious, the binary of the 64bit double is.. >>>> >>>>0011111111011111111111111111111111111111111111 111111111111111110 >>>> >>>>..The binary of 0.5 is.. >>>> >>>>0011111111100000000000000000000000000000000000 000000000000000000 >>>> >>>>..Close, no cigar. >>>> >>>>If you add one more '9' to the constant it will "round up" to 0.5 and >>>>your example will be true. As it is, floor(0.4999999999999999 + 0.5) >>>>yields 0.0, not 1.0 here at my house. >>> >>> >>> >>>And this is a counterexample to my statement >>> >>> so an implementation may represent >>> >>> 0.4999999999999999 >>> >>> as a floating point number greater than or equal to 0.5 >>> >>>how? >>> >> >>I thought I was clear. Again, evaluation of 0.4999999999999999 does not >>evaluate to double >= to 0.5 but if evaluated to float it may round up >>to 0.5 but there is no case that I know of where it will be greater than >>0.5. Is there such a case? > > > I do not know. > > reread carefully > > so an implementation may represent > > Note that this says may. The word "may" does not indicate that > any given implementation does, or indeed that there exists an > implemenation that does. It just means that according to the > standard this is possible. > > Note rounding up to 0.5 will probably cause floor(.49999999999999999 + > 0.5) > to be 1, so the question of whether any implementation chooses a value > greater than 0.5 is entirely academic. > > William Hughes > I haven't trimmed this post so that others might see everything. In any case, this my last comment on the matter. You apparently can't read what I write. There is no case that I know where 0.4999999999999999 will result in a value greater than 0.5 . And you don't either. Nor does anyone else.
Happy Turkey Day.
I haven't tried this but a float (not double) on a PIC C compiler (such as HiTech C) might simply because it doesn't use the IEEE floating point due to optimising for speed/space (hey, the PIC is a very small 8 bit machine). Other than weird compilers not accurately implementing floats on 8 bit machines there are also weird machines like the CDC and Cray which has non IEEE conforming binary representation of floats. On these machines the result may or may not be correct. Anyone have access to one of these and print out their binary representation like Joe did?
It's still hard to imagine a floatingpoint format in which 0.5 does not have an exact representation. Any system based on binary, it's 1*(2**1), and even with a decimal [bcd] system it's 5*(10**1).
True, but irrelevant. It is still legal for a system to convert
0.4999999999999999 to a number greater that 0.5, even if
0.5 can be represented exactly. (for quality of implementation
reasons, this will probably not happen)
William Hughes
In article <11**********************@g49g2000cwa.googlegroups .com> "William Hughes" <wp*******@hotmail.com> writes:
.... 1. Behaviour dictated by the standard 2. Behaviour on common hosted implementations 3. Behaviour on nonhosted/embedded implementations 4. Behaviour on my implementation (depressingly often i386/Microsoft vcc)
My initial statement was a mix of 1 and 2 (I am not familiar with the systems in 3). The standard allows .4999999999999999 to be converted to a floating point value > 0.5, but this is very unlikely. On the other hand it is likely that some systems may convert 0.4999999999999999 to 0.5. (It is certain that some systems will convert 0.49999999999999999 to 0.5) The upshot is that is is likely that floor(0.4999999999999999 +0.5) will equal 1 on some systems (and certain that floor(0.49999999999999999 +0.5) will equal 1 on some systems).
But that is not really the problem, because in that case 0.4999...999 will
compare equal to 0.5 (assuming a wellbehaved floatingpoint system). On
the other hand, it *is* possible that you have a number that compares
smaller than 0.5 but where adding 0.5 to that number results in 1.0.
The following program:
#include <stdio.h>
#include <stdlib.h>
int main(void) {
double d = 0.25, r;
int i = 0;
r = d;
while(d < 0.5) {
if(d + 0.5 == 1.0) {
printf("equal at step %d\n", i);
exit(0);
}
r = r / 2;
i++;
d += r;
}
}
Will print
equal at step 52
on a Sun running Solaris, it will print
equal at step 63
on an Intel machine using gcc with O3, and it will
print nothing on that same machine using gcc without
optimisation (but will termate). So under some circumstances
we have a number that is smaller than 0.5 but where
floor(x + 0.5) will yield 1.0.

dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
In article <11**********************@g47g2000cwa.googlegroups .com> "sl*******@yahoo.com" <sl*******@gmail.com> writes:
.... Other than weird compilers not accurately implementing floats on 8 bit machines there are also weird machines like the CDC and Cray which has non IEEE conforming binary representation of floats. On these machines the result may or may not be correct. Anyone have access to one of these and print out their binary representation like Joe did?
On sane implementations when converting a number from the (decimal)
source format to the (nondecimal) internal format, the result after
conversion will not be larger than the smallest representable number
equal to or larger than the number in the source format. Cray
provided a sane implementation, so on that machine 0.4999999...999
would be <= 0.5 regardless the number of 9's.

dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dik T. Winter wrote: In article <11**********************@g49g2000cwa.googlegroups .com> "William Hughes" <wp*******@hotmail.com> writes: ... > 1. Behaviour dictated by the standard > 2. Behaviour on common hosted implementations > 3. Behaviour on nonhosted/embedded implementations > 4. Behaviour on my implementation (depressingly often > i386/Microsoft vcc) > > My initial statement was a mix of 1 and 2 (I am > not familiar with the systems in 3). The standard > allows .4999999999999999 to be converted to a floating > point value > 0.5, but this is very unlikely. On the > other hand it is likely that some systems may convert > 0.4999999999999999 to 0.5. (It is certain that some > systems will convert 0.49999999999999999 to 0.5) > The upshot is that is is likely that > floor(0.4999999999999999 +0.5) will equal 1 on some > systems (and certain that floor(0.49999999999999999 +0.5) > will equal 1 on some systems).
But that is not really the problem, because in that case 0.4999...999 will compare equal to 0.5 (assuming a wellbehaved floatingpoint system). On the other hand, it *is* possible that you have a number that compares smaller than 0.5 but where adding 0.5 to that number results in 1.0.
The following program:
#include <stdio.h> #include <stdlib.h>
int main(void) { double d = 0.25, r; int i = 0; r = d; while(d < 0.5) { if(d + 0.5 == 1.0) { printf("equal at step %d\n", i); exit(0); } r = r / 2; i++; d += r; } }
Will print equal at step 52 on a Sun running Solaris, it will print equal at step 63 on an Intel machine using gcc with O3, and it will print nothing on that same machine using gcc without optimisation (but will termate). So under some circumstances we have a number that is smaller than 0.5 but where floor(x + 0.5) will yield 1.0.
Nicely illustrated. And it can be tested even on non "weird"
implementations ;)
Dik T. Winter wrote: In article <11**********************@g49g2000cwa.googlegroups .com> "William Hughes" <wp*******@hotmail.com> writes: ... > 1. Behaviour dictated by the standard > 2. Behaviour on common hosted implementations > 3. Behaviour on nonhosted/embedded implementations > 4. Behaviour on my implementation (depressingly often > i386/Microsoft vcc) > > My initial statement was a mix of 1 and 2 (I am > not familiar with the systems in 3). The standard > allows .4999999999999999 to be converted to a floating > point value > 0.5, but this is very unlikely. On the > other hand it is likely that some systems may convert > 0.4999999999999999 to 0.5. (It is certain that some > systems will convert 0.49999999999999999 to 0.5) > The upshot is that is is likely that > floor(0.4999999999999999 +0.5) will equal 1 on some > systems (and certain that floor(0.49999999999999999 +0.5) > will equal 1 on some systems). But that is not really the problem, because in that case 0.4999...999 will compare equal to 0.5 (assuming a wellbehaved floatingpoint system).
Well, if you expect
float(0.49999...9 + 0.5)
to equal 0 no matter how many 9's you have then it is a problem. But I
take your point. This is a simple consequence of finite precision
(inevitable on any real machine). x comparing less that 0.5 and
x+0.5 comparing greater than or equal to 1 is not. (not a simple
consequence in any case).
William Hughes
On the other hand, it *is* possible that you have a number that compares smaller than 0.5 but where adding 0.5 to that number results in 1.0.
The following program:
#include <stdio.h> #include <stdlib.h>
int main(void) { double d = 0.25, r; int i = 0; r = d; while(d < 0.5) { if(d + 0.5 == 1.0) { printf("equal at step %d\n", i); exit(0); } r = r / 2; i++; d += r; } }
Will print equal at step 52 on a Sun running Solaris, it will print equal at step 63 on an Intel machine using gcc with O3, and it will print nothing on that same machine using gcc without optimisation (but will termate). So under some circumstances we have a number that is smaller than 0.5 but where floor(x + 0.5) will yield 1.0.  dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131 home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Jordan Abel wrote: On 20051124, sl*******@yahoo.com <sl*******@gmail.com> wrote:
I haven't tried this but a float (not double) on a PIC C compiler (such as HiTech C) might simply because it doesn't use the IEEE floating point due to optimising for speed/space (hey, the PIC is a very small 8 bit machine). Other than weird compilers not accurately implementing floats on 8 bit machines there are also weird machines like the CDC and Cray which has non IEEE conforming binary representation of floats. On these machines the result may or may not be correct. Anyone have access to one of these and print out their binary representation like Joe did?
It's still hard to imagine a floatingpoint format in which 0.5 does not have an exact representation. Any system based on binary, it's 1*(2**1), and even with a decimal [bcd] system it's 5*(10**1).
It's theoretically possible that a very bad system might get .49999... > .5 due to cumulative rounding error [say, .4+.09+.009+.0009+.00009...], but unlikely.
Yep, however, some popular DS9000 variants might have a FLT_RADIX which
is an odd prime number or a product of odd prime numbers.
Cheers
Michael

EMail: Mine is an /at/ gmx /dot/ de address.
Now for the round function. Here is a version that is (I think) foolproof,
assuming a sane implementation:
double round(double x) {
if(fabs(x) < 0.5) { /* allow for bad behaviour when x close to + 0.5 */
return 0;
} else if(x > 0) {
if(trunc(x) == x) { /* allow for rounding of integers to the next
higher when adding 0.5 */
return x;
} else {
return trunc(x + 0.5);
}
} else {
if(ceil(x) == x) { /* see above */
return x;
} else {
return ceil(x  0.5);
}
}
}

dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dik T. Winter wrote: Now for the round function. Here is a version that is (I think) foolproof, assuming a sane implementation:
double round(double x) { if(fabs(x) < 0.5) { /* allow for bad behaviour when x close to + 0.5 */ return 0; } else if(x > 0) { if(trunc(x) == x) { /* allow for rounding of integers to the next higher when adding 0.5 */ return x; } else { return trunc(x + 0.5); } } else { if(ceil(x) == x) { /* see above */ return x; } else { return ceil(x  0.5); } } }
I am not sure what you are requiring of a sane implementation.
But it seems to me that even on a sane implementation we could
have
x compares less than 1.5
x + 0.5 compares equal to 2
Under the above would x not round to 2?
How about assuming that
if y is an integer, y+0.5 is exaclty representable and
the expression y+0.5 will produce this representation
(this could be considered sane behaviour for a system with
radix 2 assuming y is not too large)
Then we could have something like
double round(double x)
{
if(x < ((floor)(x) + 0.5) )
{
return floor(x);
}
else
{
return floor(x) +1;
}
}
William Hughes
In article <11**********************@g14g2000cwa.googlegroups .com> "William Hughes" <wp*******@hotmail.com> writes:
.... I am not sure what you are requiring of a sane implementation.
But it seems to me that even on a sane implementation we could have x compares less than 1.5 x + 0.5 compares equal to 2
I think not. Consider 1.5, in binary that would be 1.1, and any number
larger than 1 and smaller than 1.5 would (in binary) start with 1.0.
Adding 0.5 to that would merely replace that 0 by an 1, and such a number
should not compare equal to 2. At least on a sane implementation. (I
have worked with only one system where two numbers could compare equal
while they actually were not equal, I tend to call such a system insane.)
How about assuming that if y is an integer, y+0.5 is exaclty representable and the expression y+0.5 will produce this representation (this could be considered sane behaviour for a system with radix 2 assuming y is not too large)
See the latter requirement. If y is too large this can be false.
Especially this is false under IEEE double precision when x is (say)
2^52 + 1. Adding 0.5 to it results in 2^52 + 2 (round to even rule).
double round(double x) { if(x < ((floor)(x) + 0.5) ) { return floor(x); }
I do not think you want this. Suppose x == 0.75, it will return 0.0.

dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
> > I am not sure what you are requiring of a sane implementation. But it seems to me that even on a sane implementation we could have x compares less than 1.5 x + 0.5 compares equal to 2
I think not. Consider 1.5, in binary that would be 1.1, and any number larger than 1 and smaller than 1.5 would (in binary) start with 1.0. Adding 0.5 to that would merely replace that 0 by an 1, and such a number should not compare equal to 2. At least on a sane implementation. (I
Consider this scenario:
x = 1.011111111111111111111111111111111111111111111111 111111 * 2^0
(This is math, not C, and ^ is the exponentiation operator).
but this is a result with excess precision kept in registers but
it can't be stored. The compiler has it in a register so it uses it
there, and it compares less than 1.5.
x + 0.5 = 1.111111111111111111111111111111111111111111111111 111111 * 2^0
Now C stores it in a double variable, which doesn't have so many
bits, so it gets rounded, to:
x + 0.5 = 1.0000000000000000000000000000000000000000000 * 2^1
and it will compare equal to 2.
(No quibbling over the number of bits shown being insufficient for
a double: this is just an example and I didn't want line wrap on
80 column screens.)
Now, I think keeping "excess precision" violates C99, but lots
of compilers do it anyway, and taking care to NOT do it can be a
significant performance hit on some architectures, so it may be
common to see this with real compilers (especially if they are
not invoked with the "strictly follow the excessprecision rules"
flag). But I don't think you get to call it an "insane" implementation
for allowing this.
Gordon L. Burditt
In article <11*************@corp.supernews.com> go***********@burditt.org (Gordon Burditt) writes: I think not. Consider 1.5, in binary that would be 1.1, and any number larger than 1 and smaller than 1.5 would (in binary) start with 1.0. Adding 0.5 to that would merely replace that 0 by an 1, and such a number should not compare equal to 2. At least on a sane implementation. (I
Consider this scenario: x = 1.011111111111111111111111111111111111111111111111 111111 * 2^0 (This is math, not C, and ^ is the exponentiation operator). but this is a result with excess precision kept in registers but it can't be stored.
Yes, I know everything about excess precision. Do you think it is sane
that the following program:
#include <stdio.h>
int equal(double x, y) {
return(x == y);
}
int main(void) {
double d, e;
.... perform some initialisations on d and e and continue with:
if(d != e && equal(d, e)) {
printf("Arghh\n");
}
}
prints something?
But whatever, a round function has only to do with its argument and if
everything is well, in the argument excess precision is properly removed.

dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dik T. Winter wrote: In article <11**********************@g14g2000cwa.googlegroups .com> "William Hughes" <wp*******@hotmail.com> writes: ... > I am not sure what you are requiring of a sane implementation. > > But it seems to me that even on a sane implementation we could > have > x compares less than 1.5 > x + 0.5 compares equal to 2 I think not. Consider 1.5, in binary that would be 1.1, and any number larger than 1 and smaller than 1.5 would (in binary) start with 1.0. Adding 0.5 to that would merely replace that 0 by an 1, and such a number should not compare equal to 2. At least on a sane implementation. (I have worked with only one system where two numbers could compare equal while they actually were not equal, I tend to call such a system insane.)
Well, flipping the bit may be best practice, but it is possible
(e.g. (as Gordeon Burrit pointed out) the use of an extended precision
register followed by rounding) to
get x + 0.5 equal to 2. It seems to me a bit strong
to call an implementation that does this insane. > How about assuming that > if y is an integer, y+0.5 is exaclty representable and > the expression y+0.5 will produce this representation > (this could be considered sane behaviour for a system with > radix 2 assuming y is not too large) See the latter requirement. If y is too large this can be false. Especially this is false under IEEE double precision when x is (say) 2^52 + 1. Adding 0.5 to it results in 2^52 + 2 (round to even rule).
Indeed. However, if x is large enough for this to be an issue,
the utility of rounding x must be strongly questioned. > double round(double x) > { > if(x < ((floor)(x) + 0.5) ) > { > return floor(x); > }
I do not think you want this. Suppose x == 0.75, it will return 0.0.
I get ((floor)(0.75) + 0.5) = ( 0 + 0.5) = 0.5. What am I missing?
William Hughes
In article <11**********************@g49g2000cwa.googlegroups .com> "William Hughes" <wp*******@hotmail.com> writes: Dik T. Winter wrote: In article <11**********************@g14g2000cwa.googlegroups .com> "William Hughes" <wp*******@hotmail.com> writes: ... > I am not sure what you are requiring of a sane implementation. > > But it seems to me that even on a sane implementation we could > have > x compares less than 1.5 > x + 0.5 compares equal to 2
I think not. Consider 1.5, in binary that would be 1.1, and any number larger than 1 and smaller than 1.5 would (in binary) start with 1.0. Adding 0.5 to that would merely replace that 0 by an 1, and such a number should not compare equal to 2. At least on a sane implementation. (I have worked with only one system where two numbers could compare equal while they actually were not equal, I tend to call such a system insane.)
Well, flipping the bit may be best practice, but it is possible (e.g. (as Gordeon Burrit pointed out) the use of an extended precision register followed by rounding) to get x + 0.5 equal to 2. It seems to me a bit strong to call an implementation that does this insane.
We were talking about a function that does rounding. Such a function will
not receive excess precision numbers, except if it does not conform to the
standard. > How about assuming that > if y is an integer, y+0.5 is exaclty representable and > the expression y+0.5 will produce this representation > (this could be considered sane behaviour for a system with > radix 2 assuming y is not too large)
See the latter requirement. If y is too large this can be false. Especially this is false under IEEE double precision when x is (say) 2^52 + 1. Adding 0.5 to it results in 2^52 + 2 (round to even rule).
Indeed. However, if x is large enough for this to be an issue, the utility of rounding x must be strongly questioned.
Ah, you must also be questioning the utility of the IEEE standard trunc
and ceiling instructions. As a blackbox routine given a double precision
number, the routine should do whatever it can to return the best possible
result. > { > if(x < ((floor)(x) + 0.5) ) > { > return floor(x); > }
I do not think you want this. Suppose x == 0.75, it will return 0.0.
I get ((floor)(0.75) + 0.5) = ( 0 + 0.5) = 0.5. What am I missing?
My brain damage.

dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/ This discussion thread is closed Replies have been disabled for this discussion. Similar topics
reply
views
Thread by sector119 
last post: by

5 posts
views
Thread by Darren Grant 
last post: by

4 posts
views
Thread by Schraalhans Keukenmeester 
last post: by

2 posts
views
Thread by Carl Gilbert 
last post: by

15 posts
views
Thread by cwsullivan 
last post: by

6 posts
views
Thread by openopt 
last post: by

2 posts
views
Thread by Spartacus 
last post: by

9 posts
views
Thread by Ken Fine 
last post: by

10 posts
views
Thread by Bernhard Reinhardt 
last post: by
          