Lab46 Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
<WRAP centeralign round box>
<WRAP><color red><fs 200%>Corning Community College</fs></color></WRAP>
<WRAP><fs 150%>CSCS2320 Data Structures</fs></WRAP>
</WRAP>

~~TOC~~

======Project: DLT0======

=====Errata=====
This section will document any updates applied to the project since original release:

  * __revision 1__: unit test for **traverse_r()** now available (20150502)
  * __revision 2__: unit tests for **cptree_r()** and **rmtree()** now available (20150502)
  * __revision 3__: unit tests for **grabnode_r()** now available (20150503)



=====Objective=====
In this project, we continue our conceptual journey and explore yet another data structure: trees.

=====Background=====
A **tree** is our first foray into the realm of non-linear data structures. While it still consists of nodes, and those nodes are linked together, they are not linked together in a way providing a contiguous succession as we have in a list.

Truth be told, the simplest tree is merely a list- the underlying data structure we've worked with all semester. But now, under this new light, we can start to look at a list as merely a procession of singled childed nodes. The more things are different, the more they are the same...

The simplest conceptual tree is one which has a maximum of two connections- often these are called 'binary' trees. We will use that description interchangeably here with 'doubly linked trees'.

The premise behind a binary tree is that of a parent-child relationship. Each node can be a parent (of up to two child nodes), and each child can in turn be its own parent (of up to two child nodes). This creates a connection between relationships of nodes (ie a parent and its descendants), and ends up offering some interesting and useful algorithmic opportunities, along with implementation experience.
====conceptualizing a tree====
It is common to think of a tree as a vertical structure, upside-down from the item we commonly think of in nature. Here we will have the tree's "root" at the very top, and all the branches (nodes, and connections to nodes) growing down and out from the root.

====the tree====
The tree data structure presents certain advantages that encourages its use in solving problems, and we accomplish that by its compositional definition:

  * a tree has a **root** which forms the basis or starting point of the structure; all nodes are reachable (and related through means of descendance) from the root.
  * to put an item on the tree, we insert or **add** it. When we add a node to the tree, it gets positioned in the appropriately available child link off some parent node.
  * to get an item off of the tree, we **grab** it (my term- often times it is referred to as deleting a node from the tree). Just as with a list and its obtain action, disconnecting a node from the structure can involve a lot of work to maintain connections and overall integrity of the data structure.
  * an important action that will be taking place is the traversal of the tree- ie walking it in certain orders to achieve desired results (sorting/ordering of values, among other things).

As we will be placing nodes in the tree according to their stored values (lesser values go to the left, or prior; greater values go to the right, or after), our tree will naturally sort our data for us, allowing us to search through its contents quite advantageously. As such, the tree we will be implementing is also known as a //binary search tree//.
====tree height can matter====

For some operations (specifically, visualization), the height of the tree can be very important, and constraining the tree height can impose a nice upper bound on the total number of nodes put into the tree.

Just as with the stack's size and the queue's buffer, our tree will have the ability to set a **max_height**, which our adding logic needs to respect.

=====Project Overview=====

For this project, we're going to be implementing the tree data structure utilizing nodes. Isn't it neat how we've been able to use this same basic structure in so many different ways and configurations? That speaks to what we're exploring in Data Structures- ideas. It isn't as much about WHAT we're manipulating (nodes), but HOW.

====In inc/data.h====
Here we see some additional status code defines:

<code c 1>
// Status codes for the tree implementation
//
#define  DLT_SUCCESS        256
#define  DLT_CREATE_FAIL    512
#define  DLT_NULL           1024
#define  DLT_EMPTY          2048
#define  DLT_MAX            4096
#define  DLT_DEFAULT_FAIL   16384
#define  DLT_FAIL           32768
</code>

I also created the typedefs **sc** and **uc** to simplify the declaration of **signed char**s and **unsigned char**s (respectively). These can me seen just above the bottom of the file.
====In inc/tree.h====

<code c 1>
#ifndef _TREE_H
#define _TREE_H

#include "data.h"
#include "list.h"

#define  INORDER       0
#define  PREORDER      1
#define  POSTORDER     2

struct tree {
    Node *root;                         // pointer to root node of tree
    uc    max_height;                   // max height of tree (0 = unlimited)
};
typedef struct tree    Tree;

