#acl Hannah Bast:read,write Patrick Brosi:read,write All:read Please read this page very carefully and completely before you start working on the first exercise sheet. The rules are valid for all exercise sheets of this course. Not knowing them will not protect you from consequences. <> = Rules for the programming exercises = '''1. Programming language''' We recommend ''Python'' for several reasons. First, we will also use Python in the lectures. Second, the code templates and unit tests will be provided in Python. Third, ease of use of Python will allow us to focus on the actual topic of this course: information retrieval. If you prefer, you may also use ''Java'' or ''C++'' for the exercise sheet, but it will be more (and depending on the exercise sheet and your proficiency maybe much more) work. Other programming languages then the named three are not allowed. '''2. Submission''' We will grade the last version which you have uploaded (committed) to our SVN before the deadline. You can upload as many intermediate versions (including for backup purposes) as you like. Submissions after the deadline or via email will not be accepted, so please start working on the sheets in time. '''3. Makefile''' Each submission must have a ''Makefile'' (for Python and C++) or a ''build.xml'' (for Java) with the targets ''compile'', ''checkstyle'', ''test'' and ''clean''. This was explained and demonstrated in Lecture 1 and an example file for each language is available under ''public/lecture-01/''. Our continuous build system (Jenkins) will check automatically after each commit, whether the targets run through without errors. You can also initiate a check manually. '''4. Uploading''' Please take care that no unnecessary files are uploaded, for example ''.pyc'' or ''.o'' or ''.class'' files. Many exercise sheets work with a dataset and some of the datasets are quite large. You must not upload these datasets to our SVN or terrible things will happen. '''5. Compilation''' The ''compile'' target must run through without errors, otherwise your exercise sheet will not be graded and you get zero points. The reason is that it requires an unreasonable effort from a tutor to understand and check code that does not even compile. If you encounter compilation problems, which you cannot fix yourself, please ask on the forum, see Item 9. '''6. Tests''' If test are provided by us, you must not change them. If you change the contents of a test, wou will not get any points for the corresponding part of your code. Exceptions are small and purely syntactic changes or if we have made a mistake. If you code fails a test, you will get at most 50% of the points for the corresponding part. You are free to ''add'' more tests, but you don't have to. '''7. Checkstyle''' You code should be free from ''checkstyle'' errors. with checkstyle errors you risk a 10% penalty, or up to 20% if there a lot of these errors. Please note that checkstyle errors are easy to fix because the error messages from the checkstyle scripts are very concrete. '''8. Readability''' Please write modular and easily comprehensible code. If a part of your code is large or complex enough or it is used in several places, it belongs into an own function. If the functionality of a code block is not obvious, there should be a comment explaining it. Explanations should always be concise and comprehensible. Often, an example is easier to understand (and shorter) than an abstract explanation. If you write incomprehensible code, you risk a 20% point reduction. '''9. Forum''' If you encounter any problems with your code, first try to find a solution yourself. Very often, a Google search of the error message leads you to a solution quickly. However, don't spend too much time on such problems: if you can't resolve a coding problem yourself after, say 5-10 minutes, don't hesitate to ask on the forum. Here are [[AlgoDatSS2019/Forum|instructions for properly asking questions on the forum]]. {{{ #!html

10. Zusammenarbeit Sie können gerne zusammen über die Übungsblätter nachdenken, aber der Code bzw. die Lösungen müssen zu 100% selber geschrieben werden. Auch das teilweise Übernehmen von Code, egal ob von einer anderen Person, der Musterlösung aus einer vergangenen Vorlesung oder aus dem Internet, gilt als Täuschungsversuch, mit den entsprechenden Konsequenzen. Wir müssen das so deutlich sagen, weil es in der Vergangenheit immer wieder vorgekommen ist. Man lernt nichts, wenn man Code bzw. Lösungen von anderen übernimmt und es ist unfair gegenüber dem Großteil der Teilnehmer:innen, die sich ehrlich Mühe geben. }}} = Regeln für die theoretischen Aufgaben = 1. Für die Abgaben zu den theoretischen Aufgaben gilt Punkt 10 von der Liste oben sinngemäß. 2. Für die Punktevergabe gelten folgende Leitlinien. Für eine sinnvolle Grundidee bzw. einen sinnvollen Ansatz gibt es 40% der Punkte. Für die ordentliche Ausarbeitung gibt es 60% der Punkte.