Fachrat Informatik - Forum

aber da gibt es n Gegenbeispiel. wenn du 2,-2 einsetzt bekommt du das gleche, als wenn man -2,2 einsetzt. Also zwei unterschiedliche Werte aus der Menge A durch die Funktion gejagt ergeben jeweils das gleiche in B. Also ist es NICHT bijektiv und somit nicht umkehrbar!

Quoted

Original von Markus
hey, wenn wir hier fertig sind, sind wir alle informathematiker!!!! Iss doch goil, ne!!!

Nee, dazu hättest du Mathematik Studienrichtung oder Nebenfach Informatik auf Diplom wählen müssen.
Dann hättest du auch 8V+4Ü SWS Mathe im ersten Semester zzgl. Inf I, Prog I und ETec I.

Zu f((x,y)):=(1,x+y):
Was will man da groß erklären? Es wird kurz erklärt was ein Tupel und was eine Abbildung ist und dann ist gut. Das Ding ist etwas wo du zwei Zahlen reinsteckst und wo dann zwei Zahlen rauskommen, wobei die erste Zahl immer 1 ist und die Zweite die Summe der beiden übergebenen.
Wenn man im ersten Semester etwas beweisen soll, nimmt man sich die Definition und rechnet durch bis man sieht, daß sie stimmt.
Wenn man etwas widerleden soll, sucht man ein Gegenbeispiel.
(Es kann natürlich auch sein, daß du das wirklich ohne : gemeint hast und daß das dann zwei Gleichungen in zwei Unbekannten darstellt)

Kann da nur zustimmen. Ist ja ok dass wir Mathe können müssen, aber dass wir selbst in Programmieren 1 nur mathematische Probleme lösen finde ich doch etwas ätzend. Grade in den ersten Semestern hätte man doch etwas "normalere" Sprachen nehmen können und Scheme später wenn sonst nicht mehr soviel Mathe drankommt (quasi um im Training zu bleiben).

Zur Aufgabe 2c: Beide Teilfunktionen nach nach dem Motto "z = x+y, t = 2x+3" aufschreiben, nach y auflösen und weitersehen was man machen kann (bleibt nicht viel aber wenn ich das jetzt auch noch schreiben würde wärs ja schon ne komplette Lösung). Haben auch mit 4 Mann eine halbe Ewigkeit an der Aufgabe gesessen bis wir den Ansatz hatten...

Ähm, und selbst trotz allem, dass wir eine Umkehrfunktion gefunden haben, muss das keine Funktion sein. Und ich sehe keine Möglichkeit bei r² zu beweisen, ob es extremstellen bzw Monotonieverhalten in der Originalfunktion gibt. Geschweige denn wie ich sowas ableiten soll um Extremstellen aufzuzeigen!

Quoted

Original von Markus
hey, wenn wir hier fertig sind, sind wir alle informathematiker!!!! Iss doch goil, ne!!!

Korrigiere: Elektromathematiker
SCNR

Quoted

Original von Markus
Das war auch nur Scherzhaft gem,eint, dass ich dazu besser Mathe-Inf studiert haette ist mir klar

Wie ich zeige, dass etwas nicht injektiv ist, ist klar, andersherum, wie ich zeige, dass es injektiv ist, angenommen ich habe eine bijektive Funktion, kannich nicht (kann ja nicht für jedes x-y-tupel testen). Ebenso nciht die surjektivität. Im rep. der höheren Mathematik macht man es auch nur mit Vorstellung, aber diese Tupe kann man sich ja nicht mehr so leicht abstrahieren.

Die Aufgaben sind f2,f3: R^2 -> R^2
f2((x,y))=(1,x+y) und f3((x,y))=(x+y,2x+3y)
untersuche nach bijektivität und surjektivität

Bei der ersten kann man Gegenbeispiele angeben (oder auch nicht, je nachdem wie die Bildmenge der Funktion definiert ist).

Bei der zweiten ist es etwas komplizierter. Injektivität zeigt man, indem man nachweist, daß es keine x1 <> x2 und y1 <> y2 gibt mit
f_3(x1, y1) = f_3(x2, y2).

Hier würde das zu folgenden Gleichungen führen:
x1 + y1 = x2 + y2 UND
2 * x1 + 3 * y1 = 2 * x2 + 3 * y2

Das kann man nun lösen und erhält ein entsprechendes Ergebnis.

Den Nachweis von Surjektivität führt man, indem man ein beliebiges Element der Bildmenge annimmt und nachweist, daß es dazu mindestens ein Original gibt.

Quoted

Original von cyber
Kann da nur zustimmen. Ist ja ok dass wir Mathe können müssen, aber dass wir selbst in Programmieren 1 nur mathematische Probleme lösen finde ich doch etwas ätzend. Grade in den ersten Semestern hätte man doch etwas "normalere" Sprachen nehmen können und Scheme später wenn sonst nicht mehr soviel Mathe drankommt (quasi um im Training zu bleiben).

Was sind denn "normalere" (und gut für die Lehre geeignete!) Sprachen?

Zum Thema Scheme kann ich nur mal wieder ein ganz altes (aber IMHO absolut treffendes) Zitat von Phil aus der Mottenkiste holen:

Quoted

Original von PhilRM
Wichtig ist bei Scheme vor allem, sich vor Augen zu führen, dass diese Sprache nicht mit Sprache á la C, Java und Pascal konkurriert.

Mit Scheme (bzw. LISP) löste bzw. löst man einfach ganz andere Probleme - dafür (und für Rekursionen der dritten Art ) ein Gefühl zu bekommen macht den Unterschied.

Finding the right tool for the right purpose - Aufgabe des Informatikers.

Btw: Den hohen Matheanteil finde ich vollkommen in Ordnung, ja sogar nötig. Informatik ist nun einmal traditionell ein Teilgebiet der Mathematik. Mathematische Methoden sind das Handwerkszeug eines Informatikers.

Quoted

Original von Joachim
Was sind denn "normalere" (und gut für die Lehre geeignete!) Sprachen?

Es soll ja noch Leute geben die meinen HTML sei eine leicht zu erlernende Programmiersprache

Ich persönlich bin ja für Assembler als Einsteigersprache. Da lernt man am besten kennen was ein Computer kann und was alles "syntaktischer Zucker" ist. Man lernt auch die Zusammenhänge zwischen Daten und den sie repräsentierenden Bytes im Speicher viel schneller. Z.Zt favorisiere ich in dieser Hinsicht den ARM.

Wenn man darauf aus ist eine Sprache zu wählen die fast keiner kann, könnte man Postscript nehmen. Ich wette die wenigsten haben schonmal in einer stackbasierenden Sprache programmiert. Schwer ist die auch nicht und bunte Bilder schafft man in einer Zeile Code.

Daß ab Prog 2 fast nur noch Java in der Vorlesungen verwandt wird, finde ich nicht so toll. OOP wird zwar immer bedeutender, aber Java hat mir zu viele Nachteile (Hat schonmal jemand die Destruktoren gesucht? Und die Performance...). Da wäre C++ besser.

Zu den Mathe Aufgaben:
Mein 2. LinA I Übungsblatt enthielt den Hinweis

Quoted

Es gilt (Vorlesung)
f injektiv <=> es gibt g : Y -> X mit g o f = id_X,
f surjektiv <=> es gibt g : Y -> X mit f o g = id_Y,
f bijektiv <=> es gibt g : Y -> X mit g o f = id_X und f o g = id_Y.

Davon sollte man die zweite Aussage aber noch beweisen.

Wenn man LinA I durch hat macht man diese Aufgaben indem man sich die Determinante der Matrizen dieser beiden Homomorphismen anguckt, also Ablesen und Kopfrechnen.

@Lucky: das ist Stoff von Analysis II

Quoted

Original von denial

Quoted

Original von Joachim
Was sind denn "normalere" (und gut für die Lehre geeignete!) Sprachen?

Ich persönlich bin ja für Assembler als Einsteigersprache. Da lernt man am besten kennen was ein Computer kann und was alles "syntaktischer Zucker" ist. Man lernt auch die Zusammenhänge zwischen Daten und den sie repräsentierenden Bytes im Speicher viel schneller. Z.Zt favorisiere ich in dieser Hinsicht den ARM.

Das geht IMHO schon wieder zu stark in Richtung Technische Informatik. Die Zeiten der maschinennahen Programmierung sind nun einmal vorbei (bis auf einige Ausnahmen selbstverständlich) -- solche Relikte gehören zu Recht nicht in Anfängervorlesungen. Als vertiefenden Kurs (also als Wahlfach) finde ich das hingegen sinnvoll, da es genau wie Du sagst, sehr gute Einblicke in die Arbeitsweise von Computern vermittelt.

Wenn Du Wert auf Assember-ähnliche Sprachen legst, könnte man auch eine Vorlesung auf MIX aufbauen. Aber auch das ist nicht wirklich leicht verständlich. Wer schon einmal einen Blick in "The Art of Computer Programming" geworfen hat, wird nachvollziehen können, was ich meine.

Der große Vorteil von Scheme ist einfach, daß die Syntax wirklich minimal ist und auch sonst nur wenige verschiedene Sprachkonzepte verwendet werden. Und da es in Programmieren I viel mehr auf das Verstehen des Codes und weniger auf das Auswendiglernen von Befehlen und sonstigen Sprachkonstrukten ankommt, ist Scheme dafür IMHO eine recht gute Wahl. Natürlich ist es gewöhnungsbedürftig, aber eine gewisse Eleganz ist dieser Sprache nicht abzusprechen.

Quoted

Wenn man darauf aus ist eine Sprache zu wählen die fast keiner kann, könnte man Postscript nehmen. Ich wette die wenigsten haben schonmal in einer stackbasierenden Sprache programmiert. Schwer ist die auch nicht und bunte Bilder schafft man in einer Zeile Code.

