Updated Group and Individual Timelines

Graph Traversal

Graph Traversal Example:

Below is an example of a small instance of how the graph traversal will interact with the user (as currently visualized), as well as how edge weights will be updated to facilitate learning.

Example graph state where we’ve initially determined that the user drives a sedan and the symptom is that it wont start.  Our traversal begins at the “Won’t Start” node.

At each step of the traversal we define and display the probabilities of each leaf node that exists down the tree as the product of the edge weights in the shortest path to the leaf. As we are at the “Won’t Start” node, the probabilities would be for example:

Out of Gas: 36%

Spark Plugs Are Bad: 24%

Battery is Dead: 32%

Starter Motor is Bad: 8%

These values are updated at each step of traversal to give the user an updating list of probable problems.

Traversal:

We do a greedy graph search using the edge weights defined by the probabilities p. We reach the “Turn over?” mode at which point the traversal needs user input. The probabilities associated with the edges out from this node are built from past traversals, i.e. what users have expressed in the past. The application will ask the user for input at this node, specifically asking if the engine turns over when the key is turned. Lets assume that the user responds that it does indeed turn over. We then proceed to the transition state, a state that does not require user input and will proceed to the next state based on edge weights. In this simplified example we then reach the answer state “Out of Gas”.

At this point we have an answer for the user, their car may be out of gas. We would inform the user that this is probably the problem and perhaps provide a link to a video showing how to add gas to their vehicle. At this point, we will wait again for user input. Specifically we want the user to tell us if this was the problem. For this example let’s assume that the car was not out of gas, and we haven’t fixed the problem. The user informs the application of this, and traversal continues by going back to the transition state and proceeding to the next leaf node--the answer state “Spark Plugs Are Bad”.

We again recommend a DIY process or a mechanic to fix the problem and prompt the user for feedback. Let us assume that this did indeed fix the user’s vehicle. At this point we trace back the path and update the probabilities of each transition to reflect the new data.

This new graph structure represents a better informed graph and will be used for the future sedan queries and all graphs inheriting from the sedan graph.

Group Work Week 1

Here are some thoughts on how the group has been working together so far after one week.

Overall I have a very positive impression of our group dynamic. It seems that everyone is both responsive, as well as willing to work hard this semester. Additionally it seems like our personalities will fit well together to say nothing of our CS skill sets--which I believe complement each other's almost ideally.

I am happy with where I have landed in the division of labor and believe I will be able to make a significant and novel contribution to the project through my domain.

I am sure there will inevitably be rough spots in the coming semester regarding the group, but it is encouraging that these haven't cropped up in week one.

We have almost completed the logistics portion of the project set up (repositories, cloud resources, etc). I think this will make our group interactions more productive and less banal moving forward.

Generalized Division of Labor

Having had a small amount of time to speak with the other group members we have discussed our strengths and come up with a high-level and tentative division of labor:

Sonny:
Sonny has extensive experience with web design both functionally and aesthetically which is wonderful as this is probably my weakest area personally. For this reason Sonny is spearheading the front-end of the web design.

David:
David has agreed to pursue the "back-end" of the interface which as I understand it will act as a layer between the UI and the algorithmic logic of the program.

James:
James has experience through work with databases (another area of knowledge I woefully lack) and subsequently is going to be heading the database work for now.

Alan:
My particular strengths lie in the algorithmic side of CS and as such I believe I will be well suited to addressing the algorithmic logic of both the graph traversal as well as the learning portion of the application. The group has agreed to make this an area of focus for me.

Client Meeting 1

After having our first client meeting one thing has become abundantly clear. It is time to hammer out the specifics. Up to this point, through the proposal process and in the very short time we had as a group prior to the meeting, the whole project has been discussed in the abstract. At the time of the meeting we had talked about action plans to take steps to solidify the ideas but had not actually done so. I think we would've been in a better position to have a successful client meeting if we had discussed actual implementation and design.

This is encouraging though, because the details are currently being addressed, and I believe that implies our next client meeting will be much more successful. Additionally, with an attempt having been made at some amount of division of labor, we will be able to more personally contribute to the next meeting--rather than staring at each other awkwardly until James spoke.

