Assignment 2: Forest Fire (2023)

In this assignment you will write code to explore a way in which programming canbe used to model an environmental process.

Extreme weather events such as bush fires are becoming an increasing threat toAustralian wildlife, agriculture, and habitability. Modelling and monitoring thecondition of forests can help to predict fire behaviour and can assist in firemanagement strategy.

In this assignment, your task is to create a rudimentary model simulating thedevelopment and spread of forest fire, and plot the consequent change in treedensity.

Important information

This assignment is worth 12% of your final grade.

Deadline: Sunday 30th April, 2023, at 11:00pm Canberra time sharp.Note: Late submissions will not be marked unless you have an approved extension.

We highly recommend committing your work as you go, and pushing regularly.Do not wait until you are finished to commit and push for the first time, asyou run the risk of missing the deadline and having nothing submitted. Anunfinished assignment is worth more than no assignment.

Required Knowledge

Students who have worked up to the Week 6 lab shouldhave the programming knowledge required for this assignment; in particular youwill need to work with recursion and parametric polymorphism.

The Week 7 lab will help you improve your unit testand style marks.

You do not need any knowledge of environmental modeling methods, propertiesof fire spread and forest growth beyond what we give you in this document.

There is a glossary included at the end of this document in which some of themore specific environmental terms have been defined.

Some additional resources have been provided throughout this document forinterested students, but reading these is not required to completethis assessment.

COMP1130 students may choose to investigate properties of forest fires toimprove the accuracy of their model for their additional task, but an in-depthunderstanding is not required.

This assignment is designed to test your ability to use recursion in programming,and to apply appropriate functional decomposition.

If you need additional help with report writing or assessment planning, seeksupport fromANU Academic Skillsearly on.

Overview of Tasks

This assignment is marked out of 100 for COMP1100, and out of 120 forCOMP1130:

From this assignment onward, code that does not compile and run will be penalised heavily. This means that both the commands cabal v2-run forestfire and cabal v2-test must run without errors. If either if those commands fails with an error, a heavy mark deduction will be applied. The deduction will be the same regardless of which of these commands fails. If you have a partial solutionthat you cannot get working, you should comment it out and write an additional comment directing your tutor’s attention to it.

Getting started

