I've had a chance to converse with many of you over the week, be it in person, on irc, or via e-mail… covering a wide range of questions, quirks, and repository-related items.

For everyone's reference, as of the time I'm writing this message, the repository is at revision 29. So go and do an “svn update”, and expect to see your copy be brought up to 29 (or greater, as new commits as performed).

Two of the concerns I've received have been:

• not understanding the logic gate concepts
• not knowing what to do with respect to the project

I'll try to address both of these a little bit:

If you find yourself struggling with some of the concepts surrounding the logic gates we're implementing, I've found that in some cases it is a theoretical vs. practical barrier.

I would hope that everyone who has had questions on the logic gates has attempted to read up on them (by visiting wikipedia, by picking up a book– anyone who has taken discrete structures and still has their book, the chapter on “logic” and the chapter on “boolean logic” would be especially useful). I have some discrete math and digital logic books in the LAIR, along with some digital electronics books. Anyone is more than welcome to peruse through them in addition to any internet-based material (which there is plenty).

But one area that I can see people running into is putting that theory to practice.

For this, I'll be using the implemented AND class:

In logic, the 2-input AND has the following truth table:

   A B | X
  ----------
   0 0 | 0
   0 1 | 0
   1 0 | 0
   1 1 | 1

Where 1 is true, and 0 is false.

What has caused some confusion is you've ALWAYS been seeing AND represented like this, but when tasked with implementing it, how do we do it?

The trick is we need to remember that the truth table is a listing of ALL POSSIBLE combinations and values. The AND is not some quantum computing particle, it can only have exactly one of these states at any given time.

For example, when we play with our AND class, we actually define the inputs:

    AND myAnd;
    myAnd.set(true, false);
    cout << "true AND false is: " << myAnd.get() << endl;

In this case, we should see “false” be output… because we fed it true and false (1 and 0), which, when referencing the truth table above, 1 AND 0 is 0 (or false).

In that case, the other entries in the table don't matter, because they're not currently the situation in which we're using the AND. They are merely possible combinations that the AND can be used in (theoretical and actual… you actually cannot use a 2-input AND in any other combinations).

Hopefully that helps a little bit.

As any project kicks off, sometimes there will appear to be a scarcity of apparent tasks for some people to do. This has been the case here as well.

While there is still lots to do, sometimes figuring it out can be difficult.

At this moment, I can immediately see the following tasks in need of completion (many of which will allow for some immediate wiki documentation):

• xnor class implementation needs completion (a skeleton exists)
• xnor test application needs completion
• nor class implementation needs to be done
• nor test application needs completion
• #ifndef guards need to be implemented in the following header files:
  • or.h
  • nor.h (still needs to be created)
  • and.h
  • not.h
  • xor.h
  • xnor.h

If you have questions on what an #ifndef guard is… take a look at include/nand.h, where I have placed one… basically, it is the adding of the following two lines BEFORE ANYTHING ELSE in the file:

#ifndef _NAND_H
#define _NAND_H

and, the adding of the following line AFTER EVERYTHING ELSE in the file:

#endif

What it does is check for the existence of the symbol _NAND_H (by convention, we use ALL CAPS symbols, and prefix them with one or two underscores). If this _NAND_H symbol does not exist, we make it exist (via the #define preprocessor directive).

This prevents the include file from being included more than once (it can only be included once… any more than once and the compiler will generate “duplicate symbol declaration” errors). So this needs to be done with all our header files to make them more robust.

Note that we should make each symbol indicative of its filename… the or.h symbol should be _OR_H, and the not.h symbol should be _NOT_H. Okay?

A lot of these tasks are just replicating what already exists elsewhere in the project- don't worry, there will be plenty of time later for creative submissions. But throughout the semester will also present multiple opportunities for these housekeeping matters (and hey, they'll count nicely towards your weekly commit requirements).

We should also create a “TODO” section on the wiki page… which can be populated with tasks you all recognize as needing to be done, but have not yet implemented. That way, we can create a repository of implementation ideas that will help everyone out.

Also, if anyone wants to specifically tackle a particular task I mentioned above, consider even sending a message to the class mailing list, saying something like “I'm going to implement or.h”, etc. It'll also help count towards your weekly mailing list post requirement.

Hopefully that helps. Let me know if you have any other questions.