It's nearing the end of the semester, and the WiiSmartBoard has a semi-working prototype. However, it crashes due to memory errors and the way the images are controlled, as a group, my project group has decided that it would be best to take the working parts of the code, and use them to construct a multithreaded version of the smartboard so that it has better memory management,encapsulation, and abstraction.
Also, I've been thinking about a new data structure. Basically, trying to create a data structure based off of circles, and indexing by angles. this way a directional search could be created that would be able to search in some smart way. However as of right now, I'm imagining the overhead might not be worth the trade, and it's worst run time if implemented incorrectly could be on par with NP problems due to the connectivity of the omnidirectional graphs... its still a work in progress and more of a thought idea than anything else.
Monday, December 12, 2011
Thursday, December 1, 2011
Wii SmartBoard Calibration
Today, my project group working on creating a smartboard finally got the calibration code to work and run in such a way that the board waits for each point and doesnt just grab a bunch of points right away, also we got the board actually drawing points which is fantastic! Right now I've too many projects and homework to really update this project, but once the WiiBoard is done, a full paper is in the works, so look forward to that!
Wednesday, November 23, 2011
Papers available and project directions
So, under the suggestion of a database admin for the Green Mountain Coffee Roasters, I made myself a website. It's not the greatest thing and definitely still needs work. But within the projects page there are links to read the papers that I've written on a couple of the projects that I've talked about here.
I'm also thinking about redoing my Python Obstacle Avoidance program, either in python with cleaner code and a nice paper alongside of it to walk through the reasoning in the code itself, or to redo it in Matlab because I feel that Matlab's plotting functions could be of great use. Especially because I could make demo code that would show the algorithm working in real time and could animate a graph on screen to show what it is doing. I really like this idea, and despite moving away from Python, I feel like it will be really good. I'll either have to look up how to do lambda expressions in Matlab, or just throw away their use all together. (If you recall, I used lambda expressions to create functions that would return the value of y given an x, using an equation of a line that was the instance of the class itself.) They weren't necessary in the implementation and were mainly just me trying out something new.
The Smartboard is still coming along, and a paper is in the works for that one. I'm also going to probably be doing some small program in MIPS assembly pretty soon and will have to present it to a class I'm enrolled in, so that may make itself onto my website as well, and quite possibly this blog.
I'm also contemplating redoing the Budget Buddy in C# due to it's Visual Studio capabilities and how easy file IO is in C#, not to mention packaging into an exe. These are all things for the future, and hopefully I'll have time to do them!
Heres the URL to my website:
http://www.uvm.edu/~ejeldrid
Hope you all enjoy.
I'm also thinking about redoing my Python Obstacle Avoidance program, either in python with cleaner code and a nice paper alongside of it to walk through the reasoning in the code itself, or to redo it in Matlab because I feel that Matlab's plotting functions could be of great use. Especially because I could make demo code that would show the algorithm working in real time and could animate a graph on screen to show what it is doing. I really like this idea, and despite moving away from Python, I feel like it will be really good. I'll either have to look up how to do lambda expressions in Matlab, or just throw away their use all together. (If you recall, I used lambda expressions to create functions that would return the value of y given an x, using an equation of a line that was the instance of the class itself.) They weren't necessary in the implementation and were mainly just me trying out something new.
The Smartboard is still coming along, and a paper is in the works for that one. I'm also going to probably be doing some small program in MIPS assembly pretty soon and will have to present it to a class I'm enrolled in, so that may make itself onto my website as well, and quite possibly this blog.
I'm also contemplating redoing the Budget Buddy in C# due to it's Visual Studio capabilities and how easy file IO is in C#, not to mention packaging into an exe. These are all things for the future, and hopefully I'll have time to do them!
Heres the URL to my website:
http://www.uvm.edu/~ejeldrid
Hope you all enjoy.
Tuesday, November 22, 2011
Lambda Expressions in Python
Below is just a sample piece of code that I was playing with the other day, it was fun to mess with and interesting to see how the scope of the variables declared for the lambda expressions behaved. Mainly, that sometimes it seemed that variables declared within lambda expressions were accessible outside of what I thought their scope should be. This happened with the lambda expressions containing lambda expressions both expressions taking variables. It was a fun case study that got me away from all this serious project stuff I'm working on. And I figured I would share, so without further ado, here is the code: throw it into your favorite python IDE (command line, IDLE, eclipse) and run the show function and then play with it yourself. :)
#LAMBDA EXPRESSION TESTING
#Can you horribly abuse lambda expressions such that
#you dont have to actually create functions in a class?
class LamClass1:
def __init__(self,x,y,z):
self.x = x
self.y = y
self.z = z
self.getX = lambda: self.x
self.getY = lambda: self.y
self.getZ = lambda: self.z
self.norm = lambda a: a/(self.x+self.y+self.z)
self.xyLine = lambda m: (lambda n: n*m*self.x+self.y)
self.xzLine = lambda m: m*self.x+self.z
#nesting functions to return functions
self.makeLine = lambda m: lambda b: lambda x: (m*x+b)
#nesting arguments!
self.nesting = lambda m,b,x: (((self.makeLine(m))(b))(x))
#tupling it up
self.listF = lambda a,b,n: a+b,a*b,a-b,b-a,n
#This is a tuple you access to access a function how cool!
self.listT = lambda a,b: lambda n: (a+b)**n,lambda a,b: lambda n: (a-b)**n
self.shallowCopy = lambda: self
self.deepCopy = lambda: LamClass1(self.x,self.y,self.z)
self.tupleReturn = lambda a,b: (a,b)
self.funcList = lambda: (self.getX,self.getY,self.getZ,self.xyLine)
#you cant do multiple statements inside a lambda
#but you could nest everyline of code as a lambda being called and such
def show():
l = LamClass1(2,3,4)
#Standard gets but with lambda
l.getX()
l.getY()
l.getZ()
#An example of argument passing
f=l.xyLine(2)(3)
#Multi Function Computation:
f=l.listF[0](2,2,3)
#Example of how Scope Changes
f=l.listF[1]
print 'Global Scope of lambda variables'
print a,b,n
#you could write a =1 and then another print and watch it be strange
#Lambda Expression Variables are global, this could be bad
#Example of tupled functions
f=l.listT[0](1,2)(2) #(a+b)^n
f=l.listT[1](2,3)(3) #(a-b)^n
print a,b,n
#Notice how I have never declared a,b,n
#an example of shallowCopying and mutability
print 'Shallow Copy'
L2 = l.shallowCopy()
print 'l.x=',l.getX()
print 'L2.x=',L2.getX()
l.x = 3
print 'l.x = 3'
print 'L2.x=',L2.getX()
#an example of deep copy
L3 = l.deepCopy()
print 'Deep Copy'
print 'l.x=',l.getX()
print 'L3.x=',L3.getX()
l.x = 5
print 'l.x =',l.x
print 'L3.x=',L3.getX()
print 'Function List'
print 'l.funcList()[0]() -> getX()'
print l.funcList()[0]()
print 'l.funcList()[1]() -> getY()'
print l.funcList()[1]()
print 'l.funcList()[2]() -> getZ()'
print l.funcList()[2]()
print 'l.funcList()[3](2)(3) -> xyLine(2)(3)'
print l.funcList()[3](2)(3)
Monday, November 21, 2011
Wii Smartboard
The WiiSmartBoard that I'm working on with CS Crew is really coming along, we started working on it 2 days a week every week since early September. We're writing it in C# and using an open source library for interfacing with the Wiimote through bluetooth. When we first started working on it I went and looked through all the documentation for the WiiMote and found out which bits and bytes were returned from the wiimote and was ready to write my own assembly level parsing code. But then we were lucky enough to find the library that we did and I could focus on the actual concepts instead of the nitty gritty detail.
The cool thing is that we're going to attempt to implement a 2 and a half D flicking system to switch between "slides". I suppose I should talk a little bit more about the details.
We're using the Wiimote as a receiver for an infrared pen we built. We're drawing onto bitmaps on our GUI, but we also have buttons that will be able to be clicked. Each bitmap is a slide, stored inside of a lecture class my friend Scott and I created, when we save, we save a .lecture file that holds the information of the order of the slides to load, and saves the images into a subdirectory. It works really well because we're using two stacks to contain the bitmaps, so saving is as easy as popping and pushing them from one slide to the next and saving each one. And then when we load, we just load them in reverse order which is really the right way to do it because of the FILO structure of the stack.
I'm also writing up documentation on it and I'll definitely publish that onto my website.
The cool thing is that we're going to attempt to implement a 2 and a half D flicking system to switch between "slides". I suppose I should talk a little bit more about the details.
We're using the Wiimote as a receiver for an infrared pen we built. We're drawing onto bitmaps on our GUI, but we also have buttons that will be able to be clicked. Each bitmap is a slide, stored inside of a lecture class my friend Scott and I created, when we save, we save a .lecture file that holds the information of the order of the slides to load, and saves the images into a subdirectory. It works really well because we're using two stacks to contain the bitmaps, so saving is as easy as popping and pushing them from one slide to the next and saving each one. And then when we load, we just load them in reverse order which is really the right way to do it because of the FILO structure of the stack.
I'm also writing up documentation on it and I'll definitely publish that onto my website.
Tuesday, October 11, 2011
Proportions of a schema at time step t+1 with respect to mutation.
Firstly, I'd like to say that this is in no way linked to the Budget Project that has been on hold since my semester started again, this little gem comes from my own musings during a homework assignment for my evolutionary computation class.
Background knowledge for this piece of work:
Read up on Holland's Schema Theorem: Wikipedia Page on it
Understand how to multiply vectors, or at least take their dot product.
Moving on,
For a given population, at time step t, the number of schema's represented in the population is given by a vector of values between 0 and 1. We can compute the expected number of individuals from extending Holland's schema theorem with our own intuitive (and correct) terms. Doing this now, for a 2 bit problem:
(meaning that each schema in the population is only 2 bits long, and when I say schema here, I do not mean templates, I mean the actual members of the population of say, schema 00 or schema 11, NO wildcards.)
The probability of a schema surviving is the probability of both it's bits not being mutated. If we were mutating with probability Pm, then we can determine this survival rate as (1-Pm) squared.
The probability of a schema's complement (Think a standard not gate applied to all the bits, aka inverting, or flipping the bits, like twos complement but without the plus 1...) mutating into the given schema is the probability that it gets both bits flipped, or Pm squared.
The probability of terms representing half or partial complements being mutated is the probability of the bits matching the schema to not be mutated multiplied by the probability of the schema's non matching bits to be mutated into them. In short, (1-Pm)(Pm) and each term is raised by whatever bits match, and not match respectfully. (If this makes no sense, for a 2 bit problem, this would be (1-Pm)(Pm) or (Pm)(1-Pm) for the schema 01 and 10 if the desired schema was 00)
Now that we have those probabilities, we recognize that those probabilities multiplied by the number of the matching schema (not desired in most cases), and then summed, will give us the expected number of schema in the next generation at time t.
Now, my 'theorem' I suppose.
Let (1-Pm) = A, and (Pm)= B, o=number of bits, P= proportions of population
number of expected schema H at time t+1 = V((A+B)^n) dot P
Where V is a vector where each element i is the i-th term in the binomial expansion of (A+B)
We use the dot product to multiply the corresponding schema with the right probabilities and then tada, we're done. doing this for each schema in the population results in 2^n equations being calculated and the proportions of a generation at the next time step has been calculated.
Because this might not be very clear, due to my lack of knowledge if blogger supports latex or not, heres a bit more elaboration.
Expansions of a binomial are usually simplified, and then their coefficients make what is known as pascals triangle, however, in this theorem, the vector is composed of the UN-simplified version of the expansion, why? Because the proportions of the population can be different from one another, so you can't simply factor out the expansion, get the coefficients and multiply by the population now can you?
Also, the population vector goes from the desired schema up to the one previous to it. How? modulo arithmatic and mathematical trickery of course.
if we want schema 00, then our vector would be [00 01 10 11 ]. if we wanted 01? [01 00 11 10], what about 10? [10 11 00 01]
The goal of course of any population vector is to have the desired on the left, and the complement on the right, any bits between must correspond to their proper probability. This is the difficult part of any implementation, However consider this
000 A^3
001 A^2B
010 A^2B
011 AB^2
100 A^2B
101 AB^2
110 AB^2
111 B^3
Take the first, 000 as the desired bit string, and the other column as the probabilities assigned to it by the theorem, well we can notice that the number of complementary bits in the schema indicate how many times we should apply B, and the number of bits matching the schema apply to how many times A is multiplied by itself. Extrapolating from this, we could produce an implentation if we wanted to.
That is all.
Background knowledge for this piece of work:
Read up on Holland's Schema Theorem: Wikipedia Page on it
Understand how to multiply vectors, or at least take their dot product.
Moving on,
For a given population, at time step t, the number of schema's represented in the population is given by a vector of values between 0 and 1. We can compute the expected number of individuals from extending Holland's schema theorem with our own intuitive (and correct) terms. Doing this now, for a 2 bit problem:
(meaning that each schema in the population is only 2 bits long, and when I say schema here, I do not mean templates, I mean the actual members of the population of say, schema 00 or schema 11, NO wildcards.)
The probability of a schema surviving is the probability of both it's bits not being mutated. If we were mutating with probability Pm, then we can determine this survival rate as (1-Pm) squared.
The probability of a schema's complement (Think a standard not gate applied to all the bits, aka inverting, or flipping the bits, like twos complement but without the plus 1...) mutating into the given schema is the probability that it gets both bits flipped, or Pm squared.
The probability of terms representing half or partial complements being mutated is the probability of the bits matching the schema to not be mutated multiplied by the probability of the schema's non matching bits to be mutated into them. In short, (1-Pm)(Pm) and each term is raised by whatever bits match, and not match respectfully. (If this makes no sense, for a 2 bit problem, this would be (1-Pm)(Pm) or (Pm)(1-Pm) for the schema 01 and 10 if the desired schema was 00)
Now that we have those probabilities, we recognize that those probabilities multiplied by the number of the matching schema (not desired in most cases), and then summed, will give us the expected number of schema in the next generation at time t.
Now, my 'theorem' I suppose.
Let (1-Pm) = A, and (Pm)= B, o=number of bits, P= proportions of population
number of expected schema H at time t+1 = V((A+B)^n) dot P
Where V is a vector where each element i is the i-th term in the binomial expansion of (A+B)
We use the dot product to multiply the corresponding schema with the right probabilities and then tada, we're done. doing this for each schema in the population results in 2^n equations being calculated and the proportions of a generation at the next time step has been calculated.
Because this might not be very clear, due to my lack of knowledge if blogger supports latex or not, heres a bit more elaboration.
Expansions of a binomial are usually simplified, and then their coefficients make what is known as pascals triangle, however, in this theorem, the vector is composed of the UN-simplified version of the expansion, why? Because the proportions of the population can be different from one another, so you can't simply factor out the expansion, get the coefficients and multiply by the population now can you?
Also, the population vector goes from the desired schema up to the one previous to it. How? modulo arithmatic and mathematical trickery of course.
if we want schema 00, then our vector would be [00 01 10 11 ]. if we wanted 01? [01 00 11 10], what about 10? [10 11 00 01]
The goal of course of any population vector is to have the desired on the left, and the complement on the right, any bits between must correspond to their proper probability. This is the difficult part of any implementation, However consider this
000 A^3
001 A^2B
010 A^2B
011 AB^2
100 A^2B
101 AB^2
110 AB^2
111 B^3
Take the first, 000 as the desired bit string, and the other column as the probabilities assigned to it by the theorem, well we can notice that the number of complementary bits in the schema indicate how many times we should apply B, and the number of bits matching the schema apply to how many times A is multiplied by itself. Extrapolating from this, we could produce an implentation if we wanted to.
That is all.
Tuesday, August 23, 2011
Budget Buddy Progress!
This is the current progress of my budgeting program, the code and classes are made up for the accounts, checks, months, everything. The GUI and interlacing it with the underlying modules is all thats left. I've already started doing that, right now the 5 buttons at the top are the only things not working, as well as a few of the menu items.
On the to do list is:
The add items buttons and the other buttons associated with items and the main scroll pane that will hold the items that go into the budgeting for checks.
After thats done, making the GUI change when you select a different month and check and updating the panes that show information.
After that, the menu items such as saving and loading need to be done. After all of the main stuff, I just need to create the other panes such as the graphics and other things.
It will probably be another week or so before it's done.
Thursday, August 11, 2011
Budgeter
Hello Everyone!
I've decided on a project to do before I have to go back to school. I'm making a program that is effectively a smart checkbook. Only, right now I'm not making it to keep track of finances, but to budget them effectively.
Basically, When I get my checks from work, I open notepad and a calculator, enter my check amount into it, then slowly subtract out items as I enter them into the notepad document. So, basically I'm wrapping my setup into a program, and it seems like it's a good idea, mainly because 4 of my friends have taken an interest and have already asked to test my program once it's done. (As done as any program can get, aka release version that gets patches)
Right now I'm fighting between the urge to continue working on it, and the urge to go to bed, it is midnight, and I do have to get up at 7 tomorrow.... but when the mood takes one to code, you do not simply ignore it.
I've decided on a project to do before I have to go back to school. I'm making a program that is effectively a smart checkbook. Only, right now I'm not making it to keep track of finances, but to budget them effectively.
Basically, When I get my checks from work, I open notepad and a calculator, enter my check amount into it, then slowly subtract out items as I enter them into the notepad document. So, basically I'm wrapping my setup into a program, and it seems like it's a good idea, mainly because 4 of my friends have taken an interest and have already asked to test my program once it's done. (As done as any program can get, aka release version that gets patches)
Right now I'm fighting between the urge to continue working on it, and the urge to go to bed, it is midnight, and I do have to get up at 7 tomorrow.... but when the mood takes one to code, you do not simply ignore it.
Monday, August 8, 2011
Cluster is Done, next project
I made it about halfway through Cluster Swarm before getting to overwhelmed by work, friends, and readings. So I took a break from it, and never really got back to it. All the pieces are there, all the ideas, it's just a matter of putting the pieces together. However, I feel like my time would be better spent on other projects.
A few things I've considered, a Budgeting program that I could use to do my budgeting, (I do it in notepad right now), I could make it entirely in Java to make it transportable, I could make it customizable, and also include plenty of features that would be useful. I could model the Towers of Hanoi, and perhaps use what I've learned about genetic algorithms and evolutionary programming to evolve strategies and solutions to the towers. Although I'd probably restrict it to n <= 4 disks for the sake of managing bits. One way I thought about doing it was to use 30 bits to represent a solution to n=4 disks, each bit being able to be one of the three towers. I could initialize random bits to a few, then run it through a validity checker, essentially my fitness function, to see how well it does and to make sure it doesnt place a larger disk on a smaller disk. and then could add in how close to the optimal solution it was to determine it's fitness.
I also thought about representing the towers and their moves as a Grammar.
S -> aC | bC
A -> aB | aC
B -> bA | bC
C -> cA | cB | cƛ
ƛ -> null (end of moves)
You could simply build up possible moves, their validity would be checked by running them through a simulation of the towers, and then calculate how well they did. From their you could breed good solutions with other ones using crossover and mutation, or possibly use some type of neural net to 'train' a program to have tendancies to lean towards one change from one move to another. I'm not entirely sure on if I'm going to do this project yet or not. It's still up in the air.
A few things I've considered, a Budgeting program that I could use to do my budgeting, (I do it in notepad right now), I could make it entirely in Java to make it transportable, I could make it customizable, and also include plenty of features that would be useful. I could model the Towers of Hanoi, and perhaps use what I've learned about genetic algorithms and evolutionary programming to evolve strategies and solutions to the towers. Although I'd probably restrict it to n <= 4 disks for the sake of managing bits. One way I thought about doing it was to use 30 bits to represent a solution to n=4 disks, each bit being able to be one of the three towers. I could initialize random bits to a few, then run it through a validity checker, essentially my fitness function, to see how well it does and to make sure it doesnt place a larger disk on a smaller disk. and then could add in how close to the optimal solution it was to determine it's fitness.
I also thought about representing the towers and their moves as a Grammar.
S -> aC | bC
A -> aB | aC
B -> bA | bC
C -> cA | cB | cƛ
ƛ -> null (end of moves)
You could simply build up possible moves, their validity would be checked by running them through a simulation of the towers, and then calculate how well they did. From their you could breed good solutions with other ones using crossover and mutation, or possibly use some type of neural net to 'train' a program to have tendancies to lean towards one change from one move to another. I'm not entirely sure on if I'm going to do this project yet or not. It's still up in the air.
Thursday, June 16, 2011
Cluster Goal Driven complete
Just a quick update, the third phase of the cluster project is complete! Only one more phase (albeit large) remains! The documentation im writing up with it is up to date as well!
Wednesday, June 8, 2011
Cluster AI so far
I realize it has been a while since my last update, I blame this on my poor internet quality and working a full time job. However, Despite these time consuming things, I'm up to the Cluster with Obstacles, which you didn't know. It was quite wonderful how I implemented the obstacles, or at least I think so. I used a splay tree to do it :) coding a splay tree in C++ was pretty interesting, and working out the kinks was a bit time consuming, ubut after a days work and 3 different implementations, I had a working splay tree.
I just started working on Cluster Goal Driven a few days ago but haven't had time to really work on it too much yet, hopefully I can do that on sunday, we'll find out. Stay tuned for few and far between updates!
I just started working on Cluster Goal Driven a few days ago but haven't had time to really work on it too much yet, hopefully I can do that on sunday, we'll find out. Stay tuned for few and far between updates!
Sunday, May 8, 2011
Cluster Basic Complete
Like I said in my last post, I don't think is going to be a large project at all, but I hope I'm wrong.
So far, it has been as I predicted, the coding took me about 2-3 hours or so of actual coding and testing. I spent more time drinking water and talking to a friend online while I did the code then I actually coded, but it is done.
Cluster Basic is, well, basic. It avoids no obstacles, has no graph/grid structure it needs to index into because it has no obstacles, and it's easy enough to understand. The corner state of the box is there to be used, but isn't really used by the Cluster code. Because the Cluster doesn't actually care too much about where it's putting the members at. Because to it, the members are just a number stored in population that it checks against to make sure it has enough force to push with. You do need 2 members to push the box at all, even if 1 could do it by himself by force alone, in order to push in a horizontal or vertical line you require two members.
I'm going to type up a draft of a paper to accompany this project, and get it to the point where it adequately describes Cluster Basic, and put down all my ideas before I start working on Cluster with Obstacles.
So far, it has been as I predicted, the coding took me about 2-3 hours or so of actual coding and testing. I spent more time drinking water and talking to a friend online while I did the code then I actually coded, but it is done.
Cluster Basic is, well, basic. It avoids no obstacles, has no graph/grid structure it needs to index into because it has no obstacles, and it's easy enough to understand. The corner state of the box is there to be used, but isn't really used by the Cluster code. Because the Cluster doesn't actually care too much about where it's putting the members at. Because to it, the members are just a number stored in population that it checks against to make sure it has enough force to push with. You do need 2 members to push the box at all, even if 1 could do it by himself by force alone, in order to push in a horizontal or vertical line you require two members.
I'm going to type up a draft of a paper to accompany this project, and get it to the point where it adequately describes Cluster Basic, and put down all my ideas before I start working on Cluster with Obstacles.
Friday, May 6, 2011
New Project: Cluster
Alright, Cluser isn't a very good name so far, but I'll think of a better one. Anyway, the point is to have an object B (that is a box), and a goal point G, and a Cluster C of small workers that move the Box to the Goal by working together to rotate and push the box.
I've just started working on it, even though I did start working on something like it before, although I won't go into detail on it. Anyway, there are a few things I know I'm already going to do.
The box's state can be represented by an array that holds it's position and the amount of movement the box will move next step of the simulation, as well as the mass of the box. Also, if I want, I can create a boolean table that will tell whether a given part of the box is being pushed or not, this can be used by C to determine where to place it's members in order to push it. Makes sense?
Also, the Cluster will determine how to move the box based on the manhatten distance between it and the goal. So most of the time I expect the Box to be moving diagonally toward the goal. I'll create this project without obstacles first, but once I add in obstacles I'll probably move from an array to represent the space that C,B, and G live in to some type of Graph, and then I can start applying path finding algorithms (specfically Dijkstras A* algorithm) to the search space. Either that, or come up with my own way of dealing with it. (Minding that if I did want to use Graphs, obstacles would be nodes with HUGE weights/cost to traverse)
Alright, I've got the main ideas written in my notebook, and next I'll start coding up the classes and functions. I don't think this is going to be a very large project at all. Hopefully I'm wrong!
I've just started working on it, even though I did start working on something like it before, although I won't go into detail on it. Anyway, there are a few things I know I'm already going to do.
The box's state can be represented by an array that holds it's position and the amount of movement the box will move next step of the simulation, as well as the mass of the box. Also, if I want, I can create a boolean table that will tell whether a given part of the box is being pushed or not, this can be used by C to determine where to place it's members in order to push it. Makes sense?
Also, the Cluster will determine how to move the box based on the manhatten distance between it and the goal. So most of the time I expect the Box to be moving diagonally toward the goal. I'll create this project without obstacles first, but once I add in obstacles I'll probably move from an array to represent the space that C,B, and G live in to some type of Graph, and then I can start applying path finding algorithms (specfically Dijkstras A* algorithm) to the search space. Either that, or come up with my own way of dealing with it. (Minding that if I did want to use Graphs, obstacles would be nodes with HUGE weights/cost to traverse)
Alright, I've got the main ideas written in my notebook, and next I'll start coding up the classes and functions. I don't think this is going to be a very large project at all. Hopefully I'm wrong!
Thursday, May 5, 2011
Runtime Analysis On Turret3D
Since I have yet to decide on another project, I decided to do some runtime analysis on my program. At first, I looked at just the complexity of the overall algorithm, and figured it to be O(n) where n is the max lookahead value for the targeting algorithm, but since that literally took 2 seconds of thinking to do, I decided to figure out the more specific runtime, so I started checking on the complexity of the mathematical operations used within my code. To save myself the effort of typing it all up, and because blogger doesn't support latex embedded math typescripting (I believe), here's a screenshot of part of my paper that I wrote up.
If you do the math, the numbers won't add up quite correctly, the reason for the addition complexity in the actual runtime (the first line in the picture) is because of the boolean checks used to test if the loop should terminate or not.
The runtime is dominated by it's multiplications, as well as it's loop of course. So instead of just O(n) it's O(n * multiplications * trig). But, the addition and boolean constant time operations are negligible really, but they're included for specificity's sake.
I really want to create something involving AI, or using some Genetic Algorithms. But I have yet to figure out exactly what I want to do
If you do the math, the numbers won't add up quite correctly, the reason for the addition complexity in the actual runtime (the first line in the picture) is because of the boolean checks used to test if the loop should terminate or not.
The runtime is dominated by it's multiplications, as well as it's loop of course. So instead of just O(n) it's O(n * multiplications * trig). But, the addition and boolean constant time operations are negligible really, but they're included for specificity's sake.
I really want to create something involving AI, or using some Genetic Algorithms. But I have yet to figure out exactly what I want to do
Monday, April 25, 2011
Finished and Completed
Well, my 3-dimensional turret program has been finished. And I've even written up an 8 page document detailing the... well, details. It's available in pdf form, and if anyone would like a copy, all you've got to do is send me an email or leave a comment on this blog.
The real question is, what should I make next?
The real question is, what should I make next?
Tuesday, April 19, 2011
Working
I got my turret working. Or at least, it certainly seems it is working. See here:
The x axis is the x axis from the 3d vectors and the y value are the z height of the objects. Red is an object falling straight down at some position and green is the projectile fired. It seems like what I've done worked. But it doesn't make sense to me yet why.
What I'm confused about is how I fixed my problems I've had before. I changed the z velocity of the projectile to be v*sin(theta) and when calling an update to the projectile, instead of adding the position to the equation of the height I add the velocity instead. Somehow this works, but I do want to look into the mathematics before I do this. I'll update this project one more time if it turns out that this solution is not a fluke. And then start on a new one. I'm thinking of possibly coding up Tic Tac Toe to get my feet wet in some artificial intelligence.
Thursday, April 7, 2011
Math, a new plane to work on
 |
