Subscribe via Email

Wednesday, April 27, 2016

morris_AIMA [#4]: Final Preparations ft.Factory Factories

This is a quick follow-up from the previous blog post designing the main simulation cycle. Here, we shall get into a bit more depth with the environment cycle process, and how the Vacuum World will be handled.

Environment Cycle 

Recall from Figure 1 from the previous post, the Simulation has 4 cycles. The first one is the Environment cycle which will look like this:

This cycling system will allow for all kinds of environmental types. For example a static environment (one that is not changing while the agent is deliberating), we just have generated items after all agents get to act. For a dynamic environment, we'd allow for having things change during the action phase, and perhaps nothing during the generate phase. In the Vacuum world coming up, I could have dirt spawned during the generate phase, while the Vacuum chooses to move in the act phase.
These three phases allow keeping the logic of an Environment cycle contained, and hence give us the ability to give a more solid definition of an environments properties.

Percepts & Actions

   Percepts will be objects in which are fed into an Agent during the act portion of an Environment cycle. A percept will be customized for an agent. For an agent named XAgent, the percent will be called XPercept.

     ex: VacuumAgent will take in a VacuumPercept

When an agent thinks, it will respond with an action. This action is very abstract for now, but in implementation will contain all info needed for the environment to interpret set action and perform it. I've seen many renditions of the AIMA Vacuum World online, in which the agent actually alters the world from inside its own class. Despite not having a whole lot of experience in simulation design, I disagree with this approach. I personally think it makes more sense to have the environment receive an agent's action and perform it.
     My argument for this is as follows:
     If you are to swing a bat in a dark room, and with your ears plugged, what will be the result?
       If the room is empty and you have much space, you'll simply spin a bit. If the room you're in is underwater, you will not have as much acceleration & velocity in the swing even if it's the exact same action. If the room has a bunch of children, you're likely going to hurt someone. These are all outcomes that will happen depending on the environment.
    In terms more related to AI. Given an Agent in an Unknown environment, the Agent is the one that doesn't know how it's actions will be received, thus, it doesn't control the environment through its actions, rather the environment does. 

With Agents and their Actions & Percepts, and the main Environment loop design; here is the final layout before I begin the Vacuum world project.
    The real beauty of this design, is that the Environment class contains the cycle method, in which calls act(), generate(), and updateResults(). The Environment doesn't know who implemented these abstract methods; but it knows that these methods must have been implemented if cycle() was called since you can't call it from Environment, as Environment is abstract. Huzzah!
    The final bit of elegance comes straight from the Factory.

Factory Factories

        Before taking the Object Orientation (comp2150) course I did just weeks ago, my setup for loading entities into an environment would have involved a ton of subclasses, each using the same main loading logic that

  •               parses input file
  •               checks type of entity
  •               inserts that entity into the environment

        The thing is, it's much more convenient to just have a superclass insert everything into the environment for you, the user shouldn't care. More importantly, an entity inserted into a 2-dimensional environment should look 2D while an Entity inserted into a 3D environment should be 3D, but the user shouldn't have to care about how it was generated.

At first, I decided to use a factory, called an EntityFactory. This would take a string input representing the entities name, and return that corresponding entity. The problem with this is that once you have 20+ Environments with 200+ types of Agents, you could at worst have 200*20 possible combinations to account for in your factory, which gets ridiculous. As said before, a 2D entity, say a Truck, should be rendered in its own factory for a 2DEnvironment while a 3D truck should be built in a 3DEnvironment's factory. We need a factory to make factories, it's the only logical conclusion (at least for what I know.)
     The TileEnvironment class now has an EntityFactoryFactory that takes in the environments name and returns a factory that makes all possible types of entities for that environment.

  Example: For a TileEnvironment, the factory would be built using:

   This would return a TileEntityFactory, and this factory will handle generating all tile entities, yet ALL the user needs to do, is know what entities can be supported in the environment (check documentation), and then insert! Factories are great!

What's Next? 

  Finally, after much deliberation. The VacuumWorld exercises will be implemented/discussed as outlined by the AIMA book. In the next post, I'll explain the environment being simulated, and show the results using my software. Hoping to have this implemented within a week before I leave for summer research in Taiwan, that way during the plane flights I can work on reading chapter 3 of the textbook, and doing more theory-based work. see: my research

Future Projections

Hoping my design has been solid enough to build this. If I've built this software correctly, I should be able to implement the VacuumWorld in less than a few hours. In the future, the bigger test will be to see if my software is modular and scales to the more complex exercises later on in the book! 

No comments:

Post a Comment

Please feel free to give feedback/criticism, or other suggestions! (be gentle)

Subscribe to Updates via Email