My Problem with Computer Programming

[SektionTen]

I would make a great computer programmer if it weren't for one thing, which I will get to later. For now, suffice it to say that I love computers and working with them, and my strongest strength when it comes to tech is that I often grasp hazy concepts with incredible ease. Not only that, but whenever I set my mind to solve cutting edge computer problems, I feel I have a lazer sharp accuracy in discerning exactly what about the problem needs to be redefined in order to reach a workable solution. This has lead to my developing new concepts in the computer programming field that would help with a whole host of problems.

The problem, however, is that while I can grasp the large, broad-brush concepts with superb ease, it is very difficult for me to work out and implement the tiny details. It is a horrowing action for me to sit down and try to actually write any pseudo code, because the itty bitty details tend to be so hard to extract from my mind that I end up getting incredibly frustrated and making very little progress.

Here's an example using a go playing program. The Game of "Go" is incredibly difficult for computers to play well, and even the best computers can be ritually slaughtered by incredibly weak players. The problem computers have with trying to play go is two fold: First, the sheer number of possibilities in any situation makes brute-force search completely impossible. And second, it is incredibly baroque to analyze a given situation on the board. Whereas a chess program can analyze a chess situation in much less than 50 lines of code, it often takes thousands of lines of code to analyze a ingle Go position.

My solution to this problem goes something like this: I use two functions when analyzing a go board, each function corresponding roughly to the task and processing method of the left and right hemispheres of the brain. The first function, which I will call Rfunc() simply records the exact position of all the pieces on the board and then uses pattern recognition algorithms to call previously processed board positions into memory. The basic function of Rfunc() is to look for similarities between the current board position and the all ready processed board positions in memory. Once a set of positions has been found, Rfunc() sends all the positions(incluidng the current one) into the second function, which I shall call Lfunc(). It's important to note that Lfunc deals with high level concepts such as thickness, the life or death of groups, territory, miai. The basic purpose of Lfunc() is to to look at the similiar positions and find differences between the current and previous positions on a high level scale. By finding the differences, Lfunc() will be able to subtract or add higher level analysis to the current board position and find out how The current game is different from previous games. Given that the previous games are all ready processed in high level, the amount of computer processing on the current game will become less and less the more games the computer plays, and also--The computer should be able to use it's processed games to adapt moves for the current position.

I can see all this very clearly in my mind. I know that this method solves the two big problems of Computer go, and I know that this method will allow the computer to get adaptively stronger the more it plays. But everytime I sit down to write a small function or some other snippet of psuedo code that might further my goal, I get so frustrated. It's like my mind is stuck on a full-focus lens, which let's me see the big picture well enough, but when it comes down to the gritty details, I feel so frustrated because they come out so blurry and I have to strain to pick them up!

Argh!  :nerd: