Typos revised

hw8/task1/README.md

@@ -10,8 +10,8 @@
         - [-s Flag](#s-flag)
         - [-w Flag](#w-flag)
         - [Weitere Options](#weitere-options)
-    - [-help Ausgabe](#help-ausgabe)
-    - [Command timings](#command-timings)
+    - [`-help` Ausgabe](#help-ausgabe)
+    - [Command `timings`](#command-timings)
     - [Tests](#tests)
     - [Laufzeit Messungen (im --release Mode)](#laufzeit-messungen-im---release-mode)
 
@@ -19,38 +19,38 @@
 
 Transformieren Sie Ihr Binary Projekt in ein Library Projekt, wobei zusätzlich
 ein CLI Programm bereit gestellt wird. Dieses hat seinen Ursprung in `main.rs`.
-Nach der Transformation soll **cargo run** die Funktionalität Ihres hw7/task1
+Nach der Transformation soll **cargo run** die Funktionalität Ihres `hw7/task1`
 Programms aufzeigen, und **cargo test** durchläuft die Unit Tests der Library.
 Erstellen Sie auf Basis der bisherigen "unit_test" Datei eine `tests/task1.rs`
-Datei, die die pub Funktionen der Library testet.
+Datei, die die `pub` Funktionen der Library testet.
 
 ### Idiomatischer Code
 
-In dieser Aufgabe sollte Sie besonderen Wert auf Idiomatischen Rust Code legen.
+In dieser Aufgabe sollten Sie besonderen Wert auf Idiomatischen Rust Code legen.
 Auch sollte Ihre `main.rs` Funktion möglichst übersichtlich bleiben. Lagern Sie
 somit Funktionen in Module Ihrer Library oder für Ihr Binary aus. In den
-vorherigen Homeworks haben Sie dazu alle nötigen Kniffe kennen gelernt, die Sie
+vorherigen Homeworks haben Sie dazu alle nötigen Kniffe kennengelernt, die Sie
 nun in Ihrer Lösung verwenden.
 
 ### `ANSWERS.md`
 
 In den Aufgaben werden immer wieder Fragen gestellt. Geben Sie die Antworten
-dazu in der Datei `ANSWERS.md`. Eine kurze aber nachvollziehbare Erklärung (eigene
-Worte, kein Code) ist ausreichend. Aufbau und Struktur Ihrer `ANSWERS.md` ist
-Ihnen überlassen. Überzeugen Sie uns Tutoren mit einer klaren und verständlichen
-Struktur (und korrekter Formatierung). 
+dazu in der Datei `ANSWERS.md`. Eine kurze aber nachvollziehbare Erklärung
+(eigene Worte, kein Code) ist ausreichend. Aufbau und Struktur Ihrer
+`ANSWERS.md` ist Ihnen überlassen. Überzeugen Sie uns Tutoren mit einer klaren
+und verständlichen Struktur (und korrekter Formatierung). 
 
 Kommentieren Sie Ihren Code. Beschreiben Sie in eigenen Worten (kein Copy/Paste
 von Code oder Code Kommentaren) in `ANSWERS.md`, welche Arten der
-Synchronisation und Kommunikation (ausser MPSC) Sie einsetzen und wie Sie die
+Synchronisation und Kommunikation (außer MPSC) Sie einsetzen und wie Sie die
 maximale Performance erreichen. Wichtig: Kommentare gehören in den Code,
 Erklärungen in die `ANSWERS.md`.
 
-Ihre Erklärung muss nachvollziehbar sein, ohne weitere eigenen Recherchen. Zum
-Beispiel die Antwort: "In der Implementierung wird die Systemfunktion
-_dummy_bla_blub()_ benutzt" ist NICHT ausreichend. Ausreichend wäre: "In der
-Implementierung wird die Systemfunktion _dummy_bla_blub()_ benutzt, die die
-Uhrzeit seit Einschalten des Rechners als UTF String liefert."
+Ihre Erklärung muss nachvollziehbar sein, ohne dass wir Tutoren Recherchen
+starten müssen. Zum Beispiel die Antwort: "In der Implementierung wird die
+Systemfunktion _dummy_bla_blub()_ benutzt" ist NICHT ausreichend. Ausreichend
+wäre: "In der Implementierung wird die Systemfunktion _dummy_bla_blub()_
+benutzt, die die Uhrzeit seit Einschalten des Rechners als UTF String liefert."
 
 Messungen müssen auf Ihrem Container durchgeführt werden.
 
@@ -65,7 +65,7 @@ Erweitern Sie das CLI Programm mit einem weiteren **OPTIONALEN** Parameter:
 System und ermittelt die Anzahl der vorhandenen CPUs für 'threads'. Geben Sie
 den Parameter an, können Sie diesen Wert somit 'überschreiben'.
 
-Benutzen Sie dafür die externe [Crate sys-info](<>). Was ist der Unterschied
+Benutzen Sie dafür die externe [Crate sys-info](). Was ist der Unterschied
 zwischen einer logischen und einer physikalischen CPU?
 
 ```text
@@ -92,8 +92,8 @@ SUBCOMMANDS:
 
 ### Flag _verbose_
 
-Mit dem Parameter _-v_, _-vv_ oder _-vvv_ usw. lassen sich unterschiedliche
-viele Zusatzinformationen ausgeben. 
+Mit dem Parameter _-v_, _-vv_ oder _-vvv_ usw. lassen sich unterschiedlich viele
+Zusatzinformationen ausgeben. 
 
 Ohne die Angabe von verbose reduzieren Sie bitte die Ausgaben auf:
 
@@ -130,12 +130,12 @@ Consumer" Lösung an. Viele Producer suchen nach dem Hash. Die zu untersuchende
 'Menge' an Zahlen muss dazu geeignet auf alle Threads verteilt werden. Der
 Producer, der ihn findet, sendet den Hash an den Consumer.  
 
-Die Rust Standardbibliothek bietet dafür die [MPSC](<>) Synchronisationsprimitive
-an. Einen ähnlichen Mechanismus haben Sie bereits mit der Pipe kennen gelernt. 
+Die Rust Standardbibliothek bietet dafür die [MPSC]() Synchronisationsprimitive
+an. Einen ähnlichen Mechanismus haben Sie bereits mit der Pipe kennengelernt. 
 
-Findet einer der Producer das Ergebnis, so sender er dies dan den Consumer. Der
+Findet einer der Producer das Ergebnis, so sendet er dies an den Consumer. Der
 Consumer hat dann die ruhmreiche Aufgabe, den Hash ausgeben zu dürfen und
-beendet dann das Programm. 
+beendet das Programm. 
 
 #### -s Flag
 
@@ -212,7 +212,7 @@ Number: 567621 --> hash: b6bea2a40ed1bd6d9999b2232072092f3df0e02c4b507aa3ad94736
 Wird das Flag '-v' mit angegeben, so summiert der Consumer Thread die einzelnen
 Suchzeiten der Producer Threads, sowie die insgesamt durchgeführten Loops zur
 Suche. Überlegen Sie sich dazu, wie Sie die nötigen Informationen im Consumer
-von den Producern erfahren. Eine Ausgabe der Ergebnis könnte folgendermassen
+von den Producern erfahren. Eine Ausgabe der Ergebnis könnte folgendermaßen
 aussehen:
 
 ```text
@@ -240,19 +240,20 @@ Suche anhand einzelner Ergebnisse. Welche (ungefähre) Abhängigkeit der Laufzei
 von der Anzahl der Threads können Sie im --release Mode bestimmen? 
 
 Nutzen Sie das Unix Tool **time**, um zusätzliche Ausgaben über die Laufzeit
-Ihres Programms zu erhalten (Antworten in die Datei `ANSWERS.md`). Von Interesse
-sind nur Ihre --release Zeiten:
+Ihres Programms zu erhalten. Von Interesse sind nur Ihre `--release` Zeiten:
 
+Die folgenden Fragen sollen Ihnen als Beispiel Ihrer Diskussion dienen, erheben
+aber keinen Anspruch auf Vollständigkeit: 
 -   Wie ist die Ausgabe von **time** zu interpretieren, wenn mehrere Threads
     laufen?
--   Welche unterschiedlichen Ergebnisse erhalten Sie bei der Option timings? Wie
-    stehen diese im Zusammenhang mit den Ergebnissen von **time**.
--   Welche Quantitative Auswirkungen hat die Synchronisierung (Warum)? 
--   Wie verhält sich die Performance, wenn die von Ihnen zusätzlichen Parameter
-    (falls vorhanden) zur Optimierung der Performance variiert werden?
-
-[Crate clap]: https://docs.rs/clap/
-[Crate sha2]: https://docs.rs/sha2/
-[Crate time]: https://docs.rs/time/
-[Crate sys-info]: https://docs.rs/sys-info/
+-   Welche unterschiedlichen Ergebnisse erhalten Sie bei der Option `timings`?
+    Wie stehen diese im Zusammenhang mit den Ergebnissen von **time**?
+-   Welche quantitativen Auswirkungen hat die Synchronisierung (Warum)? Welche
+    Auswirkungen haben Ihre zusätzlichen Parameter?
+-   Wie variieren `-s` und `-w` die Messungen? 
+
+[Crate clap]: https://docs.rs/clap/ 
+[Crate sha2]: https://docs.rs/sha2/ 
+[Crate time]: https://docs.rs/time/ 
+[Crate sys-info]: https://docs.rs/sys-info/ 
 [MPSC]: https://doc.rust-lang.org/std/sync/mpsc/