Random fails if `ma_scalar` is not double.

[TheExDeus]

I used a random function to generate color for curves. It seems that when I use: color=random_integer(16777216); I get only variations of dark blue. When I use this: color=random(0xFFFFFF); I get variations of yellow. To make it work I had to use this: color=random_integer(255) | (random_integer(255) << 8) | (random_integer(255) << 16) Technically all of the above should of worked. Also this returns only variations of blue: color=random_integer(c_white);

Example can be seen here: https://www.dropbox.com/s/2lgj9pyr0cf6cli/curves_example.gmk Press two times right to go the room where you can draw with the mouse. Left click create a point with random(0xFFFFFF);, while right click creates a point with the 3 times random solution. Previously all of them worked. Maybe this is because of the ma_scalar? But even before it got cast correctly. Maybe it is something to do with the color changes.

[RobertBColton]

Yes I was going to say ma_scalar before I finished reading your post, try removing the ma_scalar just to be sure.

Edit: Harri, you gonna test?

[TheExDeus]

I tested and it seems to be fine if ma_scalar is double instead of float. Can't really understand why. But I think math should be done in double by default anyway no?

float is usually 4 bytes, so it should hold 0xFFFFFF, but that would be in unsigned int form. In float it maybe couldn't.

[RobertBColton]

Josh has a resolution to this, it's also causing bugs elsewhere. I was just too lazy to pay attention to him. Something about namespaces. I give 0 shits about saving the changes I made, and yes I realize the defaults for all the STD math functions are double. So if you want to change them back be my guest, the math scalar is pointless imo. But to just save yourself some trouble you could just modify the Universal_System/scalar.h file so ma_scalar is defined as double instead.

Edit: Actually... "the default math scalar should be double" - JoshDreamland

So yah, just uncomment this line. https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Universal_System/scalar.h#L23

Edit 2: Heh, Josh already did it.

[TheExDeus]

Okay, so changing ma_scalar to double fixes this. Can close this now.

[JoshDreamland]

The point is that ma_scalar shouldn't have to be double for this to work. This issue could still use to be investigated.

[RobertBColton]

Ok, the original example he shared is now a 404, so I've recreated it: irandom-color-test.zip NOTE: You can now attach ZIP files to GitHub issues/comments using GitHub's CDN. I would recommend doing so in the future to prevent 404's occurring before an issue is properly addressed.

The example sets the room background color using one of the three methods he originally specified. Controls 1: irandom(16777216); 2: irandom($FFFFFF); 3: irandom(255) | (irandom(255) << 8) | (irandom(255) << 16); 4: irandom(c_white);

$ ./emake C:/Users/Owner/Desktop/GMGames/irandom-color-test.gmk -o /tmp/test.exe -r

With GM8 or ENIGMA, when ma_scalar is double, all 4 of the controls show variations of just random colors.

When ma_scalar is float, I get variations on blue for every input except 3. In the blue cases (1, 2, or 4), sometimes pure green and pure red will occur a single time.

@JoshDreamland I would like to see some kind of resolution to this and am willing to do the necessary testing, but I could use you to point me in the right direction.

From my own limited review, it seems it could be the fact that enigma::Random_Seed is int and not ma_scalar leading to a loss of precision: https://github.com/enigma-dev/enigma-dev/blob/05a3eef9609678af93bbdc0ddea7f2c148ad3a92/ENIGMAsystem/SHELL/Universal_System/mathnc.cpp#L375

[JoshDreamland]

Just so Robert remembers what I told him the problem was for the 21st and 22nd times: The values I use to generate random numbers come from the Delphi PRNG. Most are too big to fit in a float, and too small to randomize a quad. That implementation should always just use double, no matter what ma_scalar is.

[RobertBColton]

Closing as finally resolved. I downloaded the reproducible I created above and it works fine on the latest master whether ma_scalar is float or whether it's double. I get variations of red, blue, and green in all 4 cases. I guess we fixed it with #1706 which also fixed #1324. I believe it was fixed because we changed to Rusky's code which does not use the frac function, which was what caused the original issue here hence #1274 having been proposed by me.

I may still merge #1274 with a unit test though.

[RobertBColton]

Ok, I modified my test a little to be like Harri's original. I then did a hard reset prior to #1706 being merged, and the issue does come back. This means we did in fact resolve this bug with #1706!

Prior to Random Determinism Fix With Float Math Scalar

Master With Float Math Scalar