Auch nicht wirklich praxisnah und ziemlich kompliziert. Zum einen ist Postscript nicht als Programmiersprache konzipert und zum anderen mangelt es einfach an der praktischen Relevanz. Zudem findet man zu Postscript auch nicht wirklich gute Literatur -- die Spezifikation ist zwar frei erhältlich (hab ich hier sogar als Buch im Regal stehen, weil ich damit vor dem Studium mal kurz zu tun hatte), aber eignet sich zum Lernen ganz und gar nicht. Mit TeX kann man prinzipiell auch programmieren. Aber man läßt es lieber.

Quoted

Daß ab Prog 2 fast nur noch Java in der Vorlesungen verwandt wird, finde ich nicht so toll. OOP wird zwar immer bedeutender, aber Java hat mir zu viele Nachteile (Hat schonmal jemand die Destruktoren gesucht? Und die Performance...). Da wäre C++ besser.

Es ist ja gerade ein Design Goal, daß so etwas wie Destruktoren nicht benötigt werden. Auf diese Weise lassen sich Speicherlecks (die in C++ schon fast zum Alltag gehören) fast völlig vermeiden. Auch das Fehlen von Zeigern ist eine recht angenehme Sache. Natürlich lassen sich daher in Java einige "Optimierungstricks" nicht anwenden, aber auch die Zeiten derartiger Optimierungen neigen sich dem Ende. Die Hardware ist heutzutage einfach leistungsfähig genug. Daher kann man bei der Wahl der für ein bestimmtes Problem geeigneten Programmiersprache ohne Bauchschmerzen auch mal gegen Performance und für gute Konzepte entscheiden.

Und über die Performance von Java kann man so pauschal auch nicht urteilen. Für GUI-Anwendungen mag das stimmen, aber der ganze "Unterbau" von Programmen läßt sich in Java ähnlich schnell wie in anderen Programmiersprachen implementieren. Aber genaue Studien zu diesem Thema würden mich sehr interessieren. Die Artikel neulich in der c't waren ja nur ein grober Anfang.

Quoted

Original von Joachim
Es ist ja gerade ein Design Goal, daß so etwas wie Destruktoren nicht benötigt werden. Auf diese Weise lassen sich Speicherlecks (die in C++ schon fast zum Alltag gehören) fast völlig vermeiden.

Ich möchte hiermit nochmal an die Aufgabe aus Proggen 2 letztes Semester erinnern, wo wir eine Datei nach jeder Änderung flushen mußten, nur um sicher zu gehen, daß Sie am Ende den richtigen Inhalt hat.

Quoted

Original von Markus

Quoted

Original von denial

Es soll ja noch Leute geben die meinen HTML sei eine leicht zu erlernende Programmiersprache

Es soll ja Leute geben, die meinen html wäre eine Programmiersprache....

Es sollte ja Leute geben, die sogar in einem Forum alles nachquatschen .

Quoted

Original von denial

Quoted

Original von Joachim
Es ist ja gerade ein Design Goal, daß so etwas wie Destruktoren nicht benötigt werden. Auf diese Weise lassen sich Speicherlecks (die in C++ schon fast zum Alltag gehören) fast völlig vermeiden.

Ich möchte hiermit nochmal an die Aufgabe aus Proggen 2 letztes Semester erinnern, wo wir eine Datei nach jeder Änderung flushen mußten, nur um sicher zu gehen, daß Sie am Ende den richtigen Inhalt hat.

Weiß ich nichts drüber. Was war denn das für eine Aufgabe?

Es sollte eine Klasse gebastelt werden die das Interface Observer implementiert und die dadurch gemeldete Veränderungen an einem Objekt in einer Datei protokolliert.

Quoted

Original von denial
Es sollte eine Klasse gebastelt werden die das Interface Observer implementiert und die dadurch gemeldete Veränderungen an einem Objekt in einer Datei protokolliert.

OK. Verstehe das Problem aber trotzdem noch nicht. Da Java die meisten Ausgaben (u. a. aus Performancegründen) puffert, ist ein Flush fällig, wenn man keine Pufferung wünscht. So what?

Die Pufferung wurde von der Aufgabenstellung nicht verboten.
Das Problem das man mit Java dabei hatte war, daß die Aufgabenstellung keine Methode vorsah die am Ende des Programms aufgerufen worden wäre um die Datei zu flushen/schließen.
Gäbe es zuverlässige Destruktoren (bzw. in Java: "finalizer"), hätte man die Datei dort schließen können.
So mußte man die Pufferung (=Performance) opfern, weil die Macher der Sprache etwas so essentielles als deprecated bezeichnen.
Die Begründung dafür ist auch nicht gerade die beste. Von mir aus kann Java eine Exception schmeißen wenn nach dem Aufruf eines Destruktors neue, vom GC nicht löschbare Objekte im Speicher sind.

Das ist langsam ziemlich OT.