Ranking Conundrum

We are about to rank the proposals so that we can be placed into groups. This is really exciting because after listening to all of the proposals the last three days there are a number of projects that I find extremely interesting! It will be a difficult ranking process, especially where I will rank my own project which for whatever reason has lost some of its luster.

I am torn here. On one hand I think I will perform better this semester if I am working on a project that I find very interesting. I will find it more natural to remain engaged in the face of this, the most difficult and busy semester of my educational career. On the other hand, if I rank my project first--ahead of some projects that, embarrassingly, interest me more--and it is chosen, then I will be ahead of the curve on the "impact" portion of my grade, a concept which looms as an incorporeal boogie-man in the bedroom closet that is my uncountable fears regarding my last semester as an undergraduate.

I have tough decisions ahead.

Proposal Writing, the Aftermath

The proposal writing process was an educational experience. The task of creating a formal proposal document was new to me. I've had experiencing writing technical papers about research, as well as experience writing legal documents when I was a paramedic, but never before have I had to sell an idea in a formal document. Especially difficult was the balance between the "real" portion and the "pretend" portion. The real portion of course being the parts of the proposal written with the context of a 12 week project in an undergraduate CS class, and the pretend portions being things like the budget and support sections which due to the context of the semester long class had to be fabricated.

Regardless of this difficulty I found the writing process to be very educational as well as a tool for focusing my intents and taking a much more formal look at what it was exactly that I was proposing--an experience that will change the way I view future projects.

Proposal Final Draft

The final draft of my proposal can be found at:

http://cs.unm.edu/~adkuntz/AlanKuntzProposalFinal.pdf

As always comments are more than welcome!

State Pattern, a Behavioral Design Pattern

One of the more intriguing design patterns I read about while perusing the software design pattern wiki was the state pattern in the category behavioral design patterns.

This pattern hinges on a characteristic of a programs objects called state. The state of an object (can be an object itself) is used to allow the original object to have multiple behaviors. Part or all of the behavior of the object is actually dependent on the state variables or state object of the original.

This simplifies the way in which the program has to handle these objects. The program need only update the state of the objects (although I suppose they could update it themselves in some implementations), and then treat the object the same regardless of the state and the object will adjust its behavior accordingly.

I find this design pattern to be particularly powerful in one main way--it allows for a large conceptual and programatic abstraction of each object that aligns well with my understanding of an "actor" model of conceptualization. Particularly, a program can be conceived and developed as a stage for the interaction of various actors (sometimes objects), and define the rules for the interactions of the actors which algorithmically results in desired behavior.

One area I have used a concept like this in the past is in experimenting with multi-agent robotic algorithms.

The state design pattern is particularly powerful in this setting, as we can allow the actors to perform various roles or behaviors based on the state of the system which allows for more complex behavior and interaction definitions.

I will definitely be considering the use of this pattern in the future.

Three Words

To describe my ideal project team in three words, I would say:

Excited, Dedicated, and Punctual

I chose these words because these are the characteristics I believe will facilitate the best experience for the group as well as the best final product.

Excited--I believe that a group that is excited about their work will inspire each other to be better group members and make the process less tedious and more enjoyable.

Dedicated--My ideal group is willing to work hard even when the project becomes difficult. A group dedicated to their work will be willing to add that extra effort to produce a high quality product.

Punctual--With such a narrow window of time to perform in, punctuality will be a high value commodity. Planning without punctuality of deliverables would be impossible, and as such punctuality deserves a place high on the list.


If I could include three more words I would include Personable, Proud, and Talented.
Person to person interaction skills are important in any kind of group setting as well as in a developer client situation. People who are proud of their work generally produce better work, as well as are better at selling it. Software Engineering seems like a difficult occupation, and as such I believe the best engineers will also possess some amount of talent.

Proposal

The proposal for my mobile application "Backpacker" is up and available at:

http://cs.unm.edu/~adkuntz/AlanKuntzCS460Proposal.pdf

Comments are most desired and welcome!

Try this URL instead:
http://www.cs.unm.edu/~adkuntz/AlanKuntzCS460Proposal.pdf