Java’s Sorted Collections and the Comparable and Comparator Interfaces

Java’s SortedSet interface and the classes that implement it (like TreeSet) will store a collection of objects that are sortable. In order to make a class sortable so that we can store it in a sorted collection, we have two choices:

  1. the sorted class can implement the Comparable interface
  2. we can pass a Comparator to the collection’s constructor.

1. Comparable Interface

This is probably the easiest way to make sure we can store objects in a sorting collection. The Comparable interface has a single method that we recognize from classes like String:

int compareTo(Object o)

This method must return an integer: 0 if this.equals(o), a negative int if this is less than o, and a positive int if this is greater than o. Using the Comparable interface defines what we call the “natural ordering” for a class. Here’s an example I wrote for a PTerm, which is a term in a polynomial:

public int compareTo( PTerm other )
{
    return other.power - power;
}

2. Comparator Interface

An interesting alternative is the Comparator interface. By using the Comparator interface we can define different comparators for a class if we need to order objects of a type in different ways. The Comparator interface contains two methods:

1. equals()
2. int compare(T o1, T o2).

Here’s the trick: the class we are comparing does NOT implement Comparator–we create a brand new class that implements it, and pass the implementing class to the collection’s constructor. Here’s an example:

public class TermComparator implements Comparator<PTerm>
{
    public int compare( PTerm term1, PTerm term2 )
    {
        return term2.getPower() - term1.getPower();
    }
}

In this case, we’re sorting the terms in the polynomial by the magnitude of the exponent, but we could have also decided to sort them by the magnitude of the coefficient.

We create the TreeSet like this:

    SortedSet<PTerm> polynomial = new TreeSet<PTerm>( new TermComparator() );

So now, whenever we add a term to the polynomial, the TreeSet will use the TermComparator to decide where it goes.

Don’t forget to override equals() in the PTerm class either:

public boolean equals( Object obj )
{
    if( obj == null )
        return false;
    if( getClass() != obj.getClass() )
        return false;
    PTerm other = (PTerm) obj;
    return power == other.power;
}

Share

AT91SAM7S256 aka the NXT Brain

The Lego MindStorms NXT Brick is controlled by a pair of Atmel microcontrollers:

The AT91SAM7S256 is part of an Atmel series of low pin-count Flash microcontrollers based on the 32-bit ARM7DMI ARM Thumb RISC processor. It features:

  • a maximum clock speed of 55 MHz (48 MHz in the NXT)
  • 64 KB of high-speed on-chip SRAM
  • 256 KB of integrated high-speed Flash memory
  • 11 peripheral DMA channels
  • 1 USB 2.0 (12 MB/s) device port
  • three 16-bit timers
  • four PWM controllers
  • 32 I/O pins
  • and requires a 3.0- to 3.6-volt power supply

The key facts here are:

  • The RISC–reduced instruction set architecture–is based on ARMv4T Von Neumann architecture. The ARM7DMI processor provides 0.9 MIPS (millions of instructions per second).
  • ARM–32-bit instruction set
  • Thumb–critical subset of the ARM 32-bit instruction set that has been encoded into a 16-bit instruction set
  • Flash memory–can be programmed in-system via the JTAG-ICE interface or through a parallel interface on a production programmer prior to mounting

The ARM7DML can execute both the high-performance 320bit ARM and high-density 16-bit Thumb instruction sets. The instruction sets are toggled by the processor as an ARM state or a Thumb state. In the ARM state, the 32-bit instructions are executed conditionally, while the 16-bit Thumb state instructions are a re-encoded subset of the ARM instruction set. The stegosaurus had a brain in its arse, and basically so does the NXT Brick. The AVR 8-bit ATmega48 microcontroller acts as a co-processor. Inside it there are:

  • 4 KB reprogrammable Flash program memory
  • 512 Byte SRAM
  • 256 Byte EEPROM
  • 8-channel, 10-bit AéD converter (TQGPéMLF)
  • 23 I/O pins
  • 4 MHz clock speed

Here’s the interesting thing. The ATmega48 is much smaller than the main AT91SAM7S256 processor, but this 8-bit microprocessor achieves almost 1 MIPS per MHz by executing its RISC instruction set in a single clock cycle.

Share

Artifact C-1: Cdump Utility (Command Prompt)

Description

The following description of the cdump program is based on the documentation of the hexdump utility:

NAME
cdump – ascii, hexadecimal, octal dump
SYNOPSIS
cdump [-bcC] [-nlength] [-soffset] [file]
DESCRIPTION
The cdump utility is a filter which displays the specified file, or the standard input, if no file is specified, in a user specified format.The options are as follows:

-b
One-byte octal display. Display the input offset in hexadecimal, followed by sixteen space-separated, three column, zero-filled, bytes of input data, in octal, per line.
-c
One-byte character display. Display the input offset in hexadecimal, followed by sixteen space-separated, three column, space-filled, characters of input data per line.
-C
Canonical hex+ASCII display. Display the input offset in hexadecimal, followed by sixteen space-separated, two column, hexadecimal bytes, followed by the same sixteen bytes in “character” format enclosed in ‘|’ characters.
-nlength
Interpret only length bytes of input. Note that there is no space between -n and length.
-soffset
Skip offset bytes from the beginning of the input. Note that there is no space between -s and offset.

The default is to interpret length & offset as decimal numbers. If they start with 0x (zero x) or 0X (zero X), they are interpreted as hexadecimal numbers; otherwise, if they start with 0 (zero), they are interpreted as octal numbers.

The default format, when neither -b, -c nor -C is specified, is to use one-byte hexadecimal display — the input offset is displayed in hexadecimal, followed by sixteen space-separated, two column, zero-filled, bytes of input data, in hexadecimal, per line.

Technical Knowledge

I learned and applied my knowledge of:

  • procedural programming in C
  • command line argument validation
  • basic I/O.

Skills Applied

I developed these skills while making this artifact:

  • programming with C
  • working with octal and hexadecimal number systems
  • managing complex user requirements.

Notes

I wrote this for BCIT’s COMP 2510, Procedural Programming in C, in July 2008.

We were required to write logic accommodating complex requirements including special cases like:

  • if the file to dump has size 0, there should be no output
  • if the number of bytes to skip is more than the number of bytes in the file, there should be no output
  • if the number of bytes to dump exceeds the number of bytes available, dumping stops at the end of the file

The following shows the -C option. The output format is somewhat different from the other cases.

$ cdump -C hello.o
00000000 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 01 00 03 00 01 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 c0 00 00 00 00 00 00 00 34 00 00 00 00 00 28 00 |........4.....(.|
00000030 0a 00 07 00 55 89 e5 83 ec 08 83 e4 f0 b8 00 00 |....U...........|
00000040 00 00 29 c4 83 ec 0c 68 00 00 00 00 e8 fc ff ff |..)....h........|
... (40 lines omitted) ...
000002d0 0e 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 |................|
000002e0 00 68 65 6c 6c 6f 2e 63 00 6d 61 69 6e 00 70 72 |.hello.c.main.pr|
000002f0 69 6e 74 66 00 00 00 00 14 00 00 00 01 05 00 00 |intf............|
00000300 19 00 00 00 02 08 00 00 |........|
00000308


Demonstration

Download a ZIP file containing the C source code here [4 KB]
Alternatively, you can download the Win Executable [16 KB] or Linux Executable [12 KB]

Share

Artifact J-2: Java RPN Calculator (Command Prompt)

Description

A simple command prompt calculator that uses Reverse Polish Notation.

In Reverse Polish Notation the operators follow their operands; for instance, to add three and four, one would write “3 4 +” rather than “3 + 4″. If there are multiple operations, the operator is given immediately after its second operand; so the expression written “3 − 4 + 5″ in conventional infix notation would be written “3 4 − 5 +” in RPN: first subtract 4 from 3, then add 5 to that.

The algorithm for evaluating any postfix expression is fairly straightforward:

  • While there are input tokens left
    • Read the next token from input
    • If the token is a value
      • Push it onto the stack
    • Otherwise, the token is an operator
      • It is known a priori that the operator takes n arguments
      • If there are fewer than n values on the stack
        • (Error) The user has not input sufficient values in the expression.
      • Else, Pop the top n values from the stack.
      • Evaluate the operator, with the values as arguments
      • Push the returned results, if any, back onto the stack
  • If there is only one value in the stack
    • That value is the result of the calculation
  • If there are more values in the stack
    • (Error) The user input too many values

For more information on Reverse Polish Notation read: http://en.wikipedia.org/wiki/Reverse_Polish_Notation.

Technical Knowledge

I applied my knowledge of:

  • object oriented programming in Java
  • Reverse Polish Notation
  • polymorphism.

Skills Applied

I developed these skills while making this artifact:

  • using the NetBeans IDE
  • test-driven design using Netbeans
  • object oriented programming with Java.

Notes

I wrote this for BCIT’s COMP 2526, Intermediate Java, in February 2008.

I employed an iterative, test-driven approach. My first iteration resulted in a program that used classes to deal with different operations. The second iteration reduced code duplication and improved the quality of the code with polymorphism.

The application was written using NetBeans against a series of Unit tests provided by our instructor, D’Arcy Smith.

Demonstration

Download the source code [8 KB ZIP].

Download the JAR file here [13 KB]. Navigate to the download folder with your command prompt and run using:

java -jar RPN_2.jar

Share

Artifact J-1: Codeword Parity Validator

Description

A program that tells the user if a parity-encoded word is valid or not, and if a Hamming codeword is valid or not.

A parity-encoded word is a series of binary digits (zero or one) where the left most digit is either a zero or one depending on the type of parity being used (EVEN or ODD). If a word is encoded with EVEN parity the number of one bits must be an even number. If a word is encoded with ODD parity the number of one bits must be an odd number.

For example, if the original word is: 100

  • EVEN codeword is 1100 (1 + 1 is 2, an even number)
  • ODD codeword is 0100 (1 is an odd number)

A Hamming encoded word is a series of binary digits (zero or one) where the 2x bits are either a zero or one depending on the type of parity being used (EVEN or ODD)

For example, if the original word is: 10

  • EVEN codeword is 11100
  • ODD codeword is 00110

For more information on parity checking read: http://en.wikipedia.org/wiki/Parity_bit.
For more information on Hamming codes read: http://en.wikipedia.org/wiki/Hamming_code.

Technical Knowledge

I applied my knowledge of:

  • Java basics including GUI classes
  • regular expressions
  • object oriented programming.

Skills Applied

I developed these skills while making this artifact:

  • working with the NetBeans IDE
  • test-driven design using NetBeans
  • object oriented programming with Java.

Notes

I wrote this for BCIT’s COMP 2526, Intermediate Java, in January 2008.

I employed an iterative, test-driven approach. My first iteration resulted in a program that checked the parity of a codeword entered as a command-line argument. The second iteration added logic to check Hamming codewords, and the third and final iteration added a GUI envelope for the program.

The application was written using NetBeans against a series of Unit tests provided by our instructor, D’Arcy Smith.

Demonstration

Download the source code [7 KB].

Download the JAR file here [21 KB]. Navigate to the download folder with your command prompt and run using:

java -jar Parity_Validator_3.jar

Share

Artifact U-1: Case Study 1 ‘A Fictitous Courier System’

Description

A set of UML 2.0-compliant diagrams that describe the functional requirements for a fictitious courier company’s new Geographic Information and Delivery Route Optimization System.

Diagrams completed include:

  1. Domain Model Class Diagram
  2. Use Case Diagram for “Create Route”
  3. Use Case Description for “Create Route”
  4. System (Black Box) Sequence Diagram for “Create Route”
  5. Use Case Sequence Diagram for “Create Route”.

This assignment was completed for BCIT’s COMP 2730, Systems Analysis and Design, in Spring 2008.

Technical Knowledge

In this assignment I applied my knowledge of:

  • event decomposition
  • Unified Modeling Language 2.0
  • creating UML docs using CASE tools like Rational Rose, Netbeans and MS Visio
  • fundamental principles of object oriented design like:
    • coupling
    • cohesion
    • object responsibility
    • protection from variations
    • indirection
    • use case controllers.

Skills Applied

This project demonstrates my ability to:

  • analyze, decompose and model complex problems and data systems
  • analyze information requirements and business processes to specify and design systems aligned with an organization’s goals
  • understand and use UML including interaction, sequence and collaboration diagrams
  • understand how to determine and document system requirements using the appropriate techniques
  • use modeling tools like NetBeans and MS Visio to accurately and efficiently describe a problem domain being investigated as well as an architecture-independent solution.

Notes

During my second term at BCIT we studied the software development life cycle. We began with five basic stages (planning, analysis, design, implementation and support), and investigated the various models, tools and techniques that are used during each stage to best analyze and design modern information systems. This assignment provided a case study and asked that we analyze the business requirements and create and deliver a series of consistent documents using Unified Modelling Language (UML 2.0), the current industry standard for system modelling.

The Domain Model Class Diagram provided an opportunity to create a system’s major entities and their relationships. Its use of classes is consistent with the current object oriented programming paradigm, in which systems deal with objects that hold and encapsulate data, rather than the older, traditional dataflow models. The other four diagrams deconstruct a single use case or functional requirement, “Create Route”. Business events trigger elementary business processes that a system addresses as use cases, and each of the four documents describes the same use case from a different point of view, or with different granularity.

I found this project challenging because there were no hints and no clear guides. The type of system being designed, a geographic information and courier route optimization system, was completely unfamiliar to me, so I couldn’t use a standard design template or capitalize on an intuitive understanding of the problem domain. I completed some research about GIS systems and courier companies and began with a simple domain model of several key objects to which I added detail in an iterative process.

An important reference was our class text: Satzinger, John W, Robert B Jackson and Stephen D Burd. Systems Analysis & Design Fourth Edition. Boston: Thomson Course Technology, 2007.

Demonstration

The five documents I produced are available for download as a single PDF [907 KB]

You may also view each artifact individually:

  1. Problem Domain Model Diagram JPEG [115 KB] / PDF [332 KB]
  2. Use Case Diagram for “Create Route” JPEG [167 KB] / PDF [84 KB]
  3. Use Case Description for “Create Route” PDF [46 KB]
  4. System (Black Box) Sequence Diagram for “Create Route” JPEG [85 KB] / PDF [236 KB]
  5. Use Case Sequence Diagram for “Create Route” JPEG [142 KB] / PDF [314 KB]
Share