1. Fork the assignment repository and create a project for it inVSCodium, following the same steps as in [Lab 2](/courses/comp1100/labs/02/. Theassignment repository is athttps://gitlab.cecs.anu.edu.au/comp1100/2023s1/2023s1studentfiles/assignment2.

2. Add our version of the repository as a remote calledupstream. This allows us to provide additional fixes in the unlikely case that theyare required. You do this by doing the following:

   • Go to the command palette in VSCode (or VSCodium) by pressing Ctrl + Shift + p
   • Type git remote
   • Click Git: Add Remote
   • Enter upstream into the box for the remote name
   • Put the following URL as the remote url: https://gitlab.cecs.anu.edu.au/comp1100/2023s1/2023s1studentfiles/assignment2.git.

Overview of the Repository

For COMP1100 students, most of your code will be written insrc/ForestFire.hs, and a little in src/TestPatterns.hs.You will also need to implement tests insrc/ForestFireTest.hs, which contains some example tests for you tostudy. COMP1130 students will also need to write code in src/App.hs.

Other Files

• app/Main.hs launches the test application.

• src/App.hs contains the bulk of a small CodeWorld test programthat uses your forest fire code. We discuss its features in “Overviewof the Test Program”.

• src/ForestRenderer.hs contains code to render a grid of sites (representinga forest) to the screen, and to convert a point on the screen back into anarea coordinate. It also contains code to render a plot of points (representing tree density information) to the screen. You are not required tounderstand it, but it is commented for interested students to read.

• src/TestPatterns.hs contains some test patterns for the modelin this assignment.

• src/Testing.hs is the testing library we used in Assignment 1. Youshould read this file as well as src/ForestFireTest.hs, and make sureyou understand how to write tests.

• test/Main.hs is a small program that runs the tests insrc/ForestFireTest.hs.

• comp1100-assignment2.cabal tells the cabal build tool how to buildyour assignment. You are not required to understand this file, andwe will discuss how to use cabal below.

• Setup.hs tells cabal that this is a normal package with no unusualbuild steps. Some complex packages (that we won’t see in thiscourse) need to put more complex code here. You are not required tounderstand it.

Overview of cabal

As before, we are using the cabal tool to build the assignmentcode. The commands provided are very similar to last time:

• cabal v2-build: Compile your assignment.

• cabal v2-run forestfire: Build your assignment (if necessary), andrun the test program.

• cabal v2-repl comp1100-assignment2: Run the GHCi interpreter overyour project.

• cabal v2-test: Build and run the tests. This assignment is set up to run a unit test suite like in Assignment 1, but this time you will be writing the tests. The unit tests will abort on the first failure, or the first call to a function that is undefined.

You should execute these cabal commands in the top-level directory of yourproject: ~/comp1100/assignment2 (i.e., the directory you are in when youlaunch a terminal from VSCodium).

Overview of the Test Program

The test program in app/Main.hs uses CodeWorld, just like Assignment 1, and responds to the following keys:

You can also click on sites with the mouse to change them, if you wantto play around with different patterns.

If you try to use the test program without completing Task 1, or youtry to run the simulation before completing Task 2, the test programmay crash with the following error:

"Exception in blank-canvas application:"Prelude.undefined

If this happens, refresh the browser to continue.

Overview of ForestFire

ForestFire is a model made up of two main components: (The key ‘p’ togglesbetween the two components, as explained in “Overview of the Test Program”).

1. A visual model of a forest made up of a grid of sites, designed to model the development of a forest fire over a series of discrete time intervals representing the passing of days.

2. A plot of tree density of the forest over time.

Every day, a set of assumptions will be applied to each Site in the Forestsuch that its Condition will change depending on the surrounding Sites andthe amount of days it has been in its current condition.

Assumptions: How the fire spreads

In environmental modelling, it is sometimes challenging to collect continuousdata across an area, due to availability of resources, limits of technology,site accessability, etc. In this assignment, we will be using a Cellular Automatamodel to represent a forest in terms of discrete areas known as Sites. The sites are evenly distributed along a set of parallel rows.

The development of the forest and the fire is determined by a set of assumptions describing the behaviour of an individual Site according to its condition at \(t\) and the condition of its surroundingsat time \(t\). The surroundings of a site refer to the sites immediatelyadjacent in all eight ordinal directions(i.e. including diagonals).

The assumptions are as follows:

• A site can either be barren, have trees, or be on fire.

• If a site is barren at \(t\):

  • If more than half of the surrounding sites have trees, the site will have trees in \(t+1\).

  • If the site’s condition has been barren for more than 20 days, it will have trees in \(t+1\).

  • Otherwise, the site will remain barren at \(t+1\).

• If a site has trees at \(t\):

  • If any of the sites directly north, south, east or west of it are on fireat \(t\), it will be on fire at \(t+1\).

    (Video) A Day In The Life of a Wildland Firefighter on a Fire Assignment

  • Otherwise, if 2 or more of the sites diagonally adjacent to it are on fireat \(t\), it will be on fire at \(t+1\).

  • If the site has had trees for more than 50 days, it willbe on fire at \(t+1\).

  • Otherwise, the site will continue to have trees in \(t+1\).

• If a site is on fire:

  • If the site has been on fire for 2 or more days at \(t\), it will become barren at \(t+1\).

  • Otherwise, it wil remain on fire.

Note: Whenever a site changes condition, we consider it to be at day\(n_t = 0\) of having that condition. Every time that the model is updated and thecondition of a site does not change, we consider the site to have been in that condition for 1 more day (i.e. \(n = n_t + 1\)).

Tip: If you are struggling to understand the assumed behaviour, try drawing it out in a table or flow diagram. This might also help when you put together some of the functions in task 2!

Test Patterns

The Test Patterns given in this assignment will allow you to observe some of thevariety of behaviour that the forest fire simulator can display, and will provide something for you to compare your program against.

We have included a function fastForest :: Forest -> Int -> Forest found in src/ForestFire.hs, which updates the forest a given number of days into the future. You may use this function to help test your program once you have finished task 2.

The first test pattern courseOnFire should appear as follows:

The second test pattern smallSpotFires is a forest with fires spread around:

Do you notice anything interesting about how the forest changes over time? Doesit match what you would expect?

The third test pattern is a larger version of the spot fires:

Understanding ForestFire Data types

A Forest has two Ints describing the number ofrows in the forest and the number of sites in each row, respectively. It alsocontains a list of all the Sites. The list should be exactly as long as the number of rows multiplied by the number of sites per row.

A Forest is visually represented as a grid of Sites. A Site has a Condition describing whether it is barren, has trees, or is on fire, and an Int describing how many days it has been in that condition.

Task 1: Types and helper functions (COMP1100: 20; COMP1130: 15)

Before we can begin implementing our forest model, we need to setup a few things:

• Data types to represent each condition;
• Helper functions over sites; and
• Helper functions for our Forest data type.

The assignment framework will use these functions to render entiregrids of sites into CodeWorld Pictures.

Your tasks

1). In src/ForestFire.hs, complete the data type Condition that represents the different conditions of sites in our model.

