The abridged version of my log:Day 1:
Came back from a one-week break back to California. Got the boolean option for the program to work. Instead of specifying an Unknown as subject or object, and having the program pull up all the answers that fit, you can now specify both subject and object, and have the program return Yes or No in regards to whether your statement is true or false.Day 2:
Worked on getting the program to support having the relation as an unknown. This can be tricky, since we can run a whole gamut of scope of relationship complexity. I can think of at least three levels: only finding the relationship if it is direct, finding it through transitive closure (using the same slot-relationship), and finding the relationship allowing links through different slot-relationships. I settled on the second choice, and spent the day figuring out how to code this with as much optimization as I could think of, since this requires much more data searching than when either the subject or the object was the unknown. Unfortunately, the more optimization heuristics included, the nastier the code looked, so it took me the whole day to work on it, with more to follow.Day 3:
Debugged having relation as unknown. It actually wasn't as bad as I thought, since I ended up relying heavily on the boolean question option I'd just implemented. That does the meat of the operation. All I had to do was make sure it was getting the relations ok, and then I passed it as a boolean question. If the answer came back "Yes" then I rearranged the text and displayed that. Next direction to go: how to have multiple queries with more than one unknown, ie using previous unknowns as a constant in future queries.Day 4:
Trying to add code to support multiple complex queries, like "Heart has parts X. X contains Y." where X is the same in both queries, and Y is the answer we're looking for. This isn't that bad to do, except for the headache that probably in displaying the results, we want the intermediate node, ie. X. We probably want to make these operations cascadable, ie be able to use Y in another query like "Y is adjacent to Z." Setting up everything recursively so theoretically an unspecified number of queries can be linked together is a bit tricky, since we want to structurally preserve the intermediate nodes for display, but we do NOT want them in doing the actual query. I got a new variable to pop up in the subject/object tree whenever a query was made, with the thought that this variable (which represents the X previously mentioned) stands for all the results the query pulled up, but that was the easy part.Day 5:
Continued to work on trying to support multiple complex queries. I spent most of my time typing away in my log to try and get the conceptual data structure down (I think better when I when I'm writing it down) so I can sketch out the pseudo code, but I kept getting down to the pseudo code and realizing: "Wait! This is the WRONG IMPLEMENTATION! I really should be doing this!" Needless to say, it was a bit frustrating. On the up side, I'm feeling pretty good about my code that I finally did type up. It needs some debugging, but it looks somewhat promising.