CTEC2901 Data Structures and Algorithms - 2015/16

First Coursework Specification

This coursework item is summative.
This summative coursework will be marked anonymously.
The learning outcome assessed by this assignment is:
[1] Explain and implement a variety of classical data structures
This is an individual assignment.
This assignment constitutes 25% of the module mark.
Date Set:
Date and Time Due:

Week 5 Monday 2nd November 2015

Week 11 Monday 14th December 2015 (4pm)

Your marked coursework and feedback will be available to you on Friday 15th January
2016. If for any reason this is not forthcoming by the due date your module leader will let you know why
and when it can be expected. The Head of Studies (headofstudies-tec@dmu.ac.uk) should be informed of
any issues relating to the return of marked coursework and feedback.

When completed you are required to submit your coursework to:

Upload to Blackboard (see detailed instructions below.)
Late submission of coursework policy: Late submissions will be processed in accordance with current University regulations which state:
The time period during which a student may submit a piece of work late without authorisation and have the work capped at 40% if passed is 14 calendar
days. Work submitted unauthorised more than 14 calendar days after the original submission date will receive a mark of 0%. These regulations apply to a
students first attempt at coursework. Work submitted late without authorisation which constitutes reassessment of a previously failed piece of coursework
will always receive a mark of 0%.
Academic Offences and Bad Academic Practice:
These include plagiarism, cheating, collusion, copying work and reuse of your
own work, poor referencing or the passing off of somebody elses ideas as your
own. If you are in any doubt about what constitutes an academic offence or
bad academic practice you must check with your tutor. Further information is
available at:

http://www.dmu.ac.uk/dmu-students/the-student-gateway/academic-support-office/
academic-offences.aspx
http://www.dmu.ac.uk/dmu-students/the-student-gateway/academic-support-office/
bad-academic-practice.aspx

Contents
1 Background Information

2 Tasks to be undertaken

2.1

Implement the blocked stack . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2

Comment the blocked stack . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3

Link with our demo program . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Deliverables to be submitted for assessment

4 How the work will be marked

4.1

Library (Weight 60%)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2

Commenting (Weight 20%) . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3

Stack Visualisation (Weight 20%) . . . . . . . . . . . . . . . . . . . . . . .

CTEC2901 Data Structures and Algorithms

Coursework I (25%)
1

Background Information

You have looked at two implementations of a stack data structure in C. The first uses
arrays and the second uses dynamically allocated storage. Both of these methods have
their advantages and disadvantages. The array is fixed so there is a maximum capacity
whereas the dynamic implementation can grow as required. However, the pointer overheads
on the dynamic implementation can be significant if the data values are relatively small
(e.g. int values). A compromise implementation uses dynamically allocated blocks of
memory as the following diagram illustrates:

stack

..
.
303
302
301

300
299
..
.

203
202
201

200
199
..
.

103
102
101

100
99
..
.
3
2
1

For illustrative purposes we have chosen a block size of 100 and pushed the first 303 integers
onto the stack. Initially the empty stack has no blocks allocated at all. As soon as the first
item is pushed a block (array) of 100 ints is allocated. Once this has filled up then another
block is allocated and linked to the first block. And so on. In the example the top of the
stack is 303 and there is clearly room for another 97 items before another block needs to
be allocated.
Popping works in reverse. Suppose we pop the stack three times. All of the data in the
most recently allocated block has been popped and the block can be deallocated:
stack

300
299
..
.
203
202
201

200
199
..
.
103
102
101

100
99
..
.
3
2
1

Essentially the implementation is a singly linked list of structs in which each struct maintains an array of data, and a pointer to the next block. There will also be an index to the
top item although this value is only significant in the most recently allocated block.

2
2.1

Tasks to be undertaken
Implement the blocked stack

You should write an implementation in ANSII C for this blocked implementation of a

stack data structure. Put the implementation into the file blocked stack int.c making
sure that all of the following operations are supported. We have provided the header file.
Copy the content below into blocked stack int.h.
#ifndef STACK_int_H
#define STACK_int_H
typedef struct stack_int_implementation stack_int;

stack_int * new_blocked_stack_int(int block_size);

int stack_int_isempty(stack_int *s);
int stack_int_size(stack_int *s);
void stack_int_push(stack_int *s, int x);
void stack_int_pop(stack_int *s);
int stack_int_top(stack_int *s);
void stack_int_display(stack_int *s);
void stack_int_release(stack_int *s);
#endif