Defining our own type to talk about conditions lets us be precise when wecode; knowing that there is a fixed number of possible conditions reducesbugs.

Now that you have defined your type, there is one back-end step you need to do. Go to line 102 of src/App.hs

| isPlot = undefined --renderPlot (plotDensity forest density <TODO: put a condition here> 20)

and insert your condition type representing trees as indicated, so that it looks like:

| isPlot = renderPlot (plotDensity forest density <your tree condition here> 20)This is not assessable, so if you need help understanding this please ask a tutor.

2). src/TestPatterns.hs contains some test patterns for ForestFires, expressed as Strings. The parseForest function parses these strings into values of type Forest, which are made available to the rest of the program.

(Parsing is the process of analysing unstructured data – usually strings or binary data – and converting it into a more structured form.)

parseForest relies on a helper function to parse individual characters into Sites: toCondition :: Char -> Condition, which you need to implement according to the following rule:

• A 'b' character represents a barren site.

• A 't' character represents a site containing _tree_s.

• Any other character represents a site on fire.

3). We provide a test program, the bulk of which can be seen in src/ForestRenderer.hs that uses CodeWorld to draw the sites to the screen, and allows you to interact with the grid by clicking on it. It relies on some helper functions in src/ForestFire.hs, which you need to implement:

a. The test program allows the user to change the condition of sites by clicking on them. This relies on cycleCondition :: Condition -> Condition in src/ForestFire.hs, which returns what the site should be after it is clicked. This function needs to return the “next” type of condition, similar to nextColour from Assignment 1. The “next” of a barren site is a tree site, the “next” of a tree site is a fire site, and the “next” of a fire site is a barren site.

b. The test program knows how to draw a Forest of areas, provided that it can be told how to draw a single area from the forest. It uses renderArea :: Forest -> Site -> Picture to do this, which needs to behave according to the following rules:

• Areas should be drawn as solid, coloured rectangles, centered at theorigin (i.e. not translated).

  The overall width of the grid of Sites is given by paneWidth and the overall height of the grid is given by paneHeight.

  The width of a single site should be given by dividing the width of the whole grid by the number of sites in each row. Similarly, the height should be the height of the whole grid divided by the number of rows.

• The colour of each Site should be determined by its condition. A barren site should be brown, a site on fire should be red and a site with trees should be green.

4). The test program requires two more helpers in src/ForestFire.hs that deal with the grid as a whole. You might also find them useful in Task 2:

a. get :: Forest -> AreaCoord -> Maybe Site

• The test program uses get when it responds to mouse clicks, topick out the site that the user is changing from the list stored in theForest.

• get f (x,y) shall return Just the site at position (x,y), ifit exists. If it does not (i.e., x or y are outside the boundsof the Forest), it shall return Nothing.

  (Video) CS6910 Forest Fire Detection Using YOLOv3

• Both x and y count from 0, starting at the top left. That is, (0,0) is the site at the top-left corner of the forest.

• The sites in a Forest are stored as a single list, in what we callrow-major order. This means that the list contains every site in row 1starting with site 1, then every site in row 2, then every site in row3, and so on…

b. allSites :: Forest -> [AreaCoord]

allSites (Forest nrows nsites _) shall return a list of everypossible AreaCoord in a forest of that length, with that number of rows andsites, in row-major order. This means that all the sites in the top row arelisted first, followed by all the sites in the second row, and so on. It is important that you output AreaCoords in this order, as the assignment skeleton assumes that the list of sites in a grid is stored in the same order.The renderer in the test program uses allSites to decide where to place the Picture of each site in the forest.

