You are not logged in.

- Topics: Active | Unanswered

Pages: **1**

**mikau****Member**- Registered: 2005-08-22
- Posts: 1,504

This function is to find the polar angle from "cent" (a center point) and obj (an object) Typically when we write something in polarform we begin from the origin (0,0) but this allows you to speficy the origin. First it finds the horizontal distance from the center to the object and then finds the vertical distance. The vertical distance is divided by the horizontal distance to find the tangent. Then atan() is used (arctangent) to find the angle to which the tangent belongs (but atan returns the value in radians so I converted it). I used a few "if" statements first to return 270 or 90 when the adjacent is zero, to avoid division by zero, and also when oposite and adjacent are both zero, (which means the points overlap and there is no angle relation).

I just don't like using a whole mess of "if" statements, and I want to make the function as simple, short, and direct as possible. Take a look at the function, tell me what you think of it, and tell me if you think it can be simplified or if some steps are redundant.

float polarangle(float centh, float centv, float objh, float objv)

{float h, v, r;

v = objv - centv; // finding vertical distance from centv, to objvh = objh - centh; //finding horrizontal distance from centh, to objh

if ((h == 0) && (v < 0)) { return 270;} // avoid division by zero

if ((h == 0) && (v > 0)) { return 90; } // avoid division by zero

if ((h == 0) && (v == 0)) { return 0; } // points overlap, no angler = atan(v/h) * 180/3.14159; //calling arctan and converting radians to degree's

if (h < 0) { return (r + 180);}

return r;

}

A logarithm is just a misspelled algorithm.

Offline

**mikau****Member**- Registered: 2005-08-22
- Posts: 1,504

I really need to rename the parameters... :-/

A logarithm is just a misspelled algorithm.

Offline

**mikau****Member**- Registered: 2005-08-22
- Posts: 1,504

I'm going to write a function for the distance formula to find the directed distance from the center point, to the object, then I can write a function that calls these two express any points coordinates in referance in polar form only in relation to any center point you chose, rather then just the origin. The primary purpose of this will be used to rotate a point around an axis (the center) by first converting to polar form, adding or subtracting the angle of rotation, then converting back to rectangular from to get the new coordinates of the point.

A logarithm is just a misspelled algorithm.

Offline

**MathsIsFun****Administrator**- Registered: 2005-01-21
- Posts: 7,626

Function looks good, clear and simple, and should translate well to many similar languages.

I usually prefer "x" and "y" rather than "h" and "v".

Also, don't say "obj" because that makes me think it is something to do with "Object Oriented". How about "Origin"?

BTW you could use some of the "Object Oriented" functions of C++. For example you could create a "point" class, which could have that function (and the radius) built into it.

"The physicists defer only to mathematicians, and the mathematicians defer only to God ..." - Leon M. Lederman

Offline

**mikau****Member**- Registered: 2005-08-22
- Posts: 1,504

Great minds think alike. But I have my reasons. I already have a class "point" with x,y,z member data. But this polar angle function is going to be used not just on the x,y plane. Its going to be used on x,z plane, a y,z plane, as well as the x,y plane. So if I use x and y, in somecases I'd have to use y, for x, instead of y, for y. The same reason why I didn't pass in "points" as arguements. Because sometimes I'll be using only their y,z coordinates, other times their x,z coordinates, etc. There is probably a simple way to do it with points but I haven't thought of one yet.

I'm writing a math program to calculate the location of a point (on an x,y plane) based on its x,y, z coordinates, the observers x,y,z coordinates, and the angle at which he's looking. Basicly I'm reinventing the 3d engine myself, trying to figure things out on my own. I've heard real 3d engines just use matrices but my system seems to work anyways.

Your object and origin suggestions are good, the only reason I didn't pic "origin" is because that usually means 0,0,0.

A logarithm is just a misspelled algorithm.

Offline

**mikau****Member**- Registered: 2005-08-22
- Posts: 1,504