Note that the constructor allows the user to specify how large the blocks must be. This
will remain constant for the lifetime of the stack instance. The display function should
draw the stack rather like we have done in the illustrations above. This will make it clear
to see the underlying structure of the stack. You are free to present this information on
the screen in any way that you wish. It will be easier to present the data horizontally (i.e.
the contents of a block from left to right rather than top to bottom) but it is up to you.
However, it should clearly show how the blocks are connected; what values are stored in
them; and which item is currently the top of the stack. Although these could, in principle,
get very large we will only be testing it for small block sizes as this will be sufficient to
demonstrate that it is working.
For this assignment you may assume that the stack will not be created with a block size
greater than 10. This will help you to design a reasonable printing routine without worrying
that it will become unmanageable in the terminal. The layout can be very simple lists of
numbers (with annotations) if you wish; or you may invent more sophisticated ways of
picturing the data structure (in ASCII on the terminal). We have allocated marks to
reflect the effort that you put in to visualising the blocked structure of the stack. (See the
marking scheme below).

2.2

Comment the blocked stack

We require that the code you write is fully commented. You should provide more comments
than perhaps you would normally write because we want to be sure that you understand
every detail of the code you have written. Make sure the comments are clearly linked to
the relevant code but also separated from it so that it is easy to read. Block comments are
useful. Avoid writing comments like increments i against i + + as this is not very illuminating. However, if i represents a particularly significant value then write increment the
available-space index (or whatever is relevant). We do not wish to be overly prescriptive
on style as this is a rather individual thing but we want to demonstrate the type and
level of commenting that we want for this assignment. Therefore, here is an example to
give you an idea (the example is taken from the array implementation of the stack from
the course notes).

/*************************************************************************
* int stack_int_push
*
* Parameters:
* s
-- a pointer to the stack header node
* x
-- the value to be pushed onto stack s
*
* Description:
* Checks to see if the stack is full before attempting to push a new
* item. If the stack is full then an error message is printed and the
* function causes the whole program to stop. Otherwise the stack is
* updated by adding the new item to the top of the stack.
*
************************************************************************/
void stack_int_push(stack_int *s, int x)
{
assert(s!=NULL);
// check s is defined before dereferencing
if (stack_int_isfull(s))
// re-uses internal library function
{
printf("stack_int_push error: stack is full\n");
exit(1);
}
else
// there is room for the new item
{
s->items[s->top] = x;
// s->top is an index pointing to the next
// available space in s->items array
(s->top)++;
// Advance the next avilable space index
}
}

2.3

Link with our demo program

