Of course it does, it is about square roots and inversions.
In most of the cases, in order to optimize an algorithm or solve a problem, mathematics will do it for you, and that ranges from simple arithmetic properties to base changing theorems in linear algebra.
You just can not tackle such subjects without expecting it to contain a fair bit of math .
It's not always weird bit-level arithmetic, but if you aren't using math at some level, you're not programming; you're just futzing around with a text editor.
There are counter-examples in every area, of course, it's just that the majority of programmers out there aren't great at math and are very much employable. And more often than not, people who're really great at math go to great lengths to avoid programming even when their work revolves around computers.
CS is a branch of math, of course, but this fact happily co-exists with all of the above.
Pretty much no sorting algorithm requires mathematical knowledge to work through, nor do many data structure algorithms. Concurrency resolution issues neither.
This is of course, so long as you consider math to be "do stuff with these numbers." Group theory and the like can help guide your results on a more abstract level.
EDIT: what I meant by this is the sort of "number-y" math that people usually mean when saying "warning: Math ahead". I realise that abstract modeling is also a part of mathematics, but that's not what people usually _mean_ when said in the context of what parent post was mentioning
This is not what math is. It's more what calculus is and math is a lot more than calculus. Most mathematics is not about numbers at all.
BTW: Interesting results about sorting algorithms (e.g. the lower bound of O(nlogn) complexity for comparison-based sorts) require maths (specifically combinatorics, permutations etc). Concurrency involves math, too. See the famous happens-before relationship which involves notions of sets (of executions), transitivity, partial ordering, etc.
I beg to differ on this one. Proving, or at least reasoning about, concurrent algorithm does involve wrapping your head around happened before model, logical clocks, state machines and such. Most of these concepts are grounded in discrete math; group theory, partial ordering and so on.
None of those requires _calculus_. I disagree about them not requiring maths.
I counted the cycles for you method and it comes to around 50 plus a conditional. Built in function should be around the same.
The fast inverse square root is based on the fact that the integer representation of a floating point number is a rough approximation of its logarithm.
So convert floating point to its integer representation. So now you have its approximate logarithm. Now take half of that and improve that with some Newton raphson.
Would something dirty like this be feasible in rust?
That's what's great about Rust, you can write unsafe code when you need it and it's isolated in `unsafe` blocks for easy auditing.
EDIT: Didn't test it too much, but looks like it works.
fn fast_inv_sqrt(x: f32) -> f32 {
let f: f32 = unsafe {
let i: i32 = std::mem::transmute(x);
std::mem::transmute(0x5f3759df - (i >> 1))
};
f * (1.5 - 0.5 * x * f * f)
}
println!("{}", fast_inv_sqrt(1.0));
//=> 0.998307
println!("{}", fast_inv_sqrt(255.0));
//=> 0.062517
This kind of system is beautiful, but there is no easy way to add and subtract.