code_t mktree    (Tree **, uc        ); // create new tree
code_t cptree_r  (Tree  *, Tree **   ); // copy given tree (recursive)
code_t rmtree    (Tree **            ); // purge and deallocate tree

code_t addnode   (Tree **, Node *    ); // add given node to tree
code_t grabnode_r(Tree **, Node **   ); // get node from tree (recursive)
code_t traverse_r(Tree  *, List **,uc); // traverse tree by mode (recursive)

code_t searchtree(Tree  *, Node **,sc); // find node in tree (by value)

#endif
</code>


====tree library====
In **src/tree/**, you will find skeletons of the above prototyped functions, hollowed out in anticipation of being made operational.

Figure out what is going on, the connections, and make sure you understand it.

===Suggested Implementation Order===
To make your life easier, I recommend implementing tree library functions in the following order:

  - **mktree()**
  - **addnode()**
  - **searchtree()**
  - **traverse_r()**
  - **grabnode_r()**
  - **cptree_r()**
  - **rmtree()**

You will really want the later functions to make use of the earlier functions to facilitate implementation (ie **cptree_r()** will likely want to make use of **traverse_r()** and **addnode()**, and **rmtree()** could take advantage of **traverse_r()** and **searchtree()** and **grabnode_r()**).

Note that **grabnode_r()** can be implemented earlier, as it only really needs **mktree()**, but you may find its implementation more involved.
====Tree library unit tests====
In **testing/tree/unit/**, you will //eventually// find these files:

  * **unit-addnode.c** - unit test for the various **addnode()** library function
  * **unit-searchtree.c** - unit test for the various **searchtree()** library function
  * **unit-grabnode.c** - unit test for **grabnode_r()** library function
  * **unit-mktree.c**   - unit test for the **mktree()** library function
  * **unit-cptree.c**   - unit test for **cptree_r()** library function
  * **unit-rmtree.c**   - unit test for **rmtree()** library function
  * **unit-traverse.c** - unit test for **traverse_r()** library function

**NOTE**: At the time of project release, not all unit tests are available/fully functional; so expect some updates.

There are also corresponding **verify-FUNCTION.sh** scripts that will output a "MATCH"/"MISMATCH" to confirm overall conformance with the pertinent tree functionality.

These are complete runnable programs (when compiled, and linked against the tree library, which is all handled for you by the **Makefile** system in place).

Of particular importance, I want you to take a close look at:

  * the source code to each of these unit tests
    * the purpose of these programs is to validate the correct functionality of the respective library functions
    * follow the logic
    * make sure you understand what is going on
    * ask questions to get clarification!
  * the output from these programs once compiled and ran
    * analyze the output
    * make sure you understand what is going on
    * ask questions to get clarification!


=====Expected Results=====
To assist you in verifying a correct implementation, a fully working implementation of the node and tree libraries should resemble the following (when running the respective verify script):



====tree library====
Here is what you should get for tree:

<cli>
lab46:~/src/data/dlt0$ bin/verify-tree.sh 
coming soon
lab46:~/src/data/dlt0$ 
</cli>

=====Submission Criteria=====
To be successful in this project, the following criteria must be met:

  * Project must be submit on time, by the posted deadline.
    * As this project is due at the very end of the semester, there is no late window. It is either submitted, or it is not.
  * All code must compile cleanly (no warnings or errors)
    * all requested functions must be implemented in the related library
    * all requested functionality must conform to stated requirements (either on this project page or in comment banner in source code files themselves).
  * Executed programs must display in a manner similar to provided output
    * output formatted, where applicable, must match that of project requirements
  * Processing must be correct based on input given and output requested
  * Output, if applicable, must be correct based on values input
  * Code must be nicely and consistently indented (you may use the **indent** tool)
  * Code must be commented
    * Any "to be implemented" comments **MUST** be removed
      * these "to be implemented" comments, if still present at evaluation time, will result in points being deducted.
    * Sufficient comments explaining the point of provided logic **MUST** be present
  * Track/version the source code in a repository
  * Submit a copy of your source code to me using the **submit** tool (**make submit** will do this) by the deadline.
Lab46 Wiki

User Tools

Site Tools

Page Tools