The dimensions of the Forest must be sensible, meaning that nrows and nsites must both be positive integers. Raise an error if either are zero or negative.

• Example:

allSites (Forest 2 4 [ Site 2 Fire, Site 4 Fire, Site 4 Fire, Site 3 Fire, Site 3 Fire, Site 2 Fire, Site 2 Fire, Site 2 Fire ])

shall return

[(0,0),(1,0),(2,0),(3,0),(0,1),(1,1),(2,1),(3,1)]

5). The test program uses CodeWorld to draw a plot to the screen, given a list of tuples.

Your task is to define a helper function density :: [Site] -> Condition ->Double, which finds the percentage of Sites of a specified Condition out of alist of Sites, represented as a double between 0 and 1. (e.g. 80% would berepresented as 0.8)

Being able to find the number of sites of a specified condition mayassist with Tasks 2 and 3.

At this stage, if you run cabal v2-run forestfire you should beable to see the first day of the simulation; switch between test patterns; and change site conditions by clicking on individual sites! Congratulations!

Hints for Task 1

• The function (!!) :: [a] -> Int -> a can return the nth elementof a list:

  • Example: ['a', 'b', 'c'] !! 2 returns 'c'.

  • Example: [] !! 0 throws an error, as there is no “0th” element in theempty list.

  • You don’t want to use this function often (because of the risk oferrors), but it is a handy tool here.

  • It can also be handy to have errors when you are testing your code:if your code uses the function !! exactly once, and your program crashesdue to a bad call of !!, then you know where to look to find the bug in yourcode.

• The labs and lectures will help you!

  • For CodeWorld, look at Lab 4, and read through the CodeWorld documentation

  • For list operations, look atLab 5, and the COMP1100 PAL site

Task 2 : Spreading the fire (COMP1100: 25; COMP1130: 25)

Now that we can render our model to CodeWorld, it is time to make it developto match the assumptions about forest fire spread, as previously described in “Overview of ForestFire”.

Your task

Define the following function in src/ForestFire.hs:

updateForest :: Forest -> Forest finds the predicted condition of the forest for the next day, according to the assumptions of the model.

Hints

• Break the problem down into subproblems (separate functions), andtest each in isolation. If you find a function does not do what youexpect, you will have smaller units of code to debug. This is easierto get your head around.

• Here are some questions you might need to ask when formulating asolution; some of them could be turned into helper functions:

  • Given a coordinate for a site in a forest, what are itssurroundings (the eight sites around that coordinate)? Note that somesites do not have surroundings on all sides. What is a way to safely returna list of objects when some of them may not exist? (Look atLab 3)

    • NOTE the assumption we make regarding the transitionof a site from a tree to fire distinguishes between orthogonal and diagonal surroundings.

    Style Note: You can split complex expressions over multiplelines, for readability:

    -- This calculation is pointless but long.-- Instead of writing it out like this:fiveFactorials = [1, 1 * 2, 1 * 2 * 3, 1 * 2 * 3 * 4, 1 * 2 * 3 * 3 * 5]-- Why not write it out like this?fiveFactorials = [ 1 , 1 * 2 , 1 * 2 * 3 , 1 * 2 * 3 * 4 , 1 * 2 * 3 * 3 * 5 ] -- P.S.: Did you notice the bug?-- It's easier to see in the second example, isn't it?

  • Given the surroundings of a site, how many sites are of some particularcondition?

  • Given a site of some condition, and its surroundings, what will thenext condition of that site be?

    • Note: for barren sites, the condition will change if more than half of thesurrounding sites are trees. A site in the middle of the forest will haveeight sites surrounding it, but that is not true of a site on the edge orcorner. How can you deal with this without checking explicitly if a siteis on the edge?

• Do the helper functions from Task 1 solve any of your subproblems?

• The list of Sites within a Forest is in row-major order. The listof coordinates returned by allSites is in row-major order. Canyou do anything useful by using both simultaneously?

Task 3: Plotting Density (COMP1100: 15; COMP1130: 10)

While our simulation allows us to visualise the development of a forest fireover time, it does not lend itself to further analysis of the trends of overallhealth of the forest, or reflect the forest’s capacity to recover.This sort of informationcan be used by environmental scientists or policy makers to understand ourenvironment and predict and prevent extreme fire events.

In this task, you will use the information created by the program so far toproduce a graph of tree density over time.

Your tasks

The test program uses CodeWorld to draw a plot to the screen. Given a list oftuples (a,b), it will draw a point a units across, and b units upwards.

Your task is to define the following helper function in src/ForestFire.hs

• plotDensity :: Forest -> ([Site] -> a -> b) -> a -> Int -> [(Int,b)] creates a listof tuples which define where our test program will draw points on the densitygraph. Given a Forest, a function [Site] -> a -> b, some a, and an int ‘n’ representing a number of daysinto the future, plotDensity shall return a tuple for each day from 0 to ‘n’inclusive. The first element of each tuple represents the day, and the secondelement represents the density of trees on that day, given as a value from 0 to 1, i.e. work out the density as a percentage and then find that percentageof 1. The code in the test program is designed such that, for example, if there are 25% trees on a particular day, or 0.25 out of 1, then the graphshould show 25 for that day. A negative integer should return an error.

  Note: the test program that produces the plot will draw a point at each location specified by a tuple. This means that the order in which thetuples appear in the list to the test program does not matter. However, theordering of the elements within each tuple (e.g. (a, b) vs (b, a)) does matter.

  For example:

  [(0,0),(1,4),(2,8),(3,10),(4,12)] will appear the same way as [(3,10),(0,0),(1,4),(4,12),(2,8)], but [(0,0),(4,1),(8,2),(10,3),(12,4)] will not.

Task 4 : Improving model accuracy (COMP1130 Only : 20)

The current model, which we shall call “Model A”, of fire spread assumes thatthe only factors influencing the development of the forest fire are theconditions of surrounding sites, and some factor of time.

Your task is to improve the accuracy of Model A by incorporatingadditional factors that influence its development.

Your Task

Consider one or more processes or factors which impact or are impacted byforest fires. Define a new model in which these factors and/or processes aretaken into account, and incorporate it into the assignment framework, includingall the functionality that was implemented in the earlier parts of theassignment and some graphical representation of your findings.

We expect you to make significant changes to the setup for Model Ain order to receive a decent mark. You might have a different set of possibleconditions for a site, additional arguments for some conditions, and a differentdefinition of “surroundings”, or a different set of assumptions.We also require your model to be at least as complex as the Model A provided - changing things like the time frame of the assumptions alone willnot get you full marks.

Style Note: Your model should be mostly distinct from Model A, even though it may have some similarities in functionality. Consider how thepresentation and layout of your code can reflect this.

Depending on your how you choose to improve your model, you may be able to usesome of the existing framework - however most sufficiently complicatedmodifications will need to change them. You may need to, but are not requiredto:

• Define a new data type for its sites. The Model A Site contains a singleargument - a Condition. You may wish to create a new data type representingyour model’s sites, and you are free to use the full power of Haskell’salgebraic data types where that makes sense in your simulation.

• Define a new data type for the condition of a site.

• Define a rendering function for your model’s sites and/orcondition types. As long asthe Picture it produces is of the same dimensions as Model A,the renderer will render the entire forest correctly.

  • You may also choose to display additional information beside the forest oron your sites; for example if you are modelling the impact of fire on koalapopulation, you maychoose to have an integer displayed on each site, or beside the forest.

    To add information outside the forest, you can modify the render functionin src/App.hs.

Regardless of your model, you will need to:

• Define an assumption or set of assumptions for your model, which shouldconsider the current site and the factors influencing and/or influenced by it.
  • The assumptions for Model A consider the Condition of a Site and theCondition of its surroundings, without regard to direction or the rest ofthe forest; if your model considers things like slope of the ground or winddirection, your assumptions may involve considering the entire forest assurroundings, or take into account things like “the site uphill” or“the site downwind”.

• Define a function that predicts the next day for your forest model.

  (Video) Firefighter Wildland Fire Pack - What to carry

• Define a function which records at least one new piece of informationderived from your model, along with the day it was collected, such that it canbe used to plot that information over time.

• Define two test patterns in src/TestPatterns.hs for yourmodel.

• Make all of the above work with the test program insrc/App.hs. The user needs to be able to:

  • Use the keyboard to switch between Model A and your model;
  • Select either of your test patterns, using the existing key bindings;
  • Advance one day at a time by pressing .;
  • Change the forest by clicking on it (you can decide what’s sensiblehere - cycling conditions made sense for Model A, but might not foryour model);
  • Use the keyboard to switch to the plot.