You should copy the following code into a program called demo blocked stack.c. This is
a program for testing your library implementation. (We may adapt or modify this when
testing your code for assessment purposes but this version will be sufficient for you to
use as the basis for testing your code.) Feel free to enhance this for your own testing
requirements.
#include <stdio.h>
#include <stdlib.h>
#include "blocked_stack_int.h"
char line[] = "****************************************";
void snapshot(stack_int * s, char * m)
{
printf("\n%s\n", line);
printf("** %s\n", m);

printf("** Stack size

is %4i\n", stack_int_size(s));
if (!stack_int_isempty(s))
printf("** Top of stack is %4i\n", stack_int_top(s));
printf("%s\n", line);
stack_int_display(s);
}
int main()
{
int i,j;
int bs=10;
stack_int * s = new_blocked_stack_int(bs);
snapshot(s, "New stack");
printf("Pushing and popping. All ok: ");
j = bs*2+2;
for(i=0; i<j; i++)
stack_int_push(s, i);
for(i=j-1; i>=0; i--)
{
if (i != stack_int_top(s))
{
printf("NO!\n");
exit(1);
}
stack_int_pop(s);
}
printf("YES\n");
printf("Stack should be empty: ");
if (stack_int_isempty(s))
printf("YES\n");
else
{
printf("NO!\n");
exit(1);
}
stack_int_push(s, 1);
snapshot(s, "Pushed an item");
for(i=2;i<=bs;i++) stack_int_push(s, i);
snapshot(s, "Filled first block");
stack_int_push(s, 11);
snapshot(s, "Push an item - created new block");
for(i=bs+2;i<=3*bs-1;i++) stack_int_push(s, i);
snapshot(s, "Created two new blocks");
stack_int_push(s, 3*bs);

snapshot(s, "Pushed an item filling the block");

stack_int_push(s, 3*bs+1);
snapshot(s, "Pushed an item creating new block");
stack_int_pop(s);
snapshot(s, "Popped an item - lose one block");
stack_int_pop(s);
snapshot(s, "Popped an item");
for(i=1;i<bs;i++) stack_int_pop(s);
snapshot(s, "Popped items - clearing the first block");
for(i=1;i<bs+bs/2;i++) stack_int_pop(s);
snapshot(s, "Popped items - cleared one and a half blocks");
while (stack_int_size(s) > 1) stack_int_pop(s);
snapshot(s, "Emptied the stack bar one element");
stack_int_pop(s);
snapshot(s, "Popped the last item");
return 0;
}

Deliverables to be submitted for assessment

Upload your implementation file (blocked stack int.c) via the coursework hand-in portal on Blackboard before the given date. We only want this source file do not upload any
other files. We will compile this against our copy of the header file (the same one as you
have been given in this assessment brief) and link it with our own demo program that we
will use for assessment. NB: We will use essentially the same demo program that you have
been given in this assessment brief but we reserve the right to make whatever modifications
to its behaviour that we see fit when linking it with your coursework submission.1

How the work will be marked

The marking scheme will be translated onto a Blackboard Rubric. The work will be
marked online and Blackboard used for providing the feedback based on the rubric.
1

For example, we may change the block size, vary the input data, or change the order of pushes and
pops etc.

4.1

Library (Weight 60%)

We expect to see a program that compiles and runs and makes a reasonable attempt at
the solution. At this level a program that does not compile is unnacceptable and will be
treated the same as a non-submission. To get full marks in this category the program must
pass ALL the tests we choose to run.
The broad categories below cover both the technical achievement (i.e. does it work?) and
the code (i.e. has it been coded well?). This does not cover commenting which comes under
a subsequent criterion. A fully working solution that is poorly designed would not score as
well as one that is fully working and well designed. Similarly, a well-designed solution that
has some coding mistakes may also score better than a fully-working solution that is poorly
designed. We do want to see code that is clean and maintainable. So, avoid hard-wired
constant values use constants instead; check that malloc has worked; choose sensible
variable names; indent code correctly to highlight the control structure; use sub-functions
where appropriate (e.g. in the stack int display function if this gets complex); etc.
Since this is partially subjective, these broad categories act as a guide. The closest fit
will be selected for each indivitual piece of work.
0% Non submission, no real attempt, or code that fails to compile.
20% Compiles. Significant room for improvement. Maybe only one or two test cases have
worked.
40% Compiles. The code would benefit from a fair amount of improvement. Some of the
test cases will have passed.
60% Compiles. Most of the code is of good quality. There is room for improvement even
if most (or all) test cases ar passed.
80% Compiles. Very little fault can be found. Must have passed (nearly) all of the test
cases.
100% Compiles. No fault can be found other than extremely minor errors. All test cases
must be passed.

4.2

Commenting (Weight 20%)

If a non-compiling program was submitted it is possible to pick up some marks here, but
only in the 20% category. The rationale is that if the code is commented to a good standard
then it should be sufficiently well understood that it compiles and performs reasonably well.
0% No comments - or just one or two brief remarks.

20% Some very basic comments. A programmer would struggle to understand and maintain the code based on these comments. Or non-compiling code submitted with some
reasonable comments provided.
40% Some good comments but not covering all the code in the library and/or not expressed
clearly in a number of places. A programmer would have a reasonable chance of
adapting and maintaining parts of the the code, but some aspects could be very
unclear.
60% Good commenting. Perhaps not fully detailed or clear in all areas but significant
passages are sufficiently clear to enable a programmer to adapt and maintain the
code confidently.
80% Excellent commenting. The majority of the code is extremely well described and a
programmer would have no difficulty working out how it all works. Room for minor
improvements.
100% Thoroughly commented and very easy to follow. Similar to the 80% category but
there must be nothing that obviously requires improvement. Provides confidence to
the marker that the author fully understands all aspects of the code.

4.3

Stack Visualisation (Weight 20%)

We asked for a suitably well presented visualisation of the blocked stack (stack int display).
The clearer the blocked stack is presented the easier it will be to see that it is working
correctly. We want to reward effort (and flair) in this category.
0% No real attempt.
20% Very basic attempt does not really work very well.
40% Basic display does the job. (e.g.) simple list with a few annotations.
60% Reasonable effort and good results - demonstrates some degree of creativity and
technical ability.
80% Very good display function. Demonstrates significant degree of creativity and technical ability.
100% Outstanding display function. Presents information beautifully and demonstrates
creativity and technical ability to an extremely high degree.