Darn it! Cos(x) is messing up and giving me a very small decimal number for the cosine of 90 instead of 0. ( and no I didn't forget to convert to radians)

A logarithm is just a misspelled algorithm.

Offline

**mikau****Member**- Registered: 2005-08-22
- Posts: 1,504

Well I guess I could just take the sine of the complement angle since thats what cosine means and the sine function appears to be working fine. (I call this sort of thing "humoring the computer")

*Last edited by mikau (2005-10-10 11:49:41)*

A logarithm is just a misspelled algorithm.

Offline

**mikau****Member**- Registered: 2005-08-22
- Posts: 1,504

It works!

A logarithm is just a misspelled algorithm.

Offline

**mikau****Member**- Registered: 2005-08-22
- Posts: 1,504

It would be much easier (and clearer) to just pass in points as arguements, rather then having to individually pass in horizontal and vertical coordinates. But then I'd have to define a new function for every plane. xy, xz, yz. I wonder if it would be worth it...

A logarithm is just a misspelled algorithm.

Offline

**mikau****Member**- Registered: 2005-08-22
- Posts: 1,504

Grrr.... well it seems theres also some slight inacuracy with sin(x) at some angles as well. Phoey!

What I need is a way to round a number to 4, or 5 decimal places.

A logarithm is just a misspelled algorithm.

Offline

**ryos****Member**- Registered: 2005-08-04
- Posts: 394

If C++ doesn't have a ready-made function for that (it really should), here's a half-baked algorthm for rounding.

First, I can't remember how C++ handles rounding when you assign a float to an integer; I think it truncates rather than rounds. If so, the algorithm (in psuedocode) looks something like this:

```
float number; //The number to be rounded
p = 5; //The precision to round to
float bumper = number * 10^p;
int chopper = (int) bumper;
int tester = (int) (bumper + 0.5);
if (tester > chopper) { float roundedNumber = tester * (1/10^p); }
else { float roundedNumber = chopper * (1/10^p); }
```

Again, my idea of C++'s rounding behaviour may be off, but I think you get the idea.

It's probably possible to do the same thing using bitwise wizardry, and such an approach may be simpler. But it would be a lot harder to implement and understand. Take your pick.

El que pega primero pega dos veces.

Offline

**ryos****Member**- Registered: 2005-08-04
- Posts: 394

Oh, I just read the whole discussion. Your imprecision is probably coming from the conversion to radians, since you only use 5 decimal places of pi. And, it looks like your imprecision starts where your precision of pi ends, which makes sense if you've had the misfortune of having to work with significant figures.

El que pega primero pega dos veces.

Offline

**MathsIsFun****Administrator**- Registered: 2005-01-21
- Posts: 7,626

Sorry mikau, I lost track of this conversation.

How is it going now? Post code and problem if you can.

"The physicists defer only to mathematicians, and the mathematicians defer only to God ..." - Leon M. Lederman

Offline

**mikau****Member**- Registered: 2005-08-22
- Posts: 1,504

Things are going well. I just ignored the slight inaccuracies. I already tried writing pi to a lot more decimal places but that just ended up writing really small numbers in scientific notation when it should have been zero.

But in the end, it seemed the inaccuaracies were small enough not to be detrimental to the program.

A logarithm is just a misspelled algorithm.

Offline

**ryos****Member**- Registered: 2005-08-04
- Posts: 394

Yeah, I doubt that, with screen resolution being what it is, you'd have much of a problem.

It occurs to me that you might try writing it to the precision storable by an unsigned double. That's the ceiling on the precision of your program, right? So that should make it come out zero? I may not understand the issues but it seems reasonable to me.

El que pega primero pega dos veces.

Offline

**mikau****Member**- Registered: 2005-08-22
- Posts: 1,504

Well radians will always be positive...hmmm... might be a good idea. :-)

A logarithm is just a misspelled algorithm.

Offline

**ryos****Member**- Registered: 2005-08-04
- Posts: 394

Hey, wait, I was wrong--radians will not always be positive in the important physical sense of direction of motion...

El que pega primero pega dos veces.

Offline

**mikau****Member**- Registered: 2005-08-22
- Posts: 1,504

Hmm... yeah I guess if we ever need the sin, cosine, tangent or arctangent of a negative angle, that would occur.

A logarithm is just a misspelled algorithm.

Offline

**mikau****Member**- Registered: 2005-08-22
- Posts: 1,504

(edit) oops! Wrong thread! x_x

*Last edited by mikau (2005-10-16 14:55:27)*

A logarithm is just a misspelled algorithm.

Offline

Pages: **1**