May 3 2016, 12:42 pm
In response to Ter13
|
|
I'm not sure I follow; there's no traversal going on that I can see in that code. The . var is very fast to access.
|
That... Does not explain a few things that had led to believe me that ifs were not actually jumps.
|
Hence my confusion over MSO's results. The impact of the if() should be negligible, and the saved jump instruction over 500K iterations should be significant enough to show up in a profile.
|
Here's some general purpose things I live by at my job that aren't strictly code related.
-Giving variables good/descriptive names are as good as code commenting if not better in some cases. - If your choice is between slightly inefficient but simple code and efficient but complex code, go with the simple solution unless the performance actively becomes a problem. Clever, complex solutions are frustrating to debug if you're not the original author or have been away from the code for awhile. - Good use of #Define can speed code comprehension up a lot. |
In response to Techgamer
|
|
Techgamer wrote:
- Good use of #Define can speed code comprehension up a lot. Seconding this. I use preprocessor macros in pif_LongInt (and eventually in pif_BigInt) to differentiate two pieces of code that, while equivalent in function, have semantic differences. It also just makes it easier to grasp what's going on. Compare the Multiply() method from one of my classes before I used preprocessor macros, and just used raw code: var to after I used preprocessor macros, indicating what each operation is doing rather than just writing out the operation. var It's much clearer what's going on in the latter case than in the former (assuming you can make heads or tails of either of them, of course). |
Bitflags? Back in college I came up with this one, that you've probably seen in a few patterns on BYOND:
n & (n-1) I use it on BYOND as a check to see if a dir is diagonal; or more specifically, if it has more than 1 bit set. It's part of a more general set of bit twiddles: // remove the least significant bit from n These are bit twiddles I use for autojoining dirs. Going clockwise from north=1, northeast=2, etc. to northwest=128: // 16-state join (no diagonals) Each of those is about determining how the cardinal directions influence their neighbors. In 47-state joins, two adjacent cardinal dirs have to be set for the diagonal to matter. In 161-state, you only need either cardinal dir to join for the diagonal to matter. 82-state is like 161 where the inner and filled corners are identical. And in 16-state joining, diagonals are irrelevant. Also I'm fascinated by Gray codes, which are ways of reorganizing a number so that n and n+1 differ by only a single bit. Converting any integer to Gray code is easy: n ^= n >> 1 Converting back from Gray code to normal (in 16 bits): n ^= n >> 8 Gray codes come up in electrical engineering, where certain devices might use brushes that make contact with conductors on a ring that indicate different bits. Mechanically, it's possible for some of the brushes to advance to the next position before others, so in going from 7 to 8 you could read any number from 0 to 15. With a Gray code, 7 is expressed as 4 and 8 as 12, and 4 and 12 differ by only a single bit--so the only contact that matters is that one, and there's no chance for a (decoded) reading at that position other than 7 or 8. |