Homework 1: Tabulating a function y=f(x)
For homework I, you will have to model an algorithm in UML, write a corresponding program in C and then write a report on it. The task is to solve a function y = f(x) within the limitations specified and display the results as a table. Some hints about aligning it can be found from printf tips example.
The program will get the initial data from the keyboard (entered by the user) as real numbers!
|Argument (xi)||Function value yi=f(xi)|
From your personal variant you will find the formulas for both xi and yi.
Function value should only be shown if the value exists. If the value cannot be calculated for the given x or is a complex number, You can choose to display “missing” or “complex”. If you wish, you are free to calculate the imaginary numbers and display them as well. Regardless of the variant, you will need to find up to 20 results.
You will have to write a detailed report on the solution you made. The report must be well structured and detailed. The quality of the report is a part of the grade.
Report template (MS Word)
The report must be written based on the IT department’s guidelines and formatting for thesis writing.
Link to the guidelines: https://haldus.taltech.ee/sites/default/files/2021-04/FIT_Author_Guidelines_ENG.pdf
We have also made an adjusted template for you to work form. You can find it here: mall_en_pr1_hw1.dotx
The template contains styles which follow the formatting requirements, use them!
The structure in the template can be adjusted . It’s also recommended to add (sub)headings as you see fit to create a better stucture.
The template contains comments underneath the headings to guide you on what it’s expected to contain.
Generic template (MS Word, OpenOffice)
If you wish to use a generic template and adjust it from scratch, you can find them here: http://www.tud.ttu.ee/im/Aila.Lainurm/ITT_Autorikomplekt/
Generic template (LaTeX)
For those who wish to write the report in LaTex, there is a generic template, available here: https://gitlab.cs.ttu.ee/thesis/latex-template
Since this is a generic template, look through the requirements what needs to be written in the report (e.g. from the word template or the following paragraph).
- Title page
- Declaration of originality
- List of abbreviations and terms (can be omitted if not present)
- Table of contents
- List of figures and tables (can be omitted if not present)
- Task description
- Function analysis
- Description of the solution
- A write up on the solution. Use the key points brought out in the template! The length must be at least 3 / 4 of a page, at maximum 2 pages. The description must be well structured, use tables, lists and other elements. It should not be a wall of text!
- An algorithm of the program modelled as a UML activity diagram.
- References (can be omitted if not present)
- Screen capture(s) of the working program
- Screen captures should illustrate various situations that you program can handle, as well as the normal behavior.
- Screenshots can be added as an appendix or embedded within the write up of the solution – in this case you can extend the length by the amount of pictures.
Common issues with the report
This is a list of commonly made mistakes when writing the report
- The title page is accurate. You need to specify to where you are submitting this report, not where you are studying! At minimum, the name of the university and the institute of the person who this report is intended for.
- You used the styles in the report as well as the automatically generated table of contents, figures, tables and references.
- There are no blank pages or headings.
- All headings are followed by text. A heading that only contains an image or a table isn’t enough – it must be explained.
- Tables and figures need to be referenced in the text. If necessary, additional comments can be added.
- The description is formatted properly – good structure, use of subheadings, tables, lists etc. to improve on readability. It shouldn’t be a wall of text.
- Algorithm must be readable. It’s recommended to export a vector graphic image and embed it in the document.
- Your report can only include snippets of the code and only when it is necessary to illustrate a part of the description. Such code must be aligned to the left, indented and use a monospaced font.
- The document includes screenshots of the program running in various situations. Do not include a screenshot of your entire desktop or your code in a text editor.
- Code must adhere to the practices taught in the class so far.
- Must be written according to either C90 or C99 standard.
- Must use standard libraries.
- Must be not be operating system dependent.
- Must not use GOTO statements.
- Must not use global variables.
- Must not have any unused components in the code (e.g. libraries, variables).
- All of the x and y values must be stored inside an array or arrays of the suitable type. The output must use those arrays.
- At maximum, must show 20 results.
- All inputs (except for the step count) must support floating point values.
- Code must adhere to the coding style, including (but not limited to):
- Every file includes the authors name, dates and a short description of the file.
- The code is commented.
- Variable name must be self-explanatory and written in the correct style.
- The code is indented, lines are within the maximum allowed length and spaces are put where required.
- No magical numbers are found within the code
- Algorithm conforms to the UML activity diagram requirements
- Algorithm is divided into swim lanes based on logical blocks.
- Algorithm shows the indexing of the arrays.
Some checks to avoid common issues:
- Every decision node has a condition specified.
- All of the possible exits from a decision node are marked (e.g. in what condition will the program follow each path – true/false, const values for switch cases etc).
- Every path from a decision node is viable – the conditions must be real, so that the flow can actually enter them.
- If multiple paths merge (following a decision node), a merge node must be used.
- No dead ends – You have to have a way to the exit from all of the nodes, actions etc.
- No infinite loops – It must always be possible to exit them.
Deadlines, points and bonuses
The first homework is valued at 15p.
A complete homework must be submitted no later than 17.10.2021 23:59:59 (local time)
Every week passed the deadline removes 1p from the maximum possible score. The late cost is capped at 5p, meaning if you submit 7 weeks late, you can still get up to 10p.
Submitting before deadline gives you the right to earn up to 2 bonus points.
- Submitting before 06.10.2021 23:59 – 2p
- Submitting before 12.10.2021 23:59 – 1p
To be eligible for the bonus points, all of the requirements must be met. Partial or buggy solutions will not get bonus points. If the submitted homework fails to fulfill the requirements on first submission, bonus points will be forfeit.
If we have questions about the submitted homework or are not sure about the original author of this work, we will grade this with 0p. In this case, the work must be defended.
If it becomes necessary, we will enforce the rules and guidelines of [Procedure for processing a student’s violation of academic practices and contemptible behavior in the School of Information Technologies]
We will only accept Your homework until the lockdown date (check introduction slides). Past that, submitting your homework will not be possible.
Submitting Your work
You need to submit the documentation in Adobe PDF format and all the necessary code files to compile your program.
Naming schema: HW1_<studentcode>_<firstname>_<lastname>
Submitting is done using Moodle:
Result and feedback
After your work has been checked and graded, you will see the result on Moodle with feedback written as a comment. All submissions that lose points will receive feedback. Feedback can also exist on submissions that receive the maximum points.