Except the CPU will evaluate both if branches ahead of time. Heard about the meltdown thing? it’s exploiting this mechanism.
“if” statements are not slow on classic CPU architectures (that’s different on a GPU context though). I’d be surprised if a microbench results end up in favor of bit shift operations…
In a video game 95% of the time your CPU will be waiting for your GPU to finish to render a frame. You’re not going to have any gain from the 0.0001 nanosec you save using a bit shift instead of a if statement.
Also some of these methods are redundant with built in Java methods. getNegativeSign for example is basically Math.signum without the checks. It may be slightly faster, but again… what’s the global gain?
The Cycle method is basically a modulo operation, something like -> (index + 1) % (exclusiveMax - min) + min
Java has plenty of tools, it’s nice to be aware of them to not reinvent the wheel. Also a lot of very talented coders implemented and optimized java, and, even if there can be exceptions, most of the time a built in method will be faster or safer to use than anything you can think of.
A last word on FastMath. This class is very badly named, it’s not specially faster than the Math class, it just gives you convenient math operations on floats instead of doubles, and contains additional math methods that are not present in Math.
I realize that sound a lot dismissive, and I don’t want do discourage you from contributing to the engine. But you’ll find we are very picky to what’s added to core central classes usually, as Paul stated.