Glad to hear it.
Yes, it still applies everywhere. There is little to no benefit in creating two separate methods for each array, it makes more sense to calculate the 4 digit number first then split it into two.
I'm reasonably good at mathematics, and have spent years doing it, which means I've had plenty of practice in spotting patterns. Here are the things I noticed (in order) which allowed me to deduce the "formula".
1) If you look at the list you notice that there are numbers and letters but the letters don't go past F, which is a clue that you are looking at hexadecimal.
2) Hexadecimal is in some sense a shorthand representation of binary, so this is a clue that you may need to convert things to binary at some point.
3) Some entries are two digits, but some are one. So we probably need to pad the digits to make them all 2 digits.
4) The first digit just cycles through 0,C,8,4 over and over again. A very clear pattern (suggesting that padding one digit numbers with 0 was the right thing to do).
5) In binary 0,C,8,4 is 0000, 1100, 1000, 0100. So the last two bits are always 0, suggesting that if look at other digits in binary maybe they have bits which are always 0 (or 1).
6) The second digit is always 0 or 1, which in binary is 0000, 0001, so the first three bits are always 0.
7) If we consider the first 2 digits as one number we have 5 bits in a row which are always 0. This is a clue that the digits should be considered as one big number (what happens to the bits at the end of one digit, appears to happen at the start of the bits of the next digit).
8 ) The pattern of 0 and 1 in the second digit is complicated. The fact that the first digit cycles every 4 suggests looking at it in groups of 4 might be a good idea.
9) In groups of 4 the second digit looks like 0110, 1001, 1001, 0110, 1001, 0110, ... Clearly there is a pattern, we only ever see groups which look like 0110 or 1001
10) Looking at the first number in every group of 4 we get 0110100110010110... This looks suspiciously like the same pattern as before. We can split it into groups of 4, and look at the first digit.
11) Again we see the same pattern, we can repeat step 10, to see the same pattern appear yet again.
12) Applying a lot of thought, you can deduce what is happening is that 0110 is occurring over and over but is sometimes getting flipped (0 is replaced by 1 and 1 by 0). If it was just 0110 over and over, the value would only depend on the last two binary bits of the row number n, i.e. f(bit 2 of n, bit 1 of n), where f(0,0) = 0, f(0,1) = 1, f(1,0) = 1, f(1,1) = 0. However, f(bit 2, bit 1) gets flipped according to the pattern 0110 1001 1001 0110 ... If this pattern was just 0110 0110 0110 over and over then it could be written as f(bit 4 of n, bit 3 of n). But it isn't 0110 over and over, it is 0110 with some flipping going on, in fact the flipping as you may start to guess depends on f(bit 6, bit 5) and f(bit 8, bit 7). Flipping in binary is often represented by XOR with the symbol [tex]\oplus[/tex]. So the pattern for the second digit is
f(bit 8, bit 7)[tex]\oplus[/tex]f(bit 6, bit 5)[tex]\oplus[/tex]f(bit 4, bit 3)[tex]\oplus[/tex]f(bit 2, bit 1)
At this point you may guess that the function f may actually have a simpler representation, namely XOR, so digit 2 is actually just
bit 8[tex]\oplus[/tex]bit 7[tex]\oplus[/tex]bit 6[tex]\oplus[/tex]bit 5[tex]\oplus[/tex]bit 4[tex]\oplus[/tex]bit 3[tex]\oplus[/tex]bit 2[tex]\oplus[/tex]bit 1
Which I called [tex]p(n)[/tex] in previous posts.
(Note that the group of 4 thing that we started out with was a bit of a red herring, this often happens when investigating maths. Often the guess we started with gets changed/ditched for something better.)
13) Next up is the 3rd digit. You should notice that it seems to be related to the second digit (again suggesting we are looking at one 4 digit number not 4 separate entities).
14) In fact for n between 0 and 31 the third digit matches the second digit with 1 being replaced by C. When n is between 32 and 63 it matches the second digit with 0,1 being replaced by 1,D. We can continue looking at groups of 32 seeing how 0,1 from the second digit gets mapped into the third digit. Clearly we need to investigate what is going on in binary.
15) In binary we see that the highest significant bit of the third digit matches precisely the lowest significant bit of the second digit (more evidence this is one giant 4 digit number).
16) The second highest significant bit of the third digit also appears to be p(n) but it doesn't quite work, it gets flipped when n is between 128 and 255, i.e. it is p(n)[tex]\oplus[/tex]bit 8 of n.
17) The last two bits of the third digit don't appear to have anything to do with p(n) but just keep cycling. They follow the pattern 0110 but stretched out over several rows, then repeated. Given we already know that 0110 is synonymous with XOR, we can guess that the pattern is bit 8 of n[tex]\oplus[/tex] bit 7 of n, and bit 7 of n[tex]\oplus[/tex]bit 6 of n.
18) Finally we look at the fourth digit. Given what we know, we should look at in binary and compare it with patterns we've seen occurring in other digits. It's not particularly difficult to see that the patterns continue and that the bits are computed as bit 6 of n[tex]\oplus[/tex]bit 5, then bit 5[tex]\oplus[/tex]bit 4, bit 4[tex]\oplus[/tex]bit 3, and finally bit 3[tex]\oplus[/tex]bit 2.
19) It seems a bit odd there is not a bit 2[tex]\oplus[/tex]bit 1, but if we revisit the first digit (that cycled 0,C,8,4), we see that the highest significant bit of the first digit is bit 2[tex]\oplus[/tex]bit 1, and the second highest bit is just bit 1 of n. It makes more sense to group these two bits of the first digit with the bits of the last digit.
20) Putting all this together gives us the following formulas for all 16 bits:
Bit 14 = 0
Bit 13 = 0
Bit 12 = 0
Bit 11 = 0
Bit 10 = 0
Bit 9 = p(n)
Bit 8 = p(n)
Bit 7 = p(n)[tex]\oplus[/tex] bit 8 of n
Bit 6 = bit 8 of n [tex]\oplus[/tex] bit 7 of n
Bit 5 = bit 7 of n [tex]\oplus[/tex] bit 6 of n
Bit 4 = bit 6 of n [tex]\oplus[/tex] bit 5 of n
Bit 3 = bit 5 of n [tex]\oplus[/tex] bit 4 of n
Bit 2 = bit 4 of n [tex]\oplus[/tex] bit 3 of n
Bit 1 = bit 3 of n [tex]\oplus[/tex] bit 2 of n
Bit 16 = bit 2 of n [tex]\oplus[/tex] bit 1 of n
Bit 15 = bit 1 of n
21) If you know how to do bit manipulation in programming then it is easy to see that we can get the various terms by doing things like multiplying p(n) by 7 left shifted by 8 (which 11100000000 in binary) to get the p(n) terms for bit 9, 8, and 7. XORing with n gets the left hand part for bits 6,5,4,3,2,1,16,15. XORing with n left shifted by 1, gets the right hand parts for bits 7,6,5,4,3,2,1,16. Then doing a left rotate on the last 2 bits puts bits 16 and 15 in the right place.
As you can see it was all just guessing, rewriting things in binary, trying to come up with patterns (if they don't work trying different ideas, guesses, patterns). It is a lot of hard work, and ultimately requires you to be good at pattern finding, and having knowledge and familiarity of binary. These things can not be taught quickly and easily, you need to do a lot of practising. The more you do the better you'll get, but it could take years. Even for someone like me who happened to spot the patterns quickly and happened to be fairly comfortable with binary and binary manipulations, it is still very time consuming to convert everything and try out patterns. There is no quick and easy magical way to do these things.
In general the pattern may just be too hard to spot, or require maths you are just not familiar with, in which case it will be impossible for you to work out. (If you don't know binary, hexadecimal, or XOR, there is almost no chance you'll spot the pattern in your particular case.) The more you know and the more experienced you are the better your chances, but there is no guarantee you will be able to work out the pattern.
Hopefully I've given you some insight into how to approach and think about these things.
Hope this helped,