| Idea given to me by my Math friend Adam |
Ok he didn't say kerpow. but I'd like to imagine that's what his brain said when it thought all of that up. He's basically a math genius. Anyway though, what I'm now encountering as a difficulty, is how to switch from my ox,oy axes to my original coordinate system. ox corresponds to the line connecting them, so it must be the magnitude of the position vector. As far as converting the y axis of my new axis back, I'm not entirely sure. Although, I have a feeling that the converstion isn't neccesary for going back, only to converting the targets coordinates into the new system. But after that, the angle of elevation + the new angle given to me by my equations should give me the 'real angle' to fire on. And that will give me my velocity vector's z component. (it's x and y are calculated by the angle the turret faces on the XY plane. Anyway, I believe, that the y component of my target will be 0 in the ox,oy axes. Because the line connects both turret and target. And if you look at the drawing above, it's abundantly clear.
now that the details are, once again, possibly worked out. Time to code!
Been a little while
It's been a while since I've updated the running blog on the status of the 3d turret. Right now, I'm still working out a few bugs. But, I should have it figured out as soon as I find the time to do it. I've been very busy with schoolwork unfortunately. Not to mention trying to read library books on computer science before I have to return them. I did think of something today which I thought was worth posting about.
A problem I was running into was that I was measuring the distance traveled by the objects by their magnitude at a given time. This, while telling me if one will get there or not, is nice, but it doesn't actually tell me the difference between the actual distances they're traveling. When the projectile is fired, it travels in an arc of sorts, but the magnitude of it's vector only tells me how far away from the turret it is. Which is not what I want, I can use that information to see if the object is in range or not, but not for the estimation and leading part.
so, this is what I came up with: I'll have a running total for the distance traveled by the objects as oppose to a straight calculation based on it's magnitude. Since this will only introduce 2 more variables, I don't think this will effect the complexity of the algorithm too much either. Which is nice.
My main mistake in not doing this first, was that I was thinking too 2D ish for this 3D problem. But now I should be able to make some more progress!
A problem I was running into was that I was measuring the distance traveled by the objects by their magnitude at a given time. This, while telling me if one will get there or not, is nice, but it doesn't actually tell me the difference between the actual distances they're traveling. When the projectile is fired, it travels in an arc of sorts, but the magnitude of it's vector only tells me how far away from the turret it is. Which is not what I want, I can use that information to see if the object is in range or not, but not for the estimation and leading part.
so, this is what I came up with: I'll have a running total for the distance traveled by the objects as oppose to a straight calculation based on it's magnitude. Since this will only introduce 2 more variables, I don't think this will effect the complexity of the algorithm too much either. Which is nice.
Saturday, April 2, 2011
Turret 3D Estimation... still quite a work in progress
Been a bit since I've updated you guy's on my project.
Gravity has once again, proven to be the bane of my existence. Hopefully my math friend will get back to me on what he meant when we went off about some equations and such. Anyway though. I screwed up in an equation, one which I took from wikipedia, I accidently wrote a + where should have been a minus, and by the time I noticed, I had already moved and changed lines of code that I thought were wrong because of it. So yeah, it's kind of unfortunate. So, now I'm going to sit back, and think for a while on this problem.
Gosh, I wish I had noticed that + sooner...
Gravity has once again, proven to be the bane of my existence. Hopefully my math friend will get back to me on what he meant when we went off about some equations and such. Anyway though. I screwed up in an equation, one which I took from wikipedia, I accidently wrote a + where should have been a minus, and by the time I noticed, I had already moved and changed lines of code that I thought were wrong because of it. So yeah, it's kind of unfortunate. So, now I'm going to sit back, and think for a while on this problem.
Gosh, I wish I had noticed that + sooner...
Monday, March 28, 2011
Some more thoughts on my 3D Cone
Alright, so in case you can't tell, I've figured something very important out. The sphere of range around my turret isn't really a sphere. It's more of a cone.
The XY range plane is a sphere because it stretches out to 254.929 in all directions around the turret. Next, as I shrink that XY component of my vector, the heights I can hit will increase. I mentioned this near the end of my last post. I did some thinking, and I've come to believe that there is a directly... or inverse relationship between the two. if I target an object at the end of my XY plane, then the Z height of that object when I hit it will be 0. But If I move back a bit then I can hit a target a little farther up, a little inductive reasoning later and I see the max height of my projectile show up. When can I hit the object directly overhead of my turret? When it's XY plane coordinate is (0,0). So, by this logic, I get a cone. Because of this I'm unsure if my method of comparing magnitudes of the vectors will work this time. Rather, I think I should compare the components of the vector instead. Such that, if a XY component (I'm lumping the two together, so technically I'll still be using that magnitude) and a Z component make up a ratio that is greater than... can that be expressed as a ratio? The two are inversely proportional...
If the two components added together are more than 254 than I think it's out of range. Because say some object is 100 units out on the XY plane. Obviously in range XY wise. But if the height is 200 on this particular object? Then by my proportion It's out of range because 100+200 > 254. Also, I've worked out this example with the wonderful physics formula arctan(v^2+(or -) the square root of (v^4-g(gx^2+2yv^2))) all over gx where x and y are the distance times the cos and sin of the angle of elevation of the object. So I think I can use my proportion to test check to see if things will be out of range or not.
You might be thinking, why doesn't he just use the dang formula from wikipedia to figure it out? My answer? I need to compute these distances and calculations on estimated positions in t amounts of seconds and all that arctan square root lalala is expensive. And if a simple proportion can tell me if somethings out of range or not before I start doing calculations, I'll be quite happy. And thus, I am.
Oh, it was also my birthday yesterday
The XY range plane is a sphere because it stretches out to 254.929 in all directions around the turret. Next, as I shrink that XY component of my vector, the heights I can hit will increase. I mentioned this near the end of my last post. I did some thinking, and I've come to believe that there is a directly... or inverse relationship between the two. if I target an object at the end of my XY plane, then the Z height of that object when I hit it will be 0. But If I move back a bit then I can hit a target a little farther up, a little inductive reasoning later and I see the max height of my projectile show up. When can I hit the object directly overhead of my turret? When it's XY plane coordinate is (0,0). So, by this logic, I get a cone. Because of this I'm unsure if my method of comparing magnitudes of the vectors will work this time. Rather, I think I should compare the components of the vector instead. Such that, if a XY component (I'm lumping the two together, so technically I'll still be using that magnitude) and a Z component make up a ratio that is greater than... can that be expressed as a ratio? The two are inversely proportional...
If the two components added together are more than 254 than I think it's out of range. Because say some object is 100 units out on the XY plane. Obviously in range XY wise. But if the height is 200 on this particular object? Then by my proportion It's out of range because 100+200 > 254. Also, I've worked out this example with the wonderful physics formula arctan(v^2+(or -) the square root of (v^4-g(gx^2+2yv^2))) all over gx where x and y are the distance times the cos and sin of the angle of elevation of the object. So I think I can use my proportion to test check to see if things will be out of range or not.
You might be thinking, why doesn't he just use the dang formula from wikipedia to figure it out? My answer? I need to compute these distances and calculations on estimated positions in t amounts of seconds and all that arctan square root lalala is expensive. And if a simple proportion can tell me if somethings out of range or not before I start doing calculations, I'll be quite happy. And thus, I am.
Oh, it was also my birthday yesterday
Saturday, March 26, 2011
Maximum Height
Well, I started working out how to figure when to stop calculations because the target is out of range. And it seems complicated, to say the least.
First off, imagine a semi-sphere with a radius 254.929 units. This is basically the max distance for my turret, but the thing is, when I 'fire' a projectile straight up, if I increment my update function with a value of 1 second, it tells me that the projectile will reach maximum height around 6 or 7 seconds with a height of a little more than 270. This, is wrong. As I lower my increment function to say, .5, it shrinks to 265 or so, then to .25 it lowers to 260ish. Always around 6 or 7 seconds. but the thing is. The calculations performed should still give the same amount of height given the same amount of time. I don't understand why it's not. I noticed that as I lower the increment for time to update, the height approaches 254.929, but still. I can't use an approximation, or a bound for my max distance check if it changes by the time increment. It throws things off, as I'm sure you an understand.
So, what is wrong with this code?
First off, imagine a semi-sphere with a radius 254.929 units. This is basically the max distance for my turret, but the thing is, when I 'fire' a projectile straight up, if I increment my update function with a value of 1 second, it tells me that the projectile will reach maximum height around 6 or 7 seconds with a height of a little more than 270. This, is wrong. As I lower my increment function to say, .5, it shrinks to 265 or so, then to .25 it lowers to 260ish. Always around 6 or 7 seconds. but the thing is. The calculations performed should still give the same amount of height given the same amount of time. I don't understand why it's not. I noticed that as I lower the increment for time to update, the height approaches 254.929, but still. I can't use an approximation, or a bound for my max distance check if it changes by the time increment. It throws things off, as I'm sure you an understand.
So, what is wrong with this code?
//if you add in terminal velocity to the recalculation here first
pos = pos + vel * t;
pos.z = -.5*g*t*t + vel.z * t + pos.z;
if(pos.z <= 0 ){pos.z = 0; vel = Vector3D(0,0,0);} // no negative z's
vel.z = -g*t + vel.z;
//no exceeding maximum distance traveled
if(pos.x > maxD){pos.x = maxD;}
if(pos.y > maxD){pos.y = maxD;}
I don't know. The position is calculated by it's velocity and position vectors. The z position is recalculated using the height function I've found with physics. If the proj hits the ground it's velocity stops. the velocity of the z is affected by gravity by the equations of gravity. And then if the positions of x and y are greater than the maxD 254.929 then they are reset, because they should not be.
Anyway, the issue is in checking to see if the turret should even bother with trying to target an object. If the object is out of range than no attempt should be made. Basically I need to check to see if the object is within my sphere. But that's hard to do. I feel like I should be using arc trig functions to find a lenght of an arc that is whatever my arc length would be? I'm not sure.
In case you're wondering where some of the numbers come from. The 254.929 is the projectile fired at an angle of 45 degrees. Of course this only gives the max distance I can fire off into the XY plane. Making the base of my semiSphere. The maxHeight, is, I believe something along the lines of 254 as well. It would make sense... But then drawing that arc from that imaginary pole to the maxDistance line is... well, I don't know how to do it I suppose? Although...
The radius of my semiSphere is 254. So... 254 * sin theta will give me all the possible heights I can hit? I believe? Which would range from 0-254 if I'm not mistaken. I suppose, I could resolve the vector of the target into it's component vectors and then check those to make sure they're less than 254? But then what if an object is floating around at 254,254,2? Answer? I can't hit it! So it must have to do with the sum of those numbers I suppose? I've been trying to do it with magnitude but I'm not sure if that's correct because of this:
The magnitude of a vector(254,254,254) is 441.55 and without gravity, the distance a projectile can travel is 360.5 (velocity of the projectile (50 units /s) * the maxDistanceTime (7.21)) And if I compare these two, then there will be many cases where the function says: no can do. And I do agree with it in this example because 254,254,254 would be hovering waaay above. So, I suppose... I can hit something at (254,254,0) can I hit something at (0,254,254)? That would mean it's aligned with me on the x axis, but is lying out at the end of my range in the y... floating at 254z. That would be a no. It's mainly the Z that's the kicker, there must be some relationship between the XY components and the Z components. (254,254,0). I mean, 254-254 is 0, so is a bunch of other random stuff though. Halfway out, 128,128,128 I'm pretty sure I could hit. It's well within the XY range. If I do the math out: if it's about 221.7 out from the turret. which even though within the supposed maxD. I'm just still confused.
I think where I'm getting confused is that I keep thinking of the angle as being 45, and my range as being a sphere. When I think it might be more of a cone. Because I can move my Z angle up and down I can hit anywhere from 0-254 in height, but as the height gets higher, the target has to be closer. I just need to figure out that relationship first...
Grar math!
Friday, March 25, 2011
Gravity: Thou art a _ _ _ _ _
I've made progress in my 3D Turret program. I've (unfortunately for my poor brain) decided to include gravity in my calculations. Mainly because I'd prefer for my calculations to not shoot off into the sky without ever coming down again. Gravity's good for that sort of thing. Unfortunately, it's also good at making you do a bunch of calculations for determining maximum distance, terminal velocity, and a few other things. I did have a model that was close to what it should be, but the calculations it was making wasn't quite right. (Specifically it was 2 seconds later in hitting the ground than it should have been)
So I decided to peruse Wikipedia a little, specifically the free fall, projectile motion, and trajectory pages. They're plenty of nice equations ready to use. And although I was slightly saddened that I had admitted defeat in a way and just looked up the answer. The equation's were very similar to the ones I had devised. I had a big comment written at the top of my code that GRAVITY IS M/S^2, but for some reason I didn't square the time in my calculation for figuring the new z position of the projectile. But besides that, my equation was correct. My velocity updating line of code was correct though, so I was quite happy. From this figuring out the maximum distance was a matter of either running trials of different time increments or solving an equation. Or the third option not allowed by any homework ever done by a person. Look up a calculator on the internet that displays all the information when you enter the right numbers. I opted for the third approach and then tested it against my code by running the simulation to that time and making sure the z went to 0.
The only thing I'm still unsure of, is terminal velocity. Which is, unfortunately, rather annoying to figure out when you have no idea what the dimensions of your hypothetical projectile is. So I had to determine what I was actually firing (a small bullet with a mass of .04 kg is what I believe I decided on, with a cross section of 50mm^2, traveling through standard sea level air density (1.5 kg/m^3) with a drag coefficient of (.1) (a small ball by the examples I found, although it had a bullet (.3)) it gave a ridiculous terminal velocity (small that is not large) so I decided to go with my turret firing perfectly round projectiles.
So, after all that and 1 and a half cramped notebook pages later, I have an update position function I feel like I can rely on for my calculations.
Tommorow, after doing some trivial work (required course work for a required class which pertains to my major in no way), I'll start working on the estimation process and how it leads it's target through 3 dimensions. But for now, more reading Gödel, Escher, Bach by Douglas Hoftstadter (I'm a little more than halfway through the book )
So I decided to peruse Wikipedia a little, specifically the free fall, projectile motion, and trajectory pages. They're plenty of nice equations ready to use. And although I was slightly saddened that I had admitted defeat in a way and just looked up the answer. The equation's were very similar to the ones I had devised. I had a big comment written at the top of my code that GRAVITY IS M/S^2, but for some reason I didn't square the time in my calculation for figuring the new z position of the projectile. But besides that, my equation was correct. My velocity updating line of code was correct though, so I was quite happy. From this figuring out the maximum distance was a matter of either running trials of different time increments or solving an equation. Or the third option not allowed by any homework ever done by a person. Look up a calculator on the internet that displays all the information when you enter the right numbers. I opted for the third approach and then tested it against my code by running the simulation to that time and making sure the z went to 0.
The only thing I'm still unsure of, is terminal velocity. Which is, unfortunately, rather annoying to figure out when you have no idea what the dimensions of your hypothetical projectile is. So I had to determine what I was actually firing (a small bullet with a mass of .04 kg is what I believe I decided on, with a cross section of 50mm^2, traveling through standard sea level air density (1.5 kg/m^3) with a drag coefficient of (.1) (a small ball by the examples I found, although it had a bullet (.3)) it gave a ridiculous terminal velocity (small that is not large) so I decided to go with my turret firing perfectly round projectiles.
So, after all that and 1 and a half cramped notebook pages later, I have an update position function I feel like I can rely on for my calculations.
Tommorow, after doing some trivial work (required course work for a required class which pertains to my major in no way), I'll start working on the estimation process and how it leads it's target through 3 dimensions. But for now, more reading Gödel, Escher, Bach by Douglas Hoftstadter (I'm a little more than halfway through the book )
3Dimensional Turret Beginning
So I've just finished coding my 3d vector class. And now am trying to think of how I'm going to do this. I want to introduce gravity into the simulation, but this restricts the range of the turret, which is realistic, does make an infinite loop of checking for targets that are in range a strong probability. Also, I'm trying to think of how exactly to orientate and move the turret.
Heres some solutions I've come up with so far:
I could do all the calculations out like before, OR, since I made my previous 2D turret able to accept console output I could feed the coordinates into that, but that would only orientate the XY plane correctly, and even then, how would I grab the output from the execution? So, while it sparked my brain as a good idea at first, I think I'll ignore it a bit.
I think the hardest thing will be checking for gravity and other things of that nature. I know that in some science fictions, long range projectile weapons have to account for the curvature of the earth, but I don't think that will be my problem. So, to start off, I think the angle the turret's Z will be at is 45, aka the optimal distance angle, this could change a when aiming obviously. And now, before I was just using an arbituary 2 units / s for my projectile, but with the inclusion of gravity I think I've going to have to bump it up a bit to make the projectile move fast enough to stay airborne. I mean, let's face it, waiting 10 seconds for a projectile to hit a target is unrealistic. So I'll probably beef it up to say, 50 units / s or so and then just put the target out 150 or so units.
Since I've figured out the calculations to aim and lead in a 2d plane so I have reasonable confidence in extending it to the next plane up. It's just gravity and maximum distance I'm concerned about right now. Hmm.
I'll keep you updated
Heres some solutions I've come up with so far:
I could do all the calculations out like before, OR, since I made my previous 2D turret able to accept console output I could feed the coordinates into that, but that would only orientate the XY plane correctly, and even then, how would I grab the output from the execution? So, while it sparked my brain as a good idea at first, I think I'll ignore it a bit.
I think the hardest thing will be checking for gravity and other things of that nature. I know that in some science fictions, long range projectile weapons have to account for the curvature of the earth, but I don't think that will be my problem. So, to start off, I think the angle the turret's Z will be at is 45, aka the optimal distance angle, this could change a when aiming obviously. And now, before I was just using an arbituary 2 units / s for my projectile, but with the inclusion of gravity I think I've going to have to bump it up a bit to make the projectile move fast enough to stay airborne. I mean, let's face it, waiting 10 seconds for a projectile to hit a target is unrealistic. So I'll probably beef it up to say, 50 units / s or so and then just put the target out 150 or so units.
Since I've figured out the calculations to aim and lead in a 2d plane so I have reasonable confidence in extending it to the next plane up. It's just gravity and maximum distance I'm concerned about right now. Hmm.
I'll keep you updated
Wednesday, March 23, 2011
2D Vector Turret Program Complete (For the Most Part)
Phew!
I've been working since I last posted about the problem I ran into, and I have solved it. Using the good 'ol Tactics of visual representations, notebook, and my brain. It's kinda what I resort to for things like this. Anyway, I started by rewriting all my code to simplify it. The previous version I was working on had quite a phew things that could be simplified and made more efficient.
So heres a quick picture that describes what me, myself, and I (visual,notebook, and brain) came up with:
As you can see, the Fired projectile and the UFO (comeon, if something is unidentified, flying at you, and an object you want to shoot, what else do you call it? ) slowly get closer together as the seconds go by. In both the last and second to last stages of the output you can see it get extremely close and 'pass' the target. But because this 'pass' is so close, it means the UFO got nailed, because I doubt the thing we're trying to shoot is only .5 of a unit in radius.
So now, I think I may contemplate moving this into 3 Dimensions. First I'll have to rework my vector2d class into a 3d vector class. Or maybe I'll just look for source code online. Wish me luck!
I've been working since I last posted about the problem I ran into, and I have solved it. Using the good 'ol Tactics of visual representations, notebook, and my brain. It's kinda what I resort to for things like this. Anyway, I started by rewriting all my code to simplify it. The previous version I was working on had quite a phew things that could be simplified and made more efficient.
So heres a quick picture that describes what me, myself, and I (visual,notebook, and brain) came up with:
 |
| The thought process for the targeting function |
Once you reduce the vectors down to their magnitude and just work with the simplest of all physics equations (v=d/t) its actually quite simple. And I'm surprised I didn't think of it earlier. If only someone followed this blog, or posted comments, they could suggest things to me. Anyway, Heres the output of my program after running it:
______________________________________________________________________
Turret Theta: 2.26553 Turret Delay: 0.268347
Turret Vectr: 0.768221,-0.640184
Turret Armed: 0 Locked: 1 Fired: 1
Turret Estimation of UFO: 10.6101,-8.61008
UFO: Pos: 10.6101,-8.61008 Vel: 1,-1 (1.41421 units / s)
Fired Projectile: Pos: 9.74371,-8.11976 Vel: 1.53644,-1.28037 (2 units / s)
______________________________________________________________________
Turret Theta: 2.26553 Turret Delay: 0.268347
Turret Vectr: 0.768221,-0.640184
Turret Armed: 0 Locked: 1 Fired: 1
Turret Estimation of UFO: 11.8784,-9.87843
UFO: Pos: 11.8784,-9.87843 Vel: 1,-1 (1.41421 units / s)
Fired Projectile: Pos: 11.6925,-9.74371 Vel: 1.53644,-1.28037 (2 units / s)
______________________________________________________________________
Turret Theta: 2.26553 Turret Delay: 0.268347
Turret Vectr: 0.768221,-0.640184
Turret Armed: 0 Locked: 1 Fired: 1
Turret Estimation of UFO: 13.1468,-11.1468
UFO: Pos: 13.1468,-11.1468 Vel: 1,-1 (1.41421 units / s)
Fired Projectile: Pos: 13.6412,-11.3677 Vel: 1.53644,-1.28037 (2 units / s)
______________________________________________________________________
As you can see, the Fired projectile and the UFO (comeon, if something is unidentified, flying at you, and an object you want to shoot, what else do you call it? ) slowly get closer together as the seconds go by. In both the last and second to last stages of the output you can see it get extremely close and 'pass' the target. But because this 'pass' is so close, it means the UFO got nailed, because I doubt the thing we're trying to shoot is only .5 of a unit in radius.
So now, I think I may contemplate moving this into 3 Dimensions. First I'll have to rework my vector2d class into a 3d vector class. Or maybe I'll just look for source code online. Wish me luck!
Problem with the Y component of Vector
Heres a sample block of output from my program:
______________________________________________________________________
Projectile Position: 0 0
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 8.99512,0.00488001 Velocity- 0.707107,-0.707107
Pings: 1:6 2:5
______________________________________________________________________
Projectile Position: 1.99539 -0.135725
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 9.70223,-0.702227 Velocity- 0.707107,-0.707107
Pings: 1:7 2:6
______________________________________________________________________
Projectile Position: 3.99078 -0.271451
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 10.4093,-1.40933 Velocity- 0.707107,-0.707107
Pings: 1:8 2:7
______________________________________________________________________
Projectile Position: 5.98617 -0.407176
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 11.1164,-2.11644 Velocity- 0.707107,-0.707107
Pings: 1:9 2:8
______________________________________________________________________
Projectile Position: 7.98156 -0.542901
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 11.8235,-2.82355 Velocity- 0.707107,-0.707107
Pings: 1:10 2:9
______________________________________________________________________
Projectile Position: 9.97695 -0.678627
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 12.5307,-3.53065 Velocity- 0.707107,-0.707107
Pings: 1:11 2:10
______________________________________________________________________
Projectile Position: 11.9723 -0.814352
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 13.2378,-4.23776 Velocity- 0.707107,-0.707107
Pings: 1:12 2:11
______________________________________________________________________
Projectile Position: 13.9677 -0.950077
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 13.9449,-4.94487 Velocity- 0.707107,-0.707107
Pings: 1:13 2:12
______________________________________________________________________
______________________________________________________________________
Projectile Position: 0 0
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 8.99512,0.00488001 Velocity- 0.707107,-0.707107
Pings: 1:6 2:5
______________________________________________________________________
Projectile Position: 1.99539 -0.135725
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 9.70223,-0.702227 Velocity- 0.707107,-0.707107
Pings: 1:7 2:6
______________________________________________________________________
Projectile Position: 3.99078 -0.271451
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 10.4093,-1.40933 Velocity- 0.707107,-0.707107
Pings: 1:8 2:7
______________________________________________________________________
Projectile Position: 5.98617 -0.407176
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 11.1164,-2.11644 Velocity- 0.707107,-0.707107
Pings: 1:9 2:8
______________________________________________________________________
Projectile Position: 7.98156 -0.542901
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 11.8235,-2.82355 Velocity- 0.707107,-0.707107
Pings: 1:10 2:9
______________________________________________________________________
Projectile Position: 9.97695 -0.678627
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 12.5307,-3.53065 Velocity- 0.707107,-0.707107
Pings: 1:11 2:10
______________________________________________________________________
Projectile Position: 11.9723 -0.814352
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 13.2378,-4.23776 Velocity- 0.707107,-0.707107
Pings: 1:12 2:11
______________________________________________________________________
Projectile Position: 13.9677 -0.950077
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 13.9449,-4.94487 Velocity- 0.707107,-0.707107
Pings: 1:13 2:12
______________________________________________________________________
Now that you've scrolled through it here, heres the problem.
Projectile Position: 13.9677 -0.950077
Projectile Velocity: 1.99539 -0.135725
Turret Theta: -0.067915 Heading: 0.997695,-0.0678627
Turret Target Estimate: 8.28801,0.711987 Velocity: 0.707107,-0.707107
Object: Position- 13.9449,-4.94487 Velocity- 0.707107,-0.707107
Pings: 1:13 2:12
______________________________________________________________________
Do you see it? the boldfaced text? For some reason, the y velocity and such of my projectile isn't quite right. The X component is working perfectly, off by a hundreth of a unit? That's great considering rounding errors and such. But the y component is really not acceptable and I'm a bit of a loss as to why this is happening. Hopefully I can figure it out.
Monday, March 21, 2011
XY Velocity for a projectile? Solved for
Alright, So last I left off I had coded how to deal with projectiles moving in a strictly horizontal or vertical way. And was waiting on making the code for dealing with both velocities. At first I thought I would have to deal with some type of equation of two variables and solve form both of them using some complex business, but it turns out the method I use is at least 3x simpler than that.
So, first off I use the same method I've been using to get the time interval I should be using in my estimates. since I've described that in previous blogs I won't bother redefining it here. From that I get my hBound variable which is the top of said time interval. From here, I can compute how far the projectile will travel in the time given that it travels at a constant speed of 2.0 units. I then figure out the heading of my turret to aim at so it points at the targets estimated position after hBound time. From here all I need is the vector to give to the projectile as its x movement and y movement. So, using the cos of the gun's theta times the distance of the projectile as the x component and the sin of the guns theta times the distance of the projectile as the y component, I make up my vector. From this I have a triangle that may or may not overshoot the position if fired at the wrong time. So how do I figure my delay time out?
Simple, I take the magnitude of that vector I just made and divide by hBound to get how many units of time it will take to traverse this hypotenuse I've created. If that number is equal to the time it takes for the projectile to get to the estimated position then hoorah fire right away, weapons free, danger close. If its less than that then set up delay which is as simple as Time of the target - Time of the projectile. And the other situation, where T(proj) > T(target) never occurs because that would violate the work above with the whole hBound thing, theres a reason it's called the hBound you know. From here things get pretty simple.
since I have my heading, my delay time (if there is one) all that is left to do is to fire. Which is done by created anew object that has the position of the turret, the velocity vector is the heading vector of the turret(which has been normalized) multiplied by the velocitiy I know the projectile will travel (2.0 units), ahem. Tah-dah.
Now of course is where I fork myself, should I proceed to trying to create a 3d version of this? Or should I build up a simple library in DirectX to actually see whats going on instead of just numbers? Hmmm.
So, first off I use the same method I've been using to get the time interval I should be using in my estimates. since I've described that in previous blogs I won't bother redefining it here. From that I get my hBound variable which is the top of said time interval. From here, I can compute how far the projectile will travel in the time given that it travels at a constant speed of 2.0 units. I then figure out the heading of my turret to aim at so it points at the targets estimated position after hBound time. From here all I need is the vector to give to the projectile as its x movement and y movement. So, using the cos of the gun's theta times the distance of the projectile as the x component and the sin of the guns theta times the distance of the projectile as the y component, I make up my vector. From this I have a triangle that may or may not overshoot the position if fired at the wrong time. So how do I figure my delay time out?
Simple, I take the magnitude of that vector I just made and divide by hBound to get how many units of time it will take to traverse this hypotenuse I've created. If that number is equal to the time it takes for the projectile to get to the estimated position then hoorah fire right away, weapons free, danger close. If its less than that then set up delay which is as simple as Time of the target - Time of the projectile. And the other situation, where T(proj) > T(target) never occurs because that would violate the work above with the whole hBound thing, theres a reason it's called the hBound you know. From here things get pretty simple.
since I have my heading, my delay time (if there is one) all that is left to do is to fire. Which is done by created anew object that has the position of the turret, the velocity vector is the heading vector of the turret(which has been normalized) multiplied by the velocitiy I know the projectile will travel (2.0 units), ahem. Tah-dah.
Now of course is where I fork myself, should I proceed to trying to create a 3d version of this? Or should I build up a simple library in DirectX to actually see whats going on instead of just numbers? Hmmm.
Sunday, March 13, 2011
Horizontal Target Tracking
Woo!
Just finished coding the turret of my current project to lead a target thats moving only horizontally. It took me a while to wrap my head around alot of the numbers, and also I was accidentally using degrees to start off my turrets heading and not radians. Wups!
Anyway, so this is how I accomplish leading a target horizontally:
first using vector arithmatic and dot products and arcCos, we get the heading we'll be firing on.
then we account for possible time delays in order to account for differences in distance.
Heres the code: there is some stuff missing that is declared a bit above, such as getting the hBound which is the time where the distance the projectile will travel becomes greater (or equal to) than the distance the target will travel in the same amount of time. This is used so that we can lead the target. But because we lead it, we need to make sure to fire at the correct time in order to score a direct hit. So thats why we do some subtraction between the amount of distance and time and all that. Anyway: Heres the code:
if(target.velocity.y == 0 && target.velocity.x != 0){ //target only moves horizontally
//get the heading to fire on.
estMagPos = estMagPos + estMagVel*hBound;
Vector2D gt = (estMagPos - gun.position ).Normalize();
gun.theta -= acos(Dot(gt,gun.heading));
gun.heading = gt;
//now, account for leading and time delay
//hBound * vel = how much distance the proj will travel.
//Use the gun.theta and this to resolve the vector into it's components
//then the distance between the (hBound * vel) - x of target
double projd = hBound * vel;
projd = (cos(gun.theta ))*projd; // x distance of vector
double deltax = projd - estMagPos.x;
double waitT = deltax/vel;
gun.countdown = -waitT; //negation to make positive. no neg times
gun.locked = true;
std::cout << "Target Locked. Countdown Til Firing: " << gun.countdown << std::endl;
system("hal target lockd");
So, the calls to system and hal are just a speech program to say the string aloud.
Just finished coding the turret of my current project to lead a target thats moving only horizontally. It took me a while to wrap my head around alot of the numbers, and also I was accidentally using degrees to start off my turrets heading and not radians. Wups!
Anyway, so this is how I accomplish leading a target horizontally:
first using vector arithmatic and dot products and arcCos, we get the heading we'll be firing on.
then we account for possible time delays in order to account for differences in distance.
Heres the code: there is some stuff missing that is declared a bit above, such as getting the hBound which is the time where the distance the projectile will travel becomes greater (or equal to) than the distance the target will travel in the same amount of time. This is used so that we can lead the target. But because we lead it, we need to make sure to fire at the correct time in order to score a direct hit. So thats why we do some subtraction between the amount of distance and time and all that. Anyway: Heres the code:
if(target.velocity.y == 0 && target.velocity.x != 0){ //target only moves horizontally
//get the heading to fire on.
estMagPos = estMagPos + estMagVel*hBound;
Vector2D gt = (estMagPos - gun.position ).Normalize();
gun.theta -= acos(Dot(gt,gun.heading));
gun.heading = gt;
//now, account for leading and time delay
//hBound * vel = how much distance the proj will travel.
//Use the gun.theta and this to resolve the vector into it's components
//then the distance between the (hBound * vel) - x of target
double projd = hBound * vel;
projd = (cos(gun.theta ))*projd; // x distance of vector
double deltax = projd - estMagPos.x;
double waitT = deltax/vel;
gun.countdown = -waitT; //negation to make positive. no neg times
gun.locked = true;
std::cout << "Target Locked. Countdown Til Firing: " << gun.countdown << std::endl;
system("hal target lockd");
So, the calls to system and hal are just a speech program to say the string aloud.
Saturday, March 12, 2011
Getting a bit farther with my vectors
Which is, targeting and leading when the object is moving horizontally only. I've already worked out the case for the stationary target, which is the easiest, so now I'm working on the next easiest (I think) which is just horizontal movement.
this image right here shows how I was trying to think about zones and ranges of the turret.
normally, I would go into detail on more stuff. But I'm pressed for time right now, but once I get back to the world of internets, then I will gladly post and describe all the difficulties I've been having and how I've been solving them.
coming close of vacation.
So, my vacation is starting to come to a close. And I'm looking at what I expected from this vacation, and what I actually got.
I expected that I would, maybe not get laid, but find someone here who might be a friend who I could share attraction with. And maybe have a brief fling. I did kiss one of my friends, but it's normal for her and I to kiss. We're close, and the kissing really doesn't mean much. I kiss a few of my female friends on the cheeks when I see or leave them, this one I kiss on either the cheek or the lips. It's not a romantic kiss though, it's kind of like an italian kiss I suppose because it's more friendly than anything else. Anyway, getting off topic here aren't I? I expected to maybe cuddle with a specific friend and to admit some feelings for her. That didn't happen, because even though I saw her twice... maybe three times, it was always with a group. And since she invited people to events that we had planned on doing. I'm taking her hint that she just wants to be friends who tell each other they love each other and act like boyfriend girlfirend without the actual physical affection and only the virtual. It's just fake. I'm not a fake person, most of the time, and I don't especially enjoy fake. I do put on my smile for a good amount of the day, and I tend to shrug off my insecurities and sweep all my problems under an apathetic bed. I don't want a fake relationship, and I don't want a fake love, because after pretending for so long, it starts to feel like it might actually be something. I'm tired of that illusion. ... cough. I expected to see lots of friends and catch up on old times. That kind of happened, with one of my friends. The weird thing is, it was a friend who I am close with, but she was the only one who actually gave a damn to ask about me. Most of my conversations go something like this:
Hi, hi, how are you, and then they go on for a while, when they stop, they don't ask about me, so I further the conversation by asking them how their lives are going. And then the topic is them, them, them. I wish that for once or twice, maybe I could be the topic.
I think I'm mainly annoyed at the level of drama that occured while I was home. As noted by my previous rather depressing blogpost, my friend screwed up his relationship with his girl, and happened to do it with the girl who I was falling for. It's the reason I took a walk yesterday. Loaded the playlist I talked about onto my mp3 player and went for a walk in the crappy overcast weather. It was good, I got a good amount of thinking done. I was trying to figure out if I actually really like the girl enough to go for it, or if I'm more attracted to her as a friend. I didn't really figure too much out. But, I do think I'm attracted to her based on our common fuck ups. A'la she has baggage. Much in the same way I do. She still thinks about her big ex, and mentions him a lot. He was a big part of her life, so its no wonder a lot of things still remind her of him. And I think I like that about her, because I feel the same way about my ex from a long time ago. Everything still reminds me of her. Maybe that's why coming back home is kind of painful sometimes.
I expected more from my vacation, maybe some sunshine. I know I can't control the weather, but I've seen the sun once this entire week. It's frustrating when you want to go out and do fun things with friends, but they dont want to because the weather is shitty. It's rather annoyying and difficult.
I guess, when it comes down to it, I am looking forward to go back to VT, when I've talked to people over SMS, I've had to erase a part of a text that said: I only have x days before I go back home, multiple times, I guess I consider VT more home than this place to some extent. Maybe it's just nice to have a freshstart and not have all the people who already know you and stuff. Start new, find someone new, who hopefully wont fuck up my mind like my ex did.
I expected that I would, maybe not get laid, but find someone here who might be a friend who I could share attraction with. And maybe have a brief fling. I did kiss one of my friends, but it's normal for her and I to kiss. We're close, and the kissing really doesn't mean much. I kiss a few of my female friends on the cheeks when I see or leave them, this one I kiss on either the cheek or the lips. It's not a romantic kiss though, it's kind of like an italian kiss I suppose because it's more friendly than anything else. Anyway, getting off topic here aren't I? I expected to maybe cuddle with a specific friend and to admit some feelings for her. That didn't happen, because even though I saw her twice... maybe three times, it was always with a group. And since she invited people to events that we had planned on doing. I'm taking her hint that she just wants to be friends who tell each other they love each other and act like boyfriend girlfirend without the actual physical affection and only the virtual. It's just fake. I'm not a fake person, most of the time, and I don't especially enjoy fake. I do put on my smile for a good amount of the day, and I tend to shrug off my insecurities and sweep all my problems under an apathetic bed. I don't want a fake relationship, and I don't want a fake love, because after pretending for so long, it starts to feel like it might actually be something. I'm tired of that illusion. ... cough. I expected to see lots of friends and catch up on old times. That kind of happened, with one of my friends. The weird thing is, it was a friend who I am close with, but she was the only one who actually gave a damn to ask about me. Most of my conversations go something like this:
Hi, hi, how are you, and then they go on for a while, when they stop, they don't ask about me, so I further the conversation by asking them how their lives are going. And then the topic is them, them, them. I wish that for once or twice, maybe I could be the topic.
I think I'm mainly annoyed at the level of drama that occured while I was home. As noted by my previous rather depressing blogpost, my friend screwed up his relationship with his girl, and happened to do it with the girl who I was falling for. It's the reason I took a walk yesterday. Loaded the playlist I talked about onto my mp3 player and went for a walk in the crappy overcast weather. It was good, I got a good amount of thinking done. I was trying to figure out if I actually really like the girl enough to go for it, or if I'm more attracted to her as a friend. I didn't really figure too much out. But, I do think I'm attracted to her based on our common fuck ups. A'la she has baggage. Much in the same way I do. She still thinks about her big ex, and mentions him a lot. He was a big part of her life, so its no wonder a lot of things still remind her of him. And I think I like that about her, because I feel the same way about my ex from a long time ago. Everything still reminds me of her. Maybe that's why coming back home is kind of painful sometimes.
I expected more from my vacation, maybe some sunshine. I know I can't control the weather, but I've seen the sun once this entire week. It's frustrating when you want to go out and do fun things with friends, but they dont want to because the weather is shitty. It's rather annoyying and difficult.
I guess, when it comes down to it, I am looking forward to go back to VT, when I've talked to people over SMS, I've had to erase a part of a text that said: I only have x days before I go back home, multiple times, I guess I consider VT more home than this place to some extent. Maybe it's just nice to have a freshstart and not have all the people who already know you and stuff. Start new, find someone new, who hopefully wont fuck up my mind like my ex did.
Wednesday, March 9, 2011
Turret Estimation
Workin on my program some more:
So I've come up with a bit more code, and a few more interesting problems. I think I've figured out how to use my vectors correctly. I can use velocity vectors and position vectors to estimate the locations of objects. It's great.
The problem I've come up with is how to figure out where to rotate my turret to in order to fire. Because I have a few variables I need to keep track of, and keep in mind.
1. The projectiles statistics: the bullet or shell to be fired by the turret has a velocity vector and position vector. Once I move into a 3d space I may include a mass in here. But besides that, velocity is a straight float, why? Because I don't know which x y components to give the vector because I don't know the theta. so, a straight number like 2.5 m/s or something, allows me to estimate where to shoot the bullet. This will make sense once I describe my idea for this.
2. The target objects estimated path using the pings. This gives me a velocity vector and a position vector for the target.
3. The current heading, or theta of the turret.
So, my method, is briefly describe in the picture below.
So I've come up with a bit more code, and a few more interesting problems. I think I've figured out how to use my vectors correctly. I can use velocity vectors and position vectors to estimate the locations of objects. It's great.
The problem I've come up with is how to figure out where to rotate my turret to in order to fire. Because I have a few variables I need to keep track of, and keep in mind.
1. The projectiles statistics: the bullet or shell to be fired by the turret has a velocity vector and position vector. Once I move into a 3d space I may include a mass in here. But besides that, velocity is a straight float, why? Because I don't know which x y components to give the vector because I don't know the theta. so, a straight number like 2.5 m/s or something, allows me to estimate where to shoot the bullet. This will make sense once I describe my idea for this.
2. The target objects estimated path using the pings. This gives me a velocity vector and a position vector for the target.
3. The current heading, or theta of the turret.
So, my method, is briefly describe in the picture below.
I ran atrial of it last night, and it appeared to be working, but I do need to iron out some kinks in the simulation
Thursday, March 3, 2011
Radar Tracking Turret!
I came up with a new idea to code! It will probably take up a good chunk of my nights during spring break
I simple turret that tracks and fires at objects in its pinging field, in 2d space. Once I get that working, I'll think about working in 3d space.
Here are a couple of my sketches for ideas:
ok, so the first image is how the ping system will work. The second is how the pings data will be used to determine the vector of the object being targeted. and the last is how the turret will estimate where to fire.
So this is how I plan to do it. No code yet!
Have the turret object which will hold its own cordinates in its plane, its angle of firing and a pointer to its projectile loaded.
The projectile object will have a velocity and x,y cordinates. (once I move to 3d space it will have mass and other things)
The target will have an x,y and a velocity and theta for movement.
Then there is the collections object that will store all these things. this will be used by the pings sent out by the turret to let the turret know the location of the target object.
A few of the details still need to be worked out. But I've got enough that I can start a basic console prototype
I simple turret that tracks and fires at objects in its pinging field, in 2d space. Once I get that working, I'll think about working in 3d space.
Here are a couple of my sketches for ideas:
ok, so the first image is how the ping system will work. The second is how the pings data will be used to determine the vector of the object being targeted. and the last is how the turret will estimate where to fire.
So this is how I plan to do it. No code yet!
Have the turret object which will hold its own cordinates in its plane, its angle of firing and a pointer to its projectile loaded.
The projectile object will have a velocity and x,y cordinates. (once I move to 3d space it will have mass and other things)
The target will have an x,y and a velocity and theta for movement.
Then there is the collections object that will store all these things. this will be used by the pings sent out by the turret to let the turret know the location of the target object.
A few of the details still need to be worked out. But I've got enough that I can start a basic console prototype
Wednesday, March 2, 2011
OCaml Pattern Matching and etc.
I've a midterm tomorrow, in 3 classes. Anyway, calculus isn't hard. German will be alright. But programming languages, not that it will be hard, but just.... Ok so, we're allowed to use our notes we've taken in class as well as the daily summaries that he has given us in the past. Unfortunately, I've been taking all my notes in LaTeX on my computer. Which means I need to print them. Which means I need a printer, which means I needed to get my roommate to print it out. Which means I went and did something fun and asked him to do it. I came back a while later, and bam. Thirty Five Pages. THIRTY FIVE BLOODY PAGES of notes. Granted that's for the entire first half of this semester. But... It's computer paper! Formatted! To what looks like 10 size font. That's a lot of characters. Plenty of bits.
Anyway, besides that, I've just completed programming a reverse polish notation calculator in OCaml. The powers of pattern matching are spectacular. For anyone who has never programmed in Objective OCaml, I'd recommend attempting to. The type system is very nice, even if trying to figure out your error messages is a pain in the ass. I normally love my C++ but I do enjoy OCaml's elegance factor.
This semester seems like it's been quite a jump in what I've learned as far as CS goes. Before this semester I had no idea how to use php, javascript, server side includes, ocaml, unix file commands, batch file commands, and some directX code. Its a trend I would like to keep, this upward mobility of my learning. I like.
Anyway, besides that, I've just completed programming a reverse polish notation calculator in OCaml. The powers of pattern matching are spectacular. For anyone who has never programmed in Objective OCaml, I'd recommend attempting to. The type system is very nice, even if trying to figure out your error messages is a pain in the ass. I normally love my C++ but I do enjoy OCaml's elegance factor.
This semester seems like it's been quite a jump in what I've learned as far as CS goes. Before this semester I had no idea how to use php, javascript, server side includes, ocaml, unix file commands, batch file commands, and some directX code. Its a trend I would like to keep, this upward mobility of my learning. I like.
Wednesday, February 16, 2011
Binary Heap! splaying of emotions
So I've come to realize, after my data structures class today. That the method of modelling a Binary Tree with an Array that I was doing was in all actuality, a binary heap. Granted I came up with the methods of index access and such a week into my class when I didn't even know what a binary heap was, but still, I was on the right road. It's awesome. I'm decently happy with myself that I actually fundamentally understood and created a structure that was conceived of by brilliant minds who've come before me. And in fact, maybe even be alive today. It fills me with excitement for the future possibilities of my life.
Also, after discussing splay trees and studying their runtime and structure. I've determined that if someone would try to model the human emotion. They would use a splay tree. Because emotions that are accessed often, are often accessed again. For example, if someone is angry. Even if you cheer them up and calm them down, we all know it doesn't take much more to set them off again. And a person in a happy mood will be hard to get out of easily.
Another idea I had today was to write a python program that would export a picture of a binary tree. Using the height of the tree as it's measure, it would create a picture that would scale the tree so that it would fit neatly onto the picture. I've already a few ideas on how to do this. The cool thing I think, would be to have it read from a text file, specified to be in a specific traversal order, and then export the picture. Or perhaps even read from the text file and organize the data itself?
All these ideas, and so little time to actually implement them.
Oh! Also, my sister visited me and brought me a very nice 88 key keyboard. Using this I've begun learning Mandy by Barry Manilow. I'm 16 or so measure in now, 10-12 or which I can play quite comfortably. I do love making music!
The other day I started messing around with my webcam. Specifically on Video Feedback. Aka, pointing the webcam at it's output on the computer screen. Creating an infinite loop of awesome. I created a couple videos as well. There were some really cool effects.
Also, after discussing splay trees and studying their runtime and structure. I've determined that if someone would try to model the human emotion. They would use a splay tree. Because emotions that are accessed often, are often accessed again. For example, if someone is angry. Even if you cheer them up and calm them down, we all know it doesn't take much more to set them off again. And a person in a happy mood will be hard to get out of easily.
Another idea I had today was to write a python program that would export a picture of a binary tree. Using the height of the tree as it's measure, it would create a picture that would scale the tree so that it would fit neatly onto the picture. I've already a few ideas on how to do this. The cool thing I think, would be to have it read from a text file, specified to be in a specific traversal order, and then export the picture. Or perhaps even read from the text file and organize the data itself?
All these ideas, and so little time to actually implement them.
Oh! Also, my sister visited me and brought me a very nice 88 key keyboard. Using this I've begun learning Mandy by Barry Manilow. I'm 16 or so measure in now, 10-12 or which I can play quite comfortably. I do love making music!
Subscribe to:
Posts (Atom)