• Discuss your model in your report, making sure to explain how it improves theModel A, and how it reflects your chosen factors.

You should write your model such that it does not interfere with Model A, so it can still be used as described in the specification.

Hints

There is no one right way to approach this - your model can consider things frommicroscopic organisms, to human fire-fighters, to natural waterways, to windspeed, or anything else. All of these require very different implementations, and are all okay!

• When handling the ChangeArea case in applyEvent, use either ator setAt to “update” the forest at one particular site.

• If you are stuck thinking of a factor to introduce, here are some ideas:

  • Water: Rivers, streams and ponds; rain; ground water

  • Wind direction, wind strength

  • Slope of the ground/topography (fire travel upwards)

  • Temperature

  • Different types of plants

  • Wildlife and animal populations

  • Humans - different fire management and intervention strategies; cities andtowns; farms; fire trails; etc.

  • Forest recovery capacity.

  • Probabilistic condition changes

  You are not required to follow any of these suggestions. If you haveyour own exciting idea, then please pursue that!

• When making large changes like this, you can often “follow thetypes”. This is a useful procedure for making changes instrongly-typed languages like Haskell: make a change to a type andthen repeatedly attempt to build your program. GHC will issue typeerrors and warnings which tell you where the problems are in therest of your code. As you fix those, and rebuild, you will “push”the errors out of your program.

Unit Tests (COMP1100: 10; COMP1130: 10)

How do you know that the program you’ve written is correct? GHC’s typechecker rejects a lot of invalid programs, but you’ve written enoughHaskell by now to see that a program that compiles is not necessarilycorrect. Testing picks up where the type system leaves off, and givesyou confidence that changing one part of a program doesn’t breakothers. You have written simple doctests in your labs, but largerprograms need more tests, so the tests you will write for thisassignment will be labelled and organised in a separate file from thecode.

Open src/ForestFireTest.hs. This file contains a couple of exampletest cases, written using a simple test framework defined insrc/Testing.hs. These files are heavily commented for yourconvenience.

You can run the tests by executing cabal v2-test. If it succeeds itwon’t print out every test that ran, but if it fails you will see theoutput of the test run. If you want to see the tests every time, usecabal v2-test --test-show-details=streaming instead.

Your Task

Replace the example tests with tests of your own. The tests that youwrite should show that the Haskell code you’ve written in Tasks 1-3is working correctly. In order to comprehensively test a program, all testablefunctions should be tested.

Hints

General Hints

• Try writing tests before you write code. Then work on your codeuntil the tests pass. Then define some more tests and repeat. Thistechnique is called test-driven development.

• The expected values in your test cases should be easy to check byhand. If the tested code comes up with a different answer, then it’sclear that the problem is with the tested code and not the testcase.

• Sometimes it is difficult to check an entire structure that’sreturned from one of your functions. Maybe you can compute somefeature about your result that’s easier to test?

• If you find yourself checking something in GHCi (i.e., cabalv2-repl comp1100-assignment2), ask yourself “Should I make thisinto a unit test?”. The answer is often “yes”.

• If you are finding it difficult to come up with sensible tests, itis possible that your functions are doing too many things atonce. Try breaking them apart into smaller functions and writingtests for each.

Technical Hints

• The assertEqual and assertNotEqual functions will not work onthe CodeWorld Picture type (it has no Eq instance). Therefore,it is not possible to write tests for renderForest.

• If you want to write tests about new types you have defined, addderiving (Eq, Show) to the end of the type definition, like this:

  data MyType = A | B | C deriving (Eq, Show)

• It is not possible to test for a call to error using the toolsprovided in this course.

Style (COMP1100: 10; COMP1130: 10)

“[…] programs must be written for people to read, and onlyincidentally for machines to execute.”

From the foreword to the first edition of Structure andInterpretation of Computer Programs.

Programming is a brain-stretching activity, and you want to make it aseasy on yourself as possible. Part of that is making sure your code iseasy to read, because that frees up more of your brain to focus on theharder parts.

Guidance on good Haskell style can be found in this course’s StyleGuide,the COMP1100 Peer-assisted-learning repository,and in lecturenotes.

Your Task

Ensure that your code is written in good Haskell style.

Technical Report (COMP1100: 20 marks, COMP1130 30 marks)

You should write a concise technicalreport explaining your design choices inimplementing your program. The maximum word count is 1250 forCOMP1100 students and 2000 for COMP1130 students.This is a limit, not a quota; concise presentationis a virtue.

Once again: These are not required word counts. They are the maximumnumber of words that your marker will read. If you can do it infewer words without compromising the presentation, please do so.

Your report must be in PDF format, located at the root of yourassignment repository on GitLab and named Report.pdf. Otherwise, itmay not be marked, or will be marked but with a penalty. You shoulddouble-check on GitLab that this is typed correctly.

The report must have a title page with the following items:

• Your name
• Your laboratory time and tutor
• Your university ID

Content and Structure

Your audience is the tutors and lecturers, who are proficient at programmingand understand most concepts. Therefore you should not, for example, wastewords describing the syntax of Haskell or how recursion works. After readingyour technical report, the reader should thoroughly understand what problemyour program is trying to solve, the reasons behind major design choices in it,as well as how it was tested. Your report should give a broad overview of yourprogram, but focus on the specifics of what you did and why.

Remember that the tutors have access to the above assignmentspecification, and if your report only contains details from it thenyou will only receive minimal marks. Below is a potential outline forthe structure of your report and some things you might discuss in it.

Note: COMP1130 need to include justification of or explanation of their chosenmodel.

Introduction

If you wish to do so you can write an introduction. In it, give:

• A brief overview of your program:
  • how it works; and
  • what it is designed to do.
• If you have changed the way the controls work, perhaps for an extension,or added something that may make your program behave unexpectedly,then it would be worth making a note of it here.

This section is particularly relevant to more complicated programs.

Analysis of your Program

The purpose of this section is to describe your program to the reader, both in detail and at a high level.

Talk about what features your program actually has. We know what we askedfor (the features in this document!), but what does your program actuallylet a user do? How does your program work as a whole?

How does it achieve this? Let us know how each individual function worksand how they work together to solve particular design goals.

As an example, you might have used a number of helper functions to achieve a particular design goal of ploting the deinsity of trees over time. If so, tell us what these functions are, what they do, and how they composeor otherwise work together to achieve this goal.

A successful report will demonstrate conceptional understanding of all relevantfunctions, and depicts a holistic view of program structure throughdiscussion of what it is and hour it works.

Rationale and Reflection

The purpose of this section is to describe the design decisions you madewhile writing the program, to the reader.

Tell us the reasoning behind the choices you detailed above.Tell us the assumptions you made about user behaviour.Why did you solve the problems the way you did?Why did you write the functions you wrote?Did you make any other assumptions?

For example:

“I implemented the checkFirst helper function after reading this blog post (citing the post as a reference), claiming that users of quadrant based drawing programs virtually always draw their first shape in the top-right quadrant. Deciding to use this as my baseassumption for user-behaviour, I decided to save on quadrant-dependent calculation of trigonometric ratios by always assuming the first shape is drawn in this quadrant. This in turn meant I needed a function to check if a shape was the first one drawn.”

This is a critical reflection not a personal one. You’re explainingthe justification and reasoning behind the choices you made.

A successful report will give a thorough explanation of the process followedto reach a final design, including relevant reasoning and assumptions / influences.

Testing

This purpose of this section is to give the reader confidence that yourprogram has been thoroughly tested.

Tell us how you tested the program as a whole to ensure correctness.Tell us in detail how you tested individual functions to ensure correctness.

For example:

“I drew all possible directions of the hypotenuse on the coordinate plane, to ensure that the isosceles, right-angled triangle was correctly drawing up, down, left, and right.”

Or:

“I wrote a unit testing helper function validateTriangles :: Shape -> Bool which returned True if, and only if the angles sum up to 360 degrees, for every triangle on the coordinate plane.”

A successful report will demonstrate evidence of a process that checked most, if not all, of the relevant parts of the program through testing. Such a reportwould combine this with some discussion of why these testing results proveor justify program correctness.

Style

A successful report should have excellent structure, writing style, and formatting. Write professionally, use diagrams where appropriate but nototherwise, ensure your report has correct grammar and spelling.

This is a list of suggestions, not requirements. You should onlydiscuss items from this list if you have something interesting towrite.

Things to avoid in a technical report

• Line by line explanations of large portions of code. (If you want toinclude a specific line of code, be sure to format as described inthe “Format” section below.)

• Pictures of code or your IDE.

• Content that is not your own, unless cited.

• Grammatical errors or misspellings. Proof-read it before submission.

• Informal language - a technical report is a professional document, and assuch should avoid things such as:

  • Unnecessary abbreviations (atm, wrt, ps, and so on), emojis, andemoticons; and
  • Stories / recounts of events not relevant to the development of the program.

• Irrelevant diagrams, graphs, and charts. Unnecessary elements willdistract from the important content. Keep it succinct and focused.

If you need additional help with report writing,ANU Academic Skillshave resources to help.

Format

You are not required to follow any specific style guide (such as APAor Harvard). However, here are some tips which will make your reportmore pleasant to read, and make more sense to someone with a computerscience background.

• Colours should be kept minimal. If you need to use colour, make sure it isabsolutely necessary.

• If you are using graphics, make sure they are vector graphics (that staysharp even as the reader zooms in on them).

• Any code, including type/function/module names or file names, thatappears in your document should have a mono-spaced font (such asConsolas, Courier New, Lucida Console, or Monaco)

• Other text should be set in serif fonts (popular choices are Times,Palatino, Sabon, Minion, or Caslon).

• When available, automatic ligatures should be activated.

• Do not use underscore to highlight your text.

• Text should be at least 1.5 spaced.

Communicating

Do not post your code publicly, either on Ed or via otherforums. Posts on Ed trigger emails to all students, so if bymistake you post your code publicly, others will have access to yourcode and you may be held responsible for plagiarism.

Once again, and we cannot stress this enough: do not post your codepublicly . If you need help with your code, post it privately to theinstructors.

When brainstorming with your friends, do not share code. Theremight be pressure from your friends, but this is for both your andtheir benefit. Anything that smells of plagiarism will be investigatedand there may be serious consequences.

Sharing concepts and sketches is perfectly fine, but sharing should stopbefore you risk handing in suspiciously similar solutions.

Some of the readings provided may have references to code - code copied fromthese sources will be considered plagiarism. (It also will be incorrect - thesereadings are provided for context, but are not the same as this assignment).

Course staff will not look at assignment code unless it is postedprivately in Ed, or shared in a drop-in consultation.

Course staff will typically give assistance by asking questions,directing you to relevant exercises from the labs, or definitions andexamples from the lectures.

Before the assignment is due, course staff will not give individualtips on writing functions for the assignment or how your code can beimproved. We will help you get unstuck by asking questions andpointing you to relevant lecture and lab material. You will receivefeedback on your work when marks are released.

Submission Checklist

Once you have finished your assignment, and preferably 24 hours priorto the deadline, you should make sure that:

• You have fully read and understand the entire assignment specification. See the “Overview of Tasks” section to check that you have completed alltasks.

• Your work has been pushed to GitLab. You can confirm that the latest versionof your code has been pushed to GitLab by using your browser to visithttps://gitlab.cecs.anu.edu.au/uXXXXXXX/assignment2, where XXXXXXXis your student number.

• Your program compiles and runs, including the cabal v2-test test suite.

• Your program works on the lab machines - if the program does notwork on the lab machines, it might fail tests used by theinstructors.

• You have proof-read and spell-checked your report.

• The report is in PDF format, located at the root of your project onGitLab and named Report.pdf. That capital R is important - Linuxuses a case-sensitive file system. Otherwise, it may not be marked.Check that this has been done successfully on Gitlab.

We recommend that you do not wait until you are finished to commit and push yourwork. Commit and push as you work, to reduce the risk of submission errors atthe last minute.

• Density - The density of ‘x’ in some set ‘xs’ is the number of elements oftype ‘x’ proportionally to the size of ‘xs’. For example, the density of“apple”s in this list of fruit: ["apple", "banana", "pear", "orange"]; is 1out of 4, or 0.25, while the density of “apple”s in this list:["apple", "apple", "apple", "apple"]; is 4 out of 4, or 1.

• Discrete - individually separate and distinct.

• Parsing - The processof analysing unstructured data – usually strings or binary data – andconverting it into a more structured form.