Re: Does C have function to get angle?
Joe Wright wrote:[color=blue]
> William Hughes wrote:[color=green]
> > Joe Wright wrote:
> >[color=darkred]
> >>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
> >>>>>>>implemen tations 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.4999999999999 999
> >>>>>
> >>>>>as a floating point number greater than or equal to 0.5
> >>>>>in which case
> >>>>>
> >>>>> floor(0.4999999 999999999 + 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.4999999999999 999 looks like
> >>>>4.999999999 9999989e-01 on my machine. Less than 0.5 of course. If you're
> >>>>curious, the binary of the 64-bit double is..
> >>>>
> >>>>00111111110 111111111111111 111111111111111 111111111111111 11111110
> >>>>
> >>>>..The binary of 0.5 is..
> >>>>
> >>>>00111111111 000000000000000 000000000000000 000000000000000 00000000
> >>>>
> >>>>..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.4999999 999999999 + 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.4999999999999 999
> >>>
> >>> as a floating point number greater than or equal to 0.5
> >>>
> >>>how?
> >>>
> >>
> >>I thought I was clear. Again, evaluation of 0.4999999999999 999 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?[/color]
> >
> >
> > 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(.49999999 999999999 +
> > 0.5)
> > to be 1, so the question of whether any implementation chooses a value
> > greater than 0.5 is entirely academic.
> >
> > -William Hughes
> >[/color]
> 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.4999999999999 999 will
> result in a value greater than 0.5 . And you don't either. Nor does
> anyone else.
>
> Happy Turkey Day.[/color]
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 non-hosted/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 non-hosted 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 .49999999999999 99 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.4999999999999 999 to 0.5. (It is certain that some
systems will convert 0.4999999999999 9999 to 0.5)
The upshot is that is is likely that
floor(0.4999999 999999999 +0.5) will equal 1 on some
systems (and certain that floor(0.4999999 9999999999 +0.5)
will equal 1 on some systems).
Your initial statement was pure 4.
You are wrong, You said that 0.4999999999999 999
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.4999999999999 999 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
Joe Wright wrote:[color=blue]
> William Hughes wrote:[color=green]
> > Joe Wright wrote:
> >[color=darkred]
> >>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
> >>>>>>>implemen tations 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.4999999999999 999
> >>>>>
> >>>>>as a floating point number greater than or equal to 0.5
> >>>>>in which case
> >>>>>
> >>>>> floor(0.4999999 999999999 + 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.4999999999999 999 looks like
> >>>>4.999999999 9999989e-01 on my machine. Less than 0.5 of course. If you're
> >>>>curious, the binary of the 64-bit double is..
> >>>>
> >>>>00111111110 111111111111111 111111111111111 111111111111111 11111110
> >>>>
> >>>>..The binary of 0.5 is..
> >>>>
> >>>>00111111111 000000000000000 000000000000000 000000000000000 00000000
> >>>>
> >>>>..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.4999999 999999999 + 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.4999999999999 999
> >>>
> >>> as a floating point number greater than or equal to 0.5
> >>>
> >>>how?
> >>>
> >>
> >>I thought I was clear. Again, evaluation of 0.4999999999999 999 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?[/color]
> >
> >
> > 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(.49999999 999999999 +
> > 0.5)
> > to be 1, so the question of whether any implementation chooses a value
> > greater than 0.5 is entirely academic.
> >
> > -William Hughes
> >[/color]
> 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.4999999999999 999 will
> result in a value greater than 0.5 . And you don't either. Nor does
> anyone else.
>
> Happy Turkey Day.[/color]
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 non-hosted/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 non-hosted 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 .49999999999999 99 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.4999999999999 999 to 0.5. (It is certain that some
systems will convert 0.4999999999999 9999 to 0.5)
The upshot is that is is likely that
floor(0.4999999 999999999 +0.5) will equal 1 on some
systems (and certain that floor(0.4999999 9999999999 +0.5)
will equal 1 on some systems).
Your initial statement was pure 4.
You are wrong, You said that 0.4999999999999 999
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.4999999999999 999 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
Comment