On version 1.9.8 beta it said I think "IMP: Algodoo once again uses single precision float math (it was double during the earlier betas). This will speed up most things."
I am maybe now like a debugger for floats. I do not know why, but I am interested in floats all the time. So I sometimes make my own floats by using this formula: "2^exponent*(1+(mantissa/2^23))".
Yeah, but I use doubles mostly. But then converted to a float afterwards if there are issues with my projects.
I use Processing 3.2.1. Which supports doubles because it uses the programming language called 'Java'. But doubles take up more memory, so they are not used in functions except for 'text()'. Which supports it but with the string tag. Most of the functions that cannot be used in a double has to be converted to a float. Even the processing page for 'float' says "Floats are not precise!".
Yeah, but this was if a value was decimal "0.1". It would NOT equal that and pass right through it.
Because if you reduct 0.1 by 0.1 as decimal, then you would get something like this: "1.4901161e-9". And this is why I did this project.
And a floating point number is simply a 32 bit integer with they are like sectors for each one. If this binary number
"110000001 10000000 00000000 00000000" was converted to a float. It would say "3". If it was larger like this:
"100000100 10001000 00000000 00000000". Then THIS would say "392". That is how it is.
The real number of 1.0000001192092896 would look like this:
1.000000000000000000001 in full binary with a decimal point. But the number I said IS NOT decimal. If it is a float and EVEN doubles would round it down to "1".
If I said this number as binary with a decimal point "10110.111" That number would be "46.875".
If they STILL do not know, they should see the Wikipedia page for floats.
And a float in RAW form would be this:
"0 0000000 00000000000000000000000".
The first bit is the sign bit. That means if this is "1", It would be a negative value.
The second to ninth bits are exponent bits (8). These calculate to 0 to 255.
Because this is signed, It would be -126 to 127. And these are calculated by powers of 2 "Say like 2^3 for example".
The tenth to thirty-first bits are mantissa (23). These are values divided by the width of bits.
So the first bit will be added by "1.1920929e-7", The second will be added by "2.384195e-7" and so on.
If they wanna learn by messing with this system. They should go to
https://www.h-schmidt.net/FloatConverter. This is a 32-bit float system that you can use and mess around with.
No, I mean if it did, some values will go to "Infinity" because it goes past the largest finite value (3.4028235e38).
And a upgrade is 1 cookie per second at first, but multiplies the number 1 by 1.07 and repeats every time you buy again. But the value will be nonillions at the end. So this is why it will stop at 1,000.
And also, this was some of the "first" correct clicker games in Algobox.
It has a reactor which adds up the cookies by the cPs "cookies per second" value divided by 50. Why 50?, because 60 is uneven sometimes with the "6" trail.
The upgrades and the text is the ones with the most code.
