so, in response to the alternate routines page, I would like some insight into whether anyone thinks that these routines could be optimized further. I also am wondering if anyone thinks that the routine should become the new standard for custom menu and movement "fully optimized" status. I, being an optimization guru, just adore seeing programs go down in size. also, I am wondering if people prefer programs to be size or speed optimized. Because of the fact that it is possible to make objects move at speeds such that you can't recognize the delay, I tend to prefer size optimization.
please put 1 or 2 down for the three questions.
1. 1 for can be optimized, 2 for can't be optimized
2. 1 for should be accepted as standard, 2 for shouldn't
3. 1 for size, 2 for speed
First of all, I argue that the only thing really worth optimizing on that page is the one line of code where position is updated:
:min(8,max(1,A+sum(Δlist(K={25,34→A(the same code will obviously work for updating another coordinate). My reasoning is that while code for moving an object based on getKey is pretty universal, the framing isn't; I could have similar code for moving a pixel on the graph screen, moving a selection in a menu, or moving a cursor in a 3D grid.
Once we make that distinction, there's really only one question to be asked about the situation: is the object being moved in real-time, or is the program waiting for a key when the object isn't being moved? I think this determines whether the code should be optimized for size or speed. If the program will just use the extra speed to wait for the key longer, there's no point in optimizing that, and size should be the priority. In real-time, speed might be a higher priority. Of course, the best thing is optimizing for both ;-)
As for the first question, whether the code can be optimized further, the only improvement I see off the top of my head is a slight speed optimization (probably insignificant, but you never know):
min(8,max(1,A+max(Δlist(K={25,34→AOf course, there are specific cases which can be further optimized. For example, when moving an object sideways on the home screen, the likely fastest possible getKey check is to initialize L1 to {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 16} and then update the coordinate with
L₁(A+getKey→AApart from being fast, of course, this code has a number of faults (it will throw an error or react strangely to keys that aren't the left and right arrow), but I don't think the speed can be optimized further.
but do you guys think that the code is "better" than the other style getkey routines posted all over the site? because if you do then we should really start actually having what we say is fully optimized become fully optimized. for example, the movement in maps page would be out of date if this routine is to become the new standard.
btw, thanks for the max( optimization, even though it is only noticeable if you run the program for 300 iterations. And of course specific cases can be optimized much further.
