0x5f3759df and the fast inverse square root (2012) (h14s.p5r.org)

> ...math (in the sort of "doing stuff with functions in (R -> R), or multiplications/division")

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.

> Concurrency resolution issues neither.

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.

> Pretty much no sorting algorithm requires mathematical knowledge to work through, nor do many data structure algorithms. Concurrency resolution issues neither.

None of those requires _calculus_. I disagree about them not requiring maths.

Well, at some level almost everything can be described as using math. However, loads of software used by millions and netting millions can be and is written by people who most would describe as barely mathematically literate, from most sorts of business/accounting software (unless arithmetic is math) to device drivers to dating sites (where you could and will use heavyweight machine learning to match people but it kinda seems that having actual people on the site delivers 99.99% of the value regardless of said machine learning.)

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.

If you also make things happen on the click event of the button then I would say that counts.

I wrote it for the Parallax Propeller, which is slow at doing divisions - so I tried to keep those to a minimum (one, which isn't too bad).

AFAICT transmute would work: http://rustbyexample.com/staging/unsafe.html

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

EDIT2: Shorter, more readable version.