README 20 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501
  1. ********************************************
  2. * DO NOT SEND EMAIL TO THE TEACHING STAFF. *
  3. ********************************************
  4. If it is related to the course, please post it in Blackboard -
  5. Discussion. Use email for only private issues. The teaching staff
  6. will ignore email that is related to the course and not private. You
  7. will not receive any response.
  8. =====================================================================
  9. In this assignment, we will compute several properties of an array of
  10. integers.
  11. PLEASE NOTE:
  12. (1) You should only modify the file answer01.c
  13. (2) You can modify this file however you want, including adding additional
  14. functions. (This is true for all assignments.)
  15. (3) You must only submit the file answer01.c for marking
  16. (4) Parts of the assignment have been written for you, but these parts do
  17. not appear in the file answer01.c. Please browse through these files
  18. (pa01.c and pa01.h).
  19. You should not add the main function to answer01.c. Doing so will
  20. guarantee that your will program fail and you will definitely receive
  21. zero. The main function is already provided in pa01.c.
  22. If a file is marked as "do not modify this file", you should not
  23. modify this file in any circumstance. Modifying this file will
  24. guarantee that your program will fail and you will definitely receive
  25. zero. If you believe there are mistakes in the code given to you,
  26. please post your questions, corrections, or suggestions in Blackboard
  27. Discussion.
  28. This assignment includes many pieces of useful information and you
  29. will learn these pieces in the coming weeks. Do not worry if you do
  30. not understand everything in the first week. Focus on writing the
  31. functions in answer01.c. If you have taken the prerequisite CS 159,
  32. you should have no problem filling the code for these functions.
  33. If you find this assignment unreasonably difficult, you do not have
  34. the necessary background taking ECE 264. It is advised that you take
  35. CS 159 first. If you cannot do this assignment easily, you are likely
  36. to find ECE 264 unreachable.
  37. If you need help, please visit the intructors' or the teaching
  38. assistants' office hours.
  39. DO NOT SEND EMAIL. Post your questions in Blackboard - Discussion.
  40. ================================
  41. = Getting the Assignment Files =
  42. ================================
  43. Assignments will be distributed to you via the version control system
  44. "git". This very useful program will allow the teaching staff to make
  45. modifications to assignments as problems arise, and then distribute
  46. them to all of you. Version control will show exactly which lines have
  47. been changed. As students, you will have "read-only" access to the
  48. assignment repository. The URL for the repository is:
  49. https://github.com/yunghsianglu/ECE264Assignments.git
  50. Use the "clone" command to get a copy of the files:
  51. git clone https://github.com/yunghsianglu/ECE264Assignments.git
  52. Once you have a copy of the files, you can "cd" into the repository
  53. and use the "pull" command to get the latest version of the assignment
  54. files:
  55. cd ECE264Assignments
  56. git pull
  57. Sometimes mistakes are found in the assignments. The instructor will
  58. tell you to obtain a new version and you should type the command
  59. git pull
  60. ======================
  61. = Assignment Details =
  62. ======================
  63. In this assignment we shall:
  64. * add all elements in an array of integers
  65. * determine whether any element in the array is a negative number
  66. * determine whether the elements' values are always increasing
  67. This program has the following files:
  68. (1) pa01.h A header file
  69. (2) pa01.c A C file that contains "main", the program entry point
  70. (3) answer01.c A C file (only edit and submit this file)
  71. (4) Makefile A file that "make" uses to build and test your solution
  72. To use the makefile, you need to cd into the assignment directory and
  73. type "make" in the Linux terminal. Type "make help" for a list of
  74. options. For example:
  75. ECE2644Assignments/PA01 > make help
  76. After you finish this program, upload answer01.c to Blackboard and
  77. submit it. Your program /must/, *must*, !!MUST!! compile against the
  78. original assignment files (pa01.c and pa01.h), otherwise you will get
  79. zero. NO EXCEPTIONS.
  80. You MUST test your program on native Linux (not cygwin, not
  81. Virtualbox, not MinGW ...). There were many cases when students
  82. incorrect programs appeared working on cygwin or virtualbox.
  83. =========================
  84. = Using Version Control =
  85. =========================
  86. For PA03, PA04, and PA05, you will need to show evidence that you are
  87. using version control. You can use the version control tool of your
  88. preferrence; however, we recommend that you learn git. The evidence
  89. required is the log file of your commits.
  90. Version control is not required for PA01; however, it is worth
  91. figuring this out as soon as possible. Version control is an
  92. *essential* tool for computer programming in groups, and is also
  93. highly recommended when working on single person projects as
  94. well. Spend the time now to understand what you are doing, and that
  95. will *save* you a lot of time later.
  96. Conceptually there are two repositories to deal with: the repository
  97. where you do your work (you control everything), and the repository
  98. that the teaching staff use to distribute assignments to you. (URL
  99. given above.) This second repository will hence-forth be called
  100. "R-problem". The repository that you control will be referred to as
  101. "R-answer". These *must* be in /separate/ directories in your account.
  102. If you mix the two repositories, you run the risk of erasing your work
  103. when the instrutor asks everyone in the class to do "git pull".
  104. Do not modify anything in R-problem because it is read-only for
  105. you. When you need to do a "git pull", git will want to delete all
  106. your changes! IF YOU MODIFY R-problem, YOUR CODE WILL BE ERASED WHEN
  107. YOU DO "git pull".
  108. To set up R-answer, you will need to do some reading on the
  109. Internet. There are many useful tutorials, and a bit of jargon that
  110. you must master. The Internet contains everything you need to know.
  111. Below is the URL for the official git tutorial. It is a starting point
  112. for your learning of git:
  113. http://git-scm.com/docs/gittutorial
  114. Every non-trivial project is managed by version control.
  115. Once you have done "git pull" (or git clone for the very first time)
  116. in R-problem, you will need to immediately copy the problems to
  117. R-answer. Then, write your programs in R-answer, and remember to
  118. commit and push often. It is advised that you COMMIT AND PUSH AT LEAST
  119. ONCE A DAY. Since this is a one-person project, it is perfectly
  120. acceptable if you commit and push every hour or every ten minutes.
  121. In the rare cases when you are suspected of copying code, the commit
  122. log can be used as definitive evidence that you are developing your
  123. solutions step by step. However, if you commit only once before
  124. submission, you will not be able to use your commit log as evidence
  125. for your defence.
  126. ECE 264 requires that you submit source-control logs for only three
  127. assignments (PA03-PA05). After these three assignments, you are
  128. expected to continue using version control by yourself, even though it
  129. is no longer a requirement for grading.
  130. You can use the version control system of your preference (git, svn,
  131. cvs...) as long as you can provide evidence that you are using
  132. version control.
  133. IF YOU DO NOT PROVIDE EVIDENCE OF USING VERSION CONTROL in PA03-PA05,
  134. YOUR SUBSEQUENTIAL ASSIGNMENTS WILL NOT BE GRADED AND YOU WILL
  135. DEFINITELY RECEIVE F IN THIS COURSE. THERE IS NO EXCEPTION.
  136. =================================================================
  137. How does computer grading work?
  138. Your program will be graded in three ways:
  139. * whether the outputs are correct
  140. * whether the program has invalid memory accesses
  141. * whether the program has any warning messages, use global or
  142. static variables ...
  143. The first is determined by using the "diff" command. The outputs of
  144. your program is compared with the expected outputs. Your program's
  145. outputs are stored in the "outputs" directory. The expected outputs
  146. are stored in the "expected" directory. You can use this command to
  147. see whether they are different
  148. diff outputs/output0 expected/expected0
  149. We use "diff -w"; "-w" ignores the difference caused by space.
  150. The second is determined by the reports produced by valgrind. In the
  151. outputs directory, you can see files called "valgrind-log.." At the
  152. bottom of each file, there is a line called "ERROR SUMMARY". Your
  153. program should have no error. If there is an error (or errors),
  154. valgrind reports which line causes the error.
  155. The third will be checked by another program (not given to you).
  156. Since you can see the warning messages and you know whether you are
  157. using global or static variables, it is unnecessary to give you the
  158. checker.
  159. =================================================================
  160. In ECE 264, you should ALWAYS turn on gcc warning messages by adding
  161. -Wall -Wshadow
  162. after gcc.
  163. These warning messages have helped many students discover problems in
  164. their programs. Thus, you should always use them. You will lose 1
  165. point for each warning message (25% of each assignment). This will be
  166. strictly enforced and there is absolutely no exception in any case.
  167. =================================================================
  168. You should not have space in a file name. The ISO 9660 standard for
  169. file names and directory names does not allow space. There are many
  170. cases when space in file (or directory) names crashed systems. If
  171. your submission includes a file whose name contains space, it very
  172. likely that you will receive zero in the assignment.
  173. =================================================================
  174. This assignment asks you to submit only one file. Later assignments
  175. will ask you to submit zip files that include mulitiple files. It is
  176. your responsibility submitting all needed files. If you fail to
  177. submit all needed files, and your program does not work, you will
  178. receive zero. The teaching staff will NEVER accept any late
  179. submission for any reason. DO NOT ASK FOR AN EXCEPTION.
  180. The teaching staff will NEVER go to your computer or your account for
  181. grading. Do not tell the teaching staff that "I have not changed the files
  182. since the submission deadeline."
  183. Your assignment scores depend ONLY on what you submit.
  184. No late submission is accepted for any reason. There is absolutely no
  185. exception whatsoever. The instructor will not respond to any request
  186. for extension.
  187. DO NOT ASK FOR AN EXTENSION.
  188. The instructor may give the whole class extensions. The teaching
  189. assistants are not authorized to give extensions.
  190. =================================================================
  191. It is irrelevant whether your program runs correctly on YOUR computer.
  192. If your program is wrong (crashes, produces incorrect output, leak
  193. memory, etc.) during grading, you will lose points.
  194. The assignments will be graded on ECN-managed Linux computers. You
  195. should test your programs on these computers. Some incorrect programs
  196. may crash on Linux but they do not crash in MacOS os Windows (using
  197. cygwin or virtualbox). It is known that valgrind (memory error
  198. detector) does not work on MacOS.
  199. Please do not tell the teaching staff tHat "My program is perfect on
  200. my machine." This statement is irrelevant in grading.
  201. =================================================================
  202. You should never use global variables or static variables. You should
  203. never use goto or assert in your programs. The instructor will
  204. explain the reasons.
  205. You will receive zero if your program includes
  206. * one or more global variables
  207. * one or more static variables
  208. * one or more goto
  209. * one or more assert
  210. Global constants are acceptable; static functions are acceptable.
  211. ====================================================================
  212. Some books encourage readers to use assert, something like this
  213. assert(x > 0);
  214. This will stop the program if x is not positive. These books claim
  215. that by stopping your program, you will be able to debug.
  216. These books are wrong.
  217. Why?
  218. Why would you use assert? You use assert because you are not so sure.
  219. If you are 100% certain that x is positive, you would not use assert.
  220. You would not waste time typing that line. Would you write this?
  221. x = 1;
  222. assert(x > 0); /* assert immediately after x is assigned to 1 */
  223. Probably not. Why not? You are certain that x is positive.
  224. Thus, you use assert only if you have doubt. Here comes the problem.
  225. If you use assert and the condition is false, the program stops.
  226. Imagine that you are writing a program for a large system. Something
  227. unexpected happens and you stop the program! There is no chance to
  228. handle the problem. This can easily cause a disaster.
  229. As an example, a company writing flight control software found someone
  230. wrote this
  231. assert(distance of two airplanes > safe distance)
  232. In one of their tests, the company intentionally simulated the
  233. situation when two airplanes were too close and a collison was
  234. possible. This assert statement caused the flight control system to
  235. crash. It took several minutes to reboot and restart the system. The
  236. two planes collided in this simulation.
  237. Why did the software develop use assert? Because a book said so.
  238. Many of you will have chance developing safety-critical systems.
  239. Assertion failure could create significant damage, injury, or loss of
  240. lives.
  241. If you are responsible software developer, you need to detect and
  242. HANDLE problems. DO NOT STOP THE PROGRAM. This is an important
  243. concept. Stopping the program is irresponsible.
  244. When C was designed, the concept of exception handling was not
  245. invented yet. Newer languages, such as C++, Java, and Python, have
  246. exception handling.
  247. Do not use assert. It is an irresponsible way of writing programs.
  248. ====================================================================
  249. You are encouraged to talk to the teaching staff if you have any
  250. questions. When you ask questions, please be as precise as possible
  251. and provide as much information as possible. Many students ask
  252. questions by saying, "My program does not work. Can you help me?"
  253. This sentence provides no information and additional information is
  254. needed before anyone can help you.
  255. The teaching staff will help you but you need to provide more
  256. information. When you ask questions, please provide the following
  257. information:
  258. * Which machine do you use?
  259. * What is the output of gcc?
  260. * Does the program generate any output on the screen or saved in a
  261. file?
  262. * Does the program terminate abnormally (such as segmentation fault,
  263. bus error)?
  264. * Does the problem appear consistently, every time you run the
  265. program?
  266. * Have you initialized all variables?
  267. * What does valgrind say about your program?
  268. * What is the call stack shown in gdb (or ddd)?
  269. * Are the indexes for arrays valid? Remember that if an array has n
  270. elements, the valid indexes are 0 to n - 1; n is an INVALID index.
  271. One goal of ECE 264 is to teach you to ask the right questions and
  272. more important answer your own questions. Before you ask any
  273. question, please answer the questions above first.
  274. Also, please remember that "My program produces correct outputs" does
  275. **NOT** mean the program is correct. It is possible that your program
  276. has some hidden problems. There are many cases that those hidden
  277. problems are discovered in grading. "My program produces correct
  278. outputs" is **NOT** a reason to believe that your program is correct.
  279. The common problem is that the program has invalid memory accesses or
  280. reading uninitialized memory.
  281. Consider an analogy. You drive a car and run red lights. You do not
  282. hit anyone and reach your destination. Does this mean running red
  283. lights is acceptable? No. If you run red lights often, someday you
  284. will hit someone.
  285. Please remember that correct outputs does **NOT** mean your program is
  286. correct.
  287. ====================================================================
  288. Computer programs follow logic flows. Thus, understanding logic is
  289. important. Consider the following code
  290. if (x == 0)
  291. {
  292. y = 1;
  293. }
  294. If y is not 1, x cannot be zero.
  295. However, if y is 1, x may and may not be zero. Why?
  296. x = 1;
  297. y = 1;
  298. if (x == 0)
  299. {
  300. y = 1;
  301. }
  302. Even though x is not zero, y still can be one. Some students believe
  303. that x must be zero if y is one. This is incorrect.
  304. Another important concept is the difference between causality and
  305. correlation. If your program always have x is zero and y is one at
  306. the same time, does this mean the program has this statement?
  307. if (x == 0)
  308. {
  309. y = 1;
  310. }
  311. No. It is possible that
  312. if (z == 0)
  313. {
  314. x = 0;
  315. y = 1;
  316. }
  317. In this case, x does not make y to be one.
  318. ====================================================================
  319. Many students try to debug their programs by testing. Testing can
  320. only tell you something is wrong. Testing will not tell you what is
  321. wrong and how to fix it.
  322. READ YOUR PROGRAMS
  323. Sometimes students are surprised why the teaching staff can find and
  324. fix problems so quickly. The teaching staff read code carefully. If
  325. you want to write correct programs, read your code carefully after you
  326. type in a few lines.
  327. Do not copy-paste code. You may find that some assignments ask your
  328. programs to do something similar but slightly different. Copy-paste
  329. code seems a good and natural way to handle this situation. However,
  330. copy-paste code is the invitation of endless debugging. You will very
  331. likely forget to make necessary changes. Even worse, if you find a
  332. problem in one place, you will likely forget to fix the problem in
  333. mulitiple places.
  334. You should assume that you will make mistakes and try to develop a
  335. strategy to discover and correct mistakes.
  336. Do not write a lot of code at once. Write a small section of code and
  337. make sure it is correct, before you write more code. If you take a
  338. small step each time, you can finish the assignments much faster.
  339. If you rush, you will spend more time.
  340. ====================================================================
  341. All test cases are given to you and Makefile explains how your
  342. programs are graded. You are responsible making your programs work.
  343. Do not expect any point if your program does not work. You will NOT
  344. get 90% points if you write 90% code. If you write 90% code, it is
  345. very likely that you will receive no point at all.
  346. You will lose most points (possibly all) if your programs have invalid
  347. memory accesses during grading. It does not matter whether your
  348. programs "work" when you test them. If your programs have problems in
  349. grading, you will lose most points. Again, it is your responsibility.
  350. The teaching staff grade programs based on the functionalities, not
  351. sympathy; the teaching staff will not negotiate scores. If you want
  352. to receive high scores, make sure the submitted programs work.
  353. You will *definitely* receive zero if your program has one or several
  354. syntax error reported by gcc. There is no exception to this rule in
  355. any circumstance. Even if your programs would work correctly after
  356. adding a semicolon, you will still receive zero. Remember that it is
  357. your responsibility submitting a correct program.
  358. The teaching staff will never modify your program for grading in any
  359. circumstance. Your score depends on what is submitted.
  360. ====================================================================
  361. Some students ask the instructor, "What do you want me to do?" The
  362. students misunderstand the role of the instructor. You learn FOR
  363. YOURSELF, not anyone else. Ask yourself "What should I do to learn
  364. better?"
  365. ====================================================================
  366. ECE 264 is a course for you to start writing non-trivial programs. In
  367. many cases, you should design the programs before you start writing
  368. code. If you want to spend less time in the programming assignments,
  369. think carefully and design on paper before writing code. If you start
  370. writing code without clear understanding and careful design, you will
  371. likely spend many more hours than your classmates.