|
Size: 5108
Comment:
|
← Revision 25 as of 2022-10-11 14:38:15 ⇥
Size: 5674
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #acl Hannah Bast:read,write Niklas Schnelle:Patrick Brosi All:read | #acl Hannah Bast:read,write Patrick Brosi:read,write All:read |
| Line 3: | Line 3: |
| 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. | 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 (as is generally true for rules and regulations). |
| Line 7: | Line 7: |
| = Rules for the programming exercises = | = Rules for the programming exercise sheets = |
| Line 9: | Line 9: |
| '''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. | '''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, the 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 programming exercise sheets, but it will be more work (depending on the exercise sheet and your proficiency maybe even much more work). Other programming languages than the named three are not allowed. |
| Line 11: | Line 11: |
| '''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. | '''2. Submission''' The version relevant for grading is 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. |
| Line 13: | Line 13: |
| '''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. | '''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. |
| Line 15: | Line 15: |
| '''4. Uploading''' Please pay attention Achten Sie darauf, dass Sie keine unnötigen Dateien hochladen, zum Beispiel ''.pyc'' oder ''.o'' oder ''.class'' Dateien. Zu manchen Übungsblättern gehören (große) Datensätze. Diese dürfen erst recht nicht hochgeladen werden, sonst explodiert das SVN und wenn es ganz schlecht läuft das Universum. | '''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. EDIT 28.10.2019: Of course, small files used by unit tests can and should be uploaded. |
| Line 17: | Line 17: |
| '''5. Kompilieren''' Das ''compile'' target muss grundsätzlich fehlerfrei durchlaufen, sonst wird Ihr Code nicht korrigiert und es gibt keine Punkte. Grund dafür ist, dass nicht kompilierbarer Code sehr schwer zu durchschauen sein kann und dies unzumutbar viel Arbeit für die Tutor:innen wäre. Fragen Sie bei Problemen bitte rechtzeitg im Forum, siehe Punkt 9. | '''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. Note that although Python is interpreted, the ''compile'' target will check whether the code can indeed be interpreted. |
| Line 19: | Line 19: |
| '''6. Tests''' Wenn Tests vorgegeben sind, dürfen diese nicht verändert werden. Wird der Inhalt eines Tests geändert, gibt es für diesen Teil des Programms keine Punkte. Ausnahme sind kleinere syntaktische Änderungen aus guten Grund oder wenn der Fehler bei uns liegt. Schlägt ein Test fehl, gibt es für diesen Teil des Programms maximal 50% der Punkte. Sie können unsere Tests gerne um zusätzliche Testfälle erweitern, das ist aber kein Muss. | '''6. Tests''' If test are provided by us, you must not change them. If you change the contents of a test, you 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 your code fails a test, you will get at most 50% of the points for the corresponding part. So it's better to fail a given test than to wrongly modify it so that it passes. You are free to ''add'' more tests, but you don't have to. |
| Line 21: | Line 21: |
| '''7. Checkstyle''' Ihr Code sollte frei von ''checkstyle'' Fehler sein. Mit Checkstyle-Fehlern riskieren Sie einen Punktabzug bis zu 10% der Gesamtpunktzahl für eine Programmieraufgabe, bei sehr vielen Fehlern bis zu 20%. | '''7. Checkstyle''' Your code should be free from ''checkstyle'' errors. With checkstyle errors you risk a 10% point reduction, or up to 20% if there are 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. |
| Line 23: | Line 23: |
| '''8. Lesbarkeit''' Schreiben Sie modularen und verständlichen Code. Wenn ein Teil des Codes für sich alleine umfangreich bzw. komplex genug ist oder mehrfach benötigt wird, gehört er in eine eigene Funktion. Jedes Stück Code, dessen Funktionsweise sich nicht unmittelbar durch Lesen des Codes ergibt, sollte erklärt werden. Die Erklärung sollte kurz und aussagekräftig sein. Manchmal ist ein Beispiel nützlicher (und kürzer) als eine abstrakte Erklärung. Für unverständlichen Code riskieren Sie ebenfalls einen Punktabzug von bis zu 20%. | '''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. |
| Line 25: | Line 25: |
| '''9. Forum''' Wenn Sie ein Problem bei der Implementierung haben, suchen Sie ein paar Minuten (auf Google oder auch auf dem Forum, da wurden sehr viele Fragen schon mal gestellt) nach dem Fehler. Wenn Sie nicht fündig werden, fragen Sie gerne auf dem Forum, da wird Ihnen in der Regel schnell geholfen. Hier unsere [[AlgoDatSS2019/Forum|Anleitung für das richtige Fragen auf dem Forum]]. | '''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]]. |
| Line 29: | Line 29: |
| <p style="color: darkred"><b>10. Zusammenarbeit</b> Sie können gerne zusammen über die Übungsblätter nachdenken, aber der Code bzw. die Lösungen müssen zu <b>100% selber</b> 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. | <p style="color: darkred"><b>10. Collaboration</b> You are welcome to ''think'' about the exercise sheets together, but <b>the code must be written 100% by yourself</b>. Also partial copying of code – whether from another person, the master solution from a previous edition of the course, or the internet – counts as plagiarism with the corresponding consequences. You don't learn anything by copying. If you are a group of two with a joint subdirectory in our SVN (see <a style="color: darkred" href="https://daphne.informatik.uni-freiburg.de/ws1920/InformationRetrieval/svn/public/slides/lecture-01.pdf#page=6">Lecture 1, Slide 6</a>), you are treated as one person for the purposes of this rule (in particular, you have to upload only one submission and not two). |
| Line 32: | Line 32: |
| = Regeln für die theoretischen Aufgaben = | = Rules for the theoretical tasks = |
| Line 34: | Line 34: |
| 1. Für die Abgaben zu den theoretischen Aufgaben gilt Punkt 10 von der Liste oben sinngemäß. | 1. For the submissions for theoretical tasks, Item 10 holds correspondingly. |
| Line 36: | Line 36: |
| 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. | 2. The points are divided as follows: For a meaningful basic approach you get 40% of the points. For correctly worked out details you get 60% of the points. The reason for this division is that it's important to work out the details. A vague description of an idea is a start, but provides no certainty concerning correctness. |
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 (as is generally true for rules and regulations).
Rules for the programming exercise sheets
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, the 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 programming exercise sheets, but it will be more work (depending on the exercise sheet and your proficiency maybe even much more work). Other programming languages than the named three are not allowed.
2. Submission The version relevant for grading is 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. EDIT 28.10.2019: Of course, small files used by unit tests can and should be uploaded.
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. Note that although Python is interpreted, the compile target will check whether the code can indeed be interpreted.
6. Tests If test are provided by us, you must not change them. If you change the contents of a test, you 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 your code fails a test, you will get at most 50% of the points for the corresponding part. So it's better to fail a given test than to wrongly modify it so that it passes. You are free to add more tests, but you don't have to.
7. Checkstyle Your code should be free from checkstyle errors. With checkstyle errors you risk a 10% point reduction, or up to 20% if there are 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 instructions for properly asking questions on the forum.
10. Collaboration You are welcome to ''think'' about the exercise sheets together, but the code must be written 100% by yourself. Also partial copying of code – whether from another person, the master solution from a previous edition of the course, or the internet – counts as plagiarism with the corresponding consequences. You don't learn anything by copying. If you are a group of two with a joint subdirectory in our SVN (see Lecture 1, Slide 6), you are treated as one person for the purposes of this rule (in particular, you have to upload only one submission and not two).
Rules for the theoretical tasks
1. For the submissions for theoretical tasks, Item 10 holds correspondingly.
2. The points are divided as follows: For a meaningful basic approach you get 40% of the points. For correctly worked out details you get 60% of the points. The reason for this division is that it's important to work out the details. A vague description of an idea is a start, but provides no certainty concerning correctness.