Some things just come back and bite you. The past few days I've felt the sting of things I've forgoten or ignored.
I'm horrid at math. Supposedly this is rare in computer science things but I just am. Through school I've generally programmed a calculator, which surprisingly I was allowed to get away with as somehow I knew the things by being able to program them, and just avoided those classes. College I jumped to a related degree that just plain had less math.
Last few days we needed some more graphical things set up. That required lines drawn between nearly the shortest points of some lines and some points, in other words everything I've been avoiding. The crash course has went alright, as this is not completely needed to be automated some corner cutting is needed but it is sad I've spent a lot of the past two days failing at math instead of being stuck on a programing problem. But I suppose that's life.
Showing posts with label work. Show all posts
Showing posts with label work. Show all posts
Tuesday, December 20, 2011
Saturday, November 26, 2011
Neural network and work
The past week and leading up to thanksgiving has been a odd at work. They have decided to send me down to Colorado for some training as the software and my workload was sorta put on hold with preparing for this, they don't want me to start a project I can't finish before I leave, and some coworkers taking time off causing the things I could do to be a little less even though I'm at the tail end of most of the project I have. So this left me with a lot of time to think as I document and cleaned up the code and I decided to on break take up setting up some neural networks on my thumb drive.
I won't go too far into neural networks explanation as there are wikis for this. I have a bit of story on my interest in neural networks and other such research based programing though. In college I sat in on a Genetic Algorithm class for fun. I had an interest in it as I actually did some of my own exploration of it in middle or highschool after reading something in some magazine. I was using game maker way back then and doing some messing around in that that actually had some minor results, most of them being the agents evolving to find holes in my test area or simulation. Either way back at the class I was sitting in I learned a lot about them and learned the basic feed forward neural network. I had taken to making one and trying some things that hadn't been done before to my knowledge and have the neural networks learn to play tic tac toe by "learning" off each other.
This wasn't typical neural network training as I was just using the neural network to preform the work and because the concept of them seemed neat. The workhorse was a genetic algorithm picking and mutating wining agents every generation. This didn't quite work, there was something akin to subspecies in the code that more or less played rock paper scissors with each other. lets say there was 3 groups (that's what I sorta came to believe watching the games) group A would try and win diagonally, group B would try and win horizontally, and group C would try and wind vertically. The game was more or less decided on the first piece as each group had a very entrenched first move after an A agent would place it's move a B agent was basically give up and just fill in the board in a pattern that let A win, a group C would continue as normal and end up blocking the A agent while winning. similar relationship between group C and B. This let each group get enough representation in the genetic algorithms choice of fittest agents to have them represented in the next generation, which just leads to the same not really solving the problem and keeping the agents in equilibrium.
I haven't touched this problem in years but I was thinking about it on work, and decided to get some neural networks programed on break. Took a week with a lot of messing around but I got the agents to solve XOR and inverting the input which is my standard for a working neural network as I don't know too much about standards for these. I also made a "produce key" feature which allows a string to be made based on the weights and thresholds of the agent. This is actually very important to what I'm going for. While not completely versed in the genetic algorithm or neural network programing I've seen that it's kind of been leaning far to a naturalistic side of survival of the fittest. The fittest agent is taken and it has offspring that may be exactly the same or slightly different than it which does work but seems to be inefficient and leads to cycles of not solving anything as I've seen before with the tic tac toe test. So with this key I'm able to keep a "gene pool" and see if the offspring is worthwhile of being put in the next generation in regards to solving the problem. I may be wrong on this but my learning years ago didn't go on about pruning the genepool and making sure every agent is unique. So right now I have a working neural network and a will to try and revisit an old experiment and possibly produce something of worthwhile research which is some fun I haven't had in programing in a while.
I won't go too far into neural networks explanation as there are wikis for this. I have a bit of story on my interest in neural networks and other such research based programing though. In college I sat in on a Genetic Algorithm class for fun. I had an interest in it as I actually did some of my own exploration of it in middle or highschool after reading something in some magazine. I was using game maker way back then and doing some messing around in that that actually had some minor results, most of them being the agents evolving to find holes in my test area or simulation. Either way back at the class I was sitting in I learned a lot about them and learned the basic feed forward neural network. I had taken to making one and trying some things that hadn't been done before to my knowledge and have the neural networks learn to play tic tac toe by "learning" off each other.
This wasn't typical neural network training as I was just using the neural network to preform the work and because the concept of them seemed neat. The workhorse was a genetic algorithm picking and mutating wining agents every generation. This didn't quite work, there was something akin to subspecies in the code that more or less played rock paper scissors with each other. lets say there was 3 groups (that's what I sorta came to believe watching the games) group A would try and win diagonally, group B would try and win horizontally, and group C would try and wind vertically. The game was more or less decided on the first piece as each group had a very entrenched first move after an A agent would place it's move a B agent was basically give up and just fill in the board in a pattern that let A win, a group C would continue as normal and end up blocking the A agent while winning. similar relationship between group C and B. This let each group get enough representation in the genetic algorithms choice of fittest agents to have them represented in the next generation, which just leads to the same not really solving the problem and keeping the agents in equilibrium.
I haven't touched this problem in years but I was thinking about it on work, and decided to get some neural networks programed on break. Took a week with a lot of messing around but I got the agents to solve XOR and inverting the input which is my standard for a working neural network as I don't know too much about standards for these. I also made a "produce key" feature which allows a string to be made based on the weights and thresholds of the agent. This is actually very important to what I'm going for. While not completely versed in the genetic algorithm or neural network programing I've seen that it's kind of been leaning far to a naturalistic side of survival of the fittest. The fittest agent is taken and it has offspring that may be exactly the same or slightly different than it which does work but seems to be inefficient and leads to cycles of not solving anything as I've seen before with the tic tac toe test. So with this key I'm able to keep a "gene pool" and see if the offspring is worthwhile of being put in the next generation in regards to solving the problem. I may be wrong on this but my learning years ago didn't go on about pruning the genepool and making sure every agent is unique. So right now I have a working neural network and a will to try and revisit an old experiment and possibly produce something of worthwhile research which is some fun I haven't had in programing in a while.
Thursday, November 17, 2011
Legacy and Lisp
I'm terrible at updating this but still feel I should, saddly it's a life one.
Works been going a bit slow so I've been asking the other guys on some project to do as "training/downtime" things. I almost regret it, I've herad about it being the back bone for some of the systems but I don't really want to learn it. It being Lisp.
I don't hate lisp, but I just don't like working with it. Python took quite a few things from it but one thing they didn't take was it's general syntax. I was annoyed with python indentation at the start but Lisp acts like the illegitimate offspring of C and assembly. Mostly for it's polish (not even reverse polish) approach to operate syntax. A quick example to show would be a while loop and it's set up.
(setq a 0)
(while (< a 20) (setq a (+ a 1))
;worthwhile stuff goes here!
(print a)
)
That's a lot of parenthesis for something that counts from 0 to 19. I get it and easily see it becoming maddening balancing them. Thankfully I can farm out a lot of it by setting variables to be functions and going from there. At least it got me learning.
Works been going a bit slow so I've been asking the other guys on some project to do as "training/downtime" things. I almost regret it, I've herad about it being the back bone for some of the systems but I don't really want to learn it. It being Lisp.
I don't hate lisp, but I just don't like working with it. Python took quite a few things from it but one thing they didn't take was it's general syntax. I was annoyed with python indentation at the start but Lisp acts like the illegitimate offspring of C and assembly. Mostly for it's polish (not even reverse polish) approach to operate syntax. A quick example to show would be a while loop and it's set up.
(setq a 0)
(while (< a 20) (setq a (+ a 1))
;worthwhile stuff goes here!
(print a)
)
That's a lot of parenthesis for something that counts from 0 to 19. I get it and easily see it becoming maddening balancing them. Thankfully I can farm out a lot of it by setting variables to be functions and going from there. At least it got me learning.
Wednesday, October 12, 2011
Pythonic and work
Work has been intersting. First the whole new environment and people to interact with. Second is the work itself which is a lot of python. So I'll rant on a little bit about it while I try to get the urge to figure out something more entertaining hopefully for this weekend.
I was left with a lot of code to "roll back" to an earlier version of a program that runs python script. Some clients get sick of updating you see and getting one of these clients caused the entire library of the person I was replacing to break. It seems he was sent to actually get trained from people who made the program we patch and make our own scripts for behind the scenes instead of fumbling through documentation.
Using some old cold snippets and newer code that works with a lot of guessing has lead to some finally functioning programs. Somewhat slow large and cumbersome programs but workings ones none the less. All this somewhat ugly and done as fast as I could work got me looking into efficiency and good writing style for python and I come across something called "pythonic".
Pythonic is deemed "what experienced python programers expect to see" which sounds snobish, but it seems under that surface is some good things. Though first lets show off a "pythonic" philosophy that's so used in development most programs in Idle will show it jsut by executing the line "import this". The little bit is as follows.
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
A lot of pythons implementation and development follows a lot of this if you look through it. The entire idea of white space indenting is defiantly for readability and some other things can easily be seen in there. Other things such as list comprehension and other advanced programing techniques you don't really discover till you look for them and those were the sort of things that were hitting me over the head. For the past two weeks I've learned a lot about programing in python and got more than a few tricks to use. Mostly called Idioms. While I feel it's bad style to link out of the website if you got a grasp of python heading over to here will show a good amount of them.
It also seems a lot of their techniques are a bit faster than my C/java learnings tend to get me to create. Hopefuly I'll put more of the idioms to use in teh future though for right now I'd settle for being able to import my own modules under the program I work with. You don't miss functions until you have to cut and paste while updating the same functions over and over again.
I was left with a lot of code to "roll back" to an earlier version of a program that runs python script. Some clients get sick of updating you see and getting one of these clients caused the entire library of the person I was replacing to break. It seems he was sent to actually get trained from people who made the program we patch and make our own scripts for behind the scenes instead of fumbling through documentation.
Using some old cold snippets and newer code that works with a lot of guessing has lead to some finally functioning programs. Somewhat slow large and cumbersome programs but workings ones none the less. All this somewhat ugly and done as fast as I could work got me looking into efficiency and good writing style for python and I come across something called "pythonic".
Pythonic is deemed "what experienced python programers expect to see" which sounds snobish, but it seems under that surface is some good things. Though first lets show off a "pythonic" philosophy that's so used in development most programs in Idle will show it jsut by executing the line "import this". The little bit is as follows.
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
A lot of pythons implementation and development follows a lot of this if you look through it. The entire idea of white space indenting is defiantly for readability and some other things can easily be seen in there. Other things such as list comprehension and other advanced programing techniques you don't really discover till you look for them and those were the sort of things that were hitting me over the head. For the past two weeks I've learned a lot about programing in python and got more than a few tricks to use. Mostly called Idioms. While I feel it's bad style to link out of the website if you got a grasp of python heading over to here will show a good amount of them.
It also seems a lot of their techniques are a bit faster than my C/java learnings tend to get me to create. Hopefuly I'll put more of the idioms to use in teh future though for right now I'd settle for being able to import my own modules under the program I work with. You don't miss functions until you have to cut and paste while updating the same functions over and over again.
Subscribe to:
Posts (Atom)