A) Does JMonkey Engine, in its latest stable version,
use internal bit manipulation to adjust the values
on float, double or Float, Double? Or in fact not?
B) If it does, it it possible for someone to give
me a brief outline of whereabouts such manipulations
are used within the library?
No. Not even sure why it would.
Just to make doubly sure,
Do any of the Java classes or interfaces that are the latest stable version of the JMonkeyEngine library use either the Java bit manipulation or bit shift operators, being the list of:
|, &, ^, ~, <<, >>,>>>
or any other Java code syntax technique, to access or manipulate base 10 or base 16 values inside the Java float, Float, or double,Double, in any way that presumes the current, exact (IEEE 754) mappings between binary base 2 and base 10, binary base 2 and base 16, that are within the Java floating point types, by means of access to the integral types and converting their data to one of the floating point types, and by those means but in the opposite direction?
Take a look at FastMath.convertHalfToFloat(). I think it fits the bill:
Is the FastMath class the only place in the whole library that uses bit and bit shift operators upon the present presumpt state of float and double, their IEEE 754 binary to decimal and hexadecimal state? Could I obtain what seems to be a better quality answer, such as the second answer on my discussion thread, here, please?
Why do you want to know?
Maybe that will help us answer appropriately.
I am doing some work which is reconsidering IEEE floating point itself, ie. consideration for options to alter the IEEE 754 binary floating point representation equation.
https://introcs.cs.princeton.edu/java/91float/
It will not react well to the present way of doing things when it comes to very reliant forms of code,
like bit manipulation and shifting to affect the contents of float,Float,double,Double. For these purposes, I need the ultimate example I can think of, which is the JMonkeyEngine library. I would need to know
if float and double bit manipulating and shifting only occurs in your Fast Math library, which I could avoid or re-do, because of its size. I encounter a big problem if you guys have used bit operating and shifting to
float and double, Float and Double, anywhere and everywhere in your library. The initial answer on this thread said no. I can avoid or redo FastMath.java myself, but I had been hoping that there are no fine bit accesses and changes to float and double in JMonkeyEngine other that that. Can someone in the know answer this, to confirm?
We are as “in the know” as you can get without searching through the source code line by line.
JME prefers to do actual math instead of hacks like floating point bit manipulation. It’s not worth it considering that only 0.1% of coders would even understand what it’s doing. I’m staunchly against such kludgy hacks.
Can I say with 100% certainty that JME does not do it “somewhere”? No. I don’t have the whole codebase memorized.
But if I saw it in a patch then I’d reject it.
Even the one example sgold points out is doing conversion from one type of float to another (using short as represenation). And there really is no way around that.
I think as a game developer you simply use bit shifting tech every day.
Below is the most famous function from Quake â…˘ Arena
float Q_rsqrt( float number )
{
long i;
float x2, y;
const float threeHalfs = 1.5f;
x2 = number * 0.5f;
y = number;
i = * ( long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - ( i >> 1 ); // What the fuck?
y = * ( float * ) &i;
y = y * ( threeHalfs - ( x2 * y * y ) ); // 1st iteration
// y = y * ( threeHalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed
return y;
}
I mean, Bit Shifting is part of game developing history.
It is very easy to check if bit shifting is used , simply read all .java files and check if there are “<<”">>" used. It will be a simple program.
and If you use a IDE, for example IEDA, you can SEARCH key words in all files to check it.
As I know our JME engine use lots of latest algorithms, like bit shifting and Matrix multiplication, so you have to be very carefully. I’m not sure if you have too check shaders as well.
btw:
You should also ask if Java TM use bit shift tech some where or not. and I think the answer is also Yes.
(If I’m not wrong, in the functions to switch between big and little endian part,and also MATH part. Sorry I can not remember which classes that was long ago I read the code)
This will not easily answer their question because you cannot directly bit shift a float in Java… but you could look for calls to Float.floatToIntBits and track the results around. JME only uses these for format conversions and hashing, though.
…of integer values.
JME does not use bit shifting or manipulation of floating point values. And if anyone can find a case then I will remove it personally.
Presumably the conversion from Java to GPU would already have to be done from whatever custom float format they use… but I don’t know.
Well, Carmack’s Fast Inverse Sqrt is actually present in FastMath 
/**
* Quickly estimate 1/sqrt(fValue).
*
* @param x the input value (≥0)
* @return an approximate value for 1/sqrt(x)
*/
public static float fastInvSqrt(float x) {
float halfX = 0.5f * x;
int i = Float.floatToIntBits(x); // get bits for floating value
i = 0x5f375a86 - (i >> 1); // gives initial guess y0
x = Float.intBitsToFloat(i); // convert bits back to float
x = x * (1.5f - halfX * x * x); // Newton step, repeating increases accuracy
return x;
}
First of all, i dont understand OP goal/intention.
Thats why i dont like even answer questions that can be easly answered by OP himself/herself.
(like earlier said, its easy to just search in code, noone memorize everything)
i would just like to know goal/intention of this question.
Is it about some new Java version issues or what? or even just tell if its research for something.
ya, the magic number “0x5f375a86”
I missed it in my first pass. Nothing in the engine uses it and we should deprecate it. It hasn’t been useful since Firefly was a new show.
Why do we must remove it ?
Isn’t this used in all game engines?
and
it is epic.
is this just about Float bit operations or more?
because as i remember even the Node system in JME also used bit check somewhere. (but it was similar to physics Groups)
About float operations, yup, its dangerous.
edit:
Also what you said interesting, im not sure how JNI or GPU convert Float values into C/GPU.
It’s from an era where sqrt was 200x more expensive than a regular multiply.
It relies on a very specific bit format and a very specific set of CPU conditions… all of which could change in the future to make it slower/worse/non-functional.
It is an approximation that is increasingly worse the more accuracy that you desire.
In Java it is almost always better to say what you mean and mean what you say because hotspot and the CPU upgrades can then make your program run faster with each passing year… rather than being stuck in 1999.
Integer bit checks. Integer bit checks are fine. Do integer bit checks as many times as you like.
FLOATING POINT bit fiddling is bad. Useful back in the day when we were all worried about y2k. Not so useful today.
I see now.
You said one interesting thing too.
Presumably the conversion from Java to GPU would already have to be done from whatever custom float format they use… but I don’t know.
im also not sure about JNI conversions(physics lets say), but didnt used floats there myself and just belive its fine. But yes, how is it done when it convert into GPU.