Off topic post ahead:
Taehl wrote:That vector stuff sounds neat. Would it be faster than using trig?
For normalizing, yes (see below). Also, your method of computing the angle and then use sin/cos on it is
essentially the same as normalizing the vector directly:
- vec_norm.png (21.95 KiB) Viewed 8341 times
Taehl wrote:Also to test my understanding, this would correctly normalize a list of numbers, yes?
Yes, and no: It normalizes the list by the sum of it's components. It would be the "correct" way to normalize, if you define the distance of two points to be the sum of absoulte differences of it's components (=
L1/Manhatten distance). If you use the
euclidian distance, was you'd normally do, then no.
Taehl wrote:Anyway, I tested that against trig. Trig was about 3 times as fast as the list-using normalizer, and about 1.5 times as fast as the table-using normalizer.
That's comparing apples with screwdrivers: they are completely different things. The table-normalizer as well as the vararg normalizer operates on more than two numbers (mathematically, you normalize an
n-dimensional vector vs. normalizing a two-dimensional vector). To have a more fair comparison, try this:
Code: Select all
function normalize(x,y)
local len = math.sqrt(x*x + y*y)
return x/len, y/len
end
function normalize_angle(x,y)
local alpha = math.atan2(x,y)
return math.cos(alpha), math.sin(alpha)
end
function profile(func, iterations)
math.randomseed(1) -- get same numbers
local start = os.clock()
for i=1,iterations do
-- normalize a random vector
func((math.random()*2 - 1) * 100, (math.random()*2 - 1) * 100)
end
print("time: ", os.clock() - start)
end
profile(normalize, 10000000) --> time: 5.51
profile(normalize_angle, 10000000) --> time: 10.59
The angle method appears to be nearly twice as slow and is at least in my opinion less readable than the vector notation (but that may be personal taste).