@Bortels Actually bitwise operations will come if, when, TLL adopts Lua 5.2. That will provide a very nice set of bitwise operators — along with a large number of under the hood improvements
That’s certainly one way to get them. I don’t know what barriers to entry there are for that upgrade (given the changes TLL has made). I do know there are drop-in libraries for 5.1 should 5.2 not be incoming…
Well, it is quite a bit of work exchanging 5.1 for 5.2 in such an environment. Plus there is a (slight) chance that user code may break. Maybe it is quite a good thing that the change has not been made yet, as the tuning of the gc in 5.2.0 has changed in a way that the memory usage increased. AFAIK for the upcoming 5.2.1 they’re back to the 5.1 behaviour.
Concerning bitwise operators, keep in mind that Codea compiles lua with floats for numbers (as opposed to doubles), so that integral values can only have 24 bits.
Dunno about float, but pretty sure it’s 32 bits. This works:
a = 327600
Print(a)
Update. Hmm, 65530 works, as well as 6553000. Bigger numbers go into scientific notation. So - not 32 bits either? Color me confused - I thought codea used 32 instead of 64 bits for speed reasons, going floating point would presumably be the opposite effect.
Codea uses 32 bit floats, which have a 24 bit mantissa. So while the space occupied by the number is 32 bits, you only have 24 bit mantissa.
so - just so I understand - the implication there is that regular Lua 5.1 uses 64 bit floats. Ok, makes sense.
yes, normally lua uses doubles - 64 bit floats.
I am actually a little curious why Codea is using 32 bit floats. iOS always handles FP math with doubles (though if the calculation is float to float then everything is done in single precision mode) — so there is no real performance advantage. It means less storage, but in real world terms it rarely has much impact.
@JockM I read that single precision floating point arithmetic is executed on the NEON unit in Cortex-A8 CPUs, rather than the VFP, and is substantially faster. I believe this is mostly important on iPad 1 — double precision arithmetic on iPad 2 and later is significantly improved.
@Simeon ah I see your logic. In the abstract that is true. It gets a little more complicated in real world conditions, since it will come down to how much floating point data can be kept in the CPU Cache and resused.
Unfortunately with the Lua VM in the way it becomes very hard to make any predictions of which kind of code would benefit more from single precision than where it would make little or no difference.
It would take a lot of benchmarking of difference scenarios to be sure one way or the other.