Well, what actually happens is that optimizations may cut a couple floating point operations (and probably more stuff). Most FP operations carry errors. These errors are small, but when they happen in a chain of operations the end result might be really off the expected mark. This isnt a precise example, but sqrt(3) and sqrt(sqrt(9)) might differ. The type of optimizations O3 perform may prune some operations and thus cause erratic behavior all over the simulation.
Erin has tested box2d without optimizations, so there is no guarantee it will work optimized (and it indeed doesnt).
EDIT: This may sound like a lie, but I swear it is true: An year ago I wrote an app that used Three20 (FB base) to show some pics. The final pic, depending on how you moved your finger, would detach from the view and roam around (instead of keeping its y axis fixed). After a few hours digging I found out (and this is true) that, on device, the order of the operations was causing the problem. In the end of the position calculations a 0.0001 was missing to sum up to the if value and so the y limit would break, letting the pic roam free on the screen instead of just over the x axis. To fix I moved a FP operation from the end to the top, and that fixed. I submitted a mail to the busy boy who used to take care of the codebase, but he didnt care to read. A couple months ago I noticed that even the damn fb app had the issue. Shame on him.
EDIT2: I searched my mailbox and found out the thing. This is odd...
Hi dude,
it seems TTScrollView has an issue that affects scrolling of the last view (and potential others, but I just found on the last view).
At line 744 or so you do:
CGFloat newWidth = -left + width + right;
CGFloat newHeight = (height/width) * newWidth;
There is a case in which you scroll left the last view and turn your thumb up (when NOT zooming). This will make the last view to slide up following your thumb. I found out that the floating point number calculated for newWidth should result in width (when using an inner view with aspect fit). The number resulting the calculation was slightly higher than width causing the scrollview to enter zoom mode (self.zoomed returning YES).
To fix that I changed the order of the calculation to reduce the chance for error. The new order:
CGFloat newWidth = -left + right + width;
CGFloat newHeight = (height/width) * newWidth;
On this piece the width is placed on the right. left & right will annulate each other and newWidth will be set to width correctly. This shouldn't affect other cases since the calculation is pretty much the same (just the order changes).
Let me know if you find this useful.
Thanks for such an awesome API,
Zaaroth
