Random Loc in Circular Range?

[Kenoriga]

Like "GetRandomLocInRect", is there one that can get a random location in a circle?

I found some Circle Rect thingies in JassCraft, and they require some mathematics. If there isn't any direct way to achieve "random range in a circle", I would have to make the circle range from a rect range myself?

 

[Ghan]

This might be a weird way of doing it....

Center a rect on your point.
Pick a random point in your rect.
If it's X distance away or less from your point, go with it.
Else pick a new point....

 

[Chocobo]

Get middle of the circle, use a polar projection using a random offset between 0 and distance from the middle of circle to the range limit of circle, and use a random angle.

Something like (there may be some errors) :

function RandomPointCircle takes real x, takes real y, takes real d returns Location
    return Location(x+GetRandomReal(0,d)*Cos(GetRandomReal(0,360)*3.14159/180.0, y+GetRandomReal(0,d)*Sin(GetRandomReal(0,360)*3.14159/180.0)
endfunction

 

[Rheias]

function RandomPointInCircle takes point p, real r returns location
    return PolarProjectionBJ(p,GetRandomReal(0,r),GetRandomReal(0,360))
endfunction

Edit: Ah, Chocobo beat me. Only the Location needs to be lowered case.

function RandomPointCircle takes real x, takes real y, takes real d returns location // HERE
    return Location(x+GetRandomReal(0,d)*Cos(GetRandomReal(0,360)*3.14159/180.0, y+GetRandomReal(0,d)*Sin(GetRandomReal(0,360)*3.14159/180.0)
endfunction

 

[waaaks!]

i think this is faster when coded correctly (if something is wrong) than Rheias, because polarprojectionbj still uses some cos and sin formulas

function RandomPointCircle takes real x, takes real y, takes real d returns Location
    return Location(x+GetRandomReal(0,d)*Cos(GetRandomReal(0,360)*3.14159/180.0, y+GetRandomReal(0,d)*Sin(GetRandomReal(0,360)*3.14159/180.0)
endfunction

but if chocobo coded it wrongly then use rheias' function

function RandomPointInCircle takes point p, real r returns point
    return PolarProjectionBJ(p,GetRandomReal(0,r),GetRandomReal(0,360))
endfunction

 

[Rheias]

Chocobo's code is better, no doubts, but if he wants to use location rather then x and y, the function is more comfortable.

 

[Kenoriga]

That is some tough formulas there o.o

What is real x and real y, the coordinates of the location? Then what about real d?

 

[waaaks!]

x and y is the center of ur target, and d is the distance on how far u will create the explosions

 

[Kenoriga]

Wow okay!

Thanks everyone for helping Responses were speedy! =D +rep+rep

 

[Doomhammer]

function RandomPointCircle takes real x, takes real y, takes real d returns Location
    return Location(x+GetRandomReal(0,d)*Cos(GetRandomReal(0,360)*3.14159/180.0, y+GetRandomReal(0,d)*Sin(GetRandomReal(0,360)*3.14159/180.0)
endfunction

this is not bad, but then I found some issues that could further be improved:
1) GetRandomReal(0,360)*3.14159/180.0 could be reduced by one operation to GetRandomReal(0,2)*3.14159
2) thinking about the geometric side, you'd only get a "circle" if the sin and cos are used on the same radius and the same angle which is your GetRandomReal(0,360)*3.14159/180.0; calling the randomizer twice will get two different randoms, and thus two different angles, and thus a random geometric shape, instead of random coordinates within the shape of a circle. this brings us to
3) 4 calls of randomizer where only 2 calls are necessary; they make your function slower than necessary

That's how an improved version could look like:

function RandomPointCircle takes real x, real y, real d returns location
    local real a=GetRandomReal(0,2)*3.14159
    set d=GetRandomReal(0,d)
    return Location(x+d*Cos(a), y+d*Sin(a))
endfunction

 

[Kenoriga]

^ the Randomizer running twice makes sense.

Heheh, thanks

 

[Vexorian]

When you use polar projections the random distribution is not uniform... (try it, and see how it is more likely to pick points in the center)

function RandomPointCircle takes real x, real y, real d returns location
    local real cx = GetRandomReal(-d,d)
    local real ty = SquareRoot(d*d-cx*cx)
    return Location(x+cx, y+ GetRandomReal(-ty,ty) )
endfunction

And one squareroot is arguably faster than a sin+cos .

Edit: fixed a mistake

 

[Kenoriga]

I think someone has to illustrate what each of the variables mean now, getting pretty confused here. Not that I really understood the first few sin and cos actually.

So... what is the SquareRoot used for in Vexorian's function?

 

[Doomhammer]

ok, let#s get to the basics:

to describe a circle with 2 variables x and y, you have two options:

1) have your circle described with trigonometric functions:
needed: radius, (angle in degrees from 0 to 360 or in radians from 0 to 2 pi )
then your circle can be described as:
x coordinate: x = cos ( angle )
y coordinate: y = sin ( angle )
That's the variation so far.

2) have your circle described with basic geometrics: needed: radius;
in rectangular triangles you can always follow the Pythagorean rule [cathetus ] a² + [cathetus ] b² = [hypotenuse] c². Going from there on you can deduct (or check out the circle of Thales for further reference and mind-connection between rectangles and circles), that a circle in coordinates can also be described as
x² + y² = r². The problem we get here is that for each of the variables we have 2 solutions: |x|=Sqr(r²-y²), and |y|=Sqr(r²-x²), so it's x and -x, and y and -y.
This fact is what Vexorian made use of to get random coordinates within a circle: see how he extented the randomizer into the negative. The advantage of his function is that it comes along without the use of trigonometric function calls, namely sin and cos, which are said to be rather slow (internal algorithms instead of direct calculation). With "it is said" I mean that the guys at wc3 have made some tests quite some time ago, and the trigonometric functions are indeed a bit slower than let's say the square-root call, but it's not dramatic after all. So that's basically it. Hope that helps.

links:
http://en.wikipedia.org/wiki/Trigonometry

 

[Kenoriga]

^ I knew the Pythagoras stuff and the trigonometry basics just in school in this semester... and that you almost enlightened me with the circle in coordinates stuff, but I just can't visualise how Pythagoras' Theorem works about with Vex's variables, cx and d.

 

[Chocobo]

^ I knew the Pythagoras stuff and the trigonometry basics just in school in this semester... and that you almost enlightened me with the circle in coordinates stuff, but I just can't visualise how Pythagoras' Theorem works about with Vex's variables, cx and d.

cx is random distance.
ty is the square root of d² - cx² (max distance and random distance : SquareRoot((d-cx)(d+cx)) if you think properly).
cx is added to x for the real x, y is added to a random number between -ty and ty.

 

[Kenoriga]

I still don't understand... I hope someone is willing to draw a diagram on what is going on about the variables in Vex's function, as I can't see how cx and d makes up a right-angled triangle.

Plus, I don't think Doomhammer's function works, because my random points end up like a thick circumference in a circle, with "varying radii"(points don't fit on the circumference exactly") and the top left corner of the map the middle of the circle. Either that, or the distances for random points are too great, I used 200.00 for real d, and it can go far above 1000 range from the original point.

 

[AceHart]

Red: cx
Green: ty
Blue: d

 

[Kenoriga]

Clears up everything! Therefore d is somewhat like a constant, and -d < cx < d... Then cx and ty are added, in a way that they will never go out of the circle...

Omg what a dumbass am I...! :banghead::banghead::banghead:

 

[TheDamien]

Vexorian's function is very clever, and I am no maths whiz, but it seems to me that the distribution of points would not be uniform or even rotationally symmetrical. Is this the case?