|
|
|
|
| Zitat von OliOli
Ok, wer macht schnell ein Tool, das auf Gund dieser Glaubensfragen Gemeinsamkeiten und Unterschiede zwischen den Pimp Usern aufzeigt?
/e: Uni, Linux, Emacs, DIE Nutella mit Butter, mercurial, oop wenn es passt, von hinten durchgreifen, Ärzte > Hosen
| |
Tool? Mit GUI oder ohne?
|
|
|
|
|
|
Haskell
|
Definieren Sie eine Funktion grouEquals, die aufeinanderfolgende gleiche Elemente in eine Liste gruppiert und als Ergebnis eine Liste von Listen zurueckgibt.
Beispiel: [1,1,2,1,2,2,1,1,1] -> [[1,1],[2],[1],[2,2],[1,1,1]]
Der Tutor hats uns empfohlen, ne Hilffunktion zu verwenden, die er mit uns erarbeitet hat. Aber bei der Hauptfunktion komm ich irgendwie auf keinen gruenen Zweig, hat da jemand nen Tipp? So sieht der Code derzeit aus:
|
Code: |
takeEqual :: Int -> [Int] -> [Int]
takeEqual _ [] = []
takeEqual n (x:xs) | n == x = x : takeEqual n xs
| otherwise = []
groupEquals :: [Int] -> [[Int]]
groupEquals [] = []
groupEquals (x:xs) = takeEqual x xs : groupEquals xs |
|
Mein Problem ist, dass ich nicht weiss, wie ich mit den beiden Ergebnisfaellen der takeEqual Funktion umgehen soll. Entweder sie spuckt eine gefuellte Liste aus, dann pack ichs so wie es ist an die Liste, oder aber sie spuckt ne Leere Liste aus, dann muesste ich jedoch das Element, nach dem ich gesucht habe als einelementige Liste an die Hauptliste packen. Muss ich dafuer wirklich mit Guads/Case/If-Then Verteilern ran?
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von MCignaz am 20.07.2011 21:48]
|
|
|
|
|
|
Ich kann leider keine Haskell-Syntax, aber das Problem das du beschreibst kannst du ganz einfach lösen:
|
Code: |
groupEquals (x:xs) = (x : takeEqual x xs) : groupEquals xs
|
|
(das x ist ja in takeEqual nicht mehr drin)
Dein Problem ist eher, dass beim rekursiven Aufruf die Elemente von takeEquals aus xs nicht entfernt worden sind. Da kommt also momentan wenn ich mich nicht täusche sowas raus:
[1, 1, 1] -> [[1, 1, 1], [1, 1], [1]]
e2/
Hier hab ich die Funktion mal in Scala geschrieben, vielleicht hilft dir das weiter:
|
Code: |
def pack[A](l: List[A]): List[List[A]] = {
def R(f: List[A], l: List[A]): List[List[A]] = (f, l) match {
case (ys, Nil) => ys :: Nil
case (Nil, x :: xs) => R(List(x), xs)
case (y :: ys, x :: xs) => if (x == y) R(x :: y :: ys, xs)
else (y :: ys) :: R(List(x), xs)
}
R(Nil, l)
}
|
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von B0rG* am 20.07.2011 21:57]
|
|
|
|
|
|
Leider kann ich dir mit dem Haskell Problem nicht so recht weiterhelfen, aber ich muss mal loswerden, dass ich die Vorlesung zu funktionaler Programmierung echt interessiert fand (bei uns wurde aber Scala als Programmiersprache genutzt) mal ein anderer Weg zu programmieren im Gegensatz zum objektorientierten Ansatz. Die Artikel auf Wikipedia zur Theorie hinter (Lambda-Kalkül, Kombinatoren, usw.) waren aber teilweise recht unverständlich, die wurden wohl von Mathematikern geschrieben unsere Vorlesung war bei der Theorie aber auch nicht viel besser..
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von mc.smurf am 20.07.2011 21:55]
|
|
|
|
|
|
| Zitat von Rufus
| Zitat von Renga
| Zitat von Rufus
Ich raffs trotzdem nich ganz.. was dürft ihr zusätzlich benutzen?
| |
Steht nix dabei. "So wenig wie moeglich".
| |
Und wieso hängst du dann nich einfach nen Dekoder vor den D-FF? Als Eingänge J, K, Output vom D-FF. Da drin die Zustandstabelle eines JK-FF abbilden und den Ausgang an den D-FF legen.
// wobei die Aufgabe ziemlich bedeppert wäre, wenn das ne gültige Lösung ist
| |
Falls es dich noch interessiert:
Mit nem 4x1 MUX vor dem Flipflop, und ein bisschen rumgespiele welche Werte wohin geschaltet werden, funktionierts.
|
|
|
|
|
|
|
Das war ja meine Aussage..
Aber ich seh jetzt keinen didaktischen Nutzen in der Aufgabe. Auf die Weise bekommt du alles mit allem hin..
// aber danke für das "follow up"
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Rufus am 20.07.2011 22:13]
|
|
|
|
|
|
| Zitat von B0rG*
Ich kann leider keine Haskell-Syntax, aber das Problem das du beschreibst kannst du ganz einfach lösen:
|
Code: |
groupEquals (x:xs) = (x : takeEqual x xs) : groupEquals xs
|
|
(das x ist ja in takeEqual nicht mehr drin)
Dein Problem ist eher, dass beim rekursiven Aufruf die Elemente von takeEquals aus xs nicht entfernt worden sind. Da kommt also momentan wenn ich mich nicht täusche sowas raus:
[1, 1, 1] -> [[1, 1, 1], [1, 1], [1]]
e2/
Hier hab ich die Funktion mal in Scala geschrieben, vielleicht hilft dir das weiter:
|
Code: |
def pack[A](l: List[A]): List[List[A]] = {
def R(f: List[A], l: List[A]): List[List[A]] = (f, l) match {
case (ys, Nil) => ys :: Nil
case (Nil, x :: xs) => R(List(x), xs)
case (y :: ys, x :: xs) => if (x == y) R(x :: y :: ys, xs)
else (y :: ys) :: R(List(x), xs)
}
R(Nil, l)
}
|
|
| |
Danke fuer die Hilfe, allerdings seh ich bei dem Code nicht wirklich durch. Du hast dort mit Case Anweisungen gearbeitet, woran ich auch schon gedacht hatte. Also z.B. liefert takeEqual eine leere Liste, rufe x : grouEquals xs auf. Dann jedoch wirds schwierig beim naechsten Fall. Liefert takeEqual naemlich eine Liste mit Inhalt, weiss ich nicht, wie ich diesen "wegspeichern" kann, da ein erneutes Aufrufen von takeEquals ja bereits den naechsten Listenkopf abtrennt.
|
|
|
|
|
|
|
Deswegen arbeitet R mit 2 Listen. Die cases entsprechen in Scala dem was du in Haskell mit mehreren Definitionen untereinander machst - sind also einfaches Pattern matching.
Die Funktion ist nicht tail-Rekursiv (ja, ich war zu faul ).
Die Idee ist, dass immer gleiche Elemente von der rechten Liste in die linke geschaufelt werden bis ein ungleiches oder das Ende der Liste kommt.
Die cases:
case (Nil, x :: xs) Ist der "Einstiegspunkt". Wird grade nichts geschaufelt, wird das erste Element geschaufelt. (Den Fall hätte man sich auch sparen können)
case (y :: ys, x :: xs) Es wird grade geschaufelt (die linke Liste hat mindestens ein Element) und in der rechten Liste sind noch Elemente. Sind x und y gleich wird y in die linke Liste geworfen und weitergesucht. Sind x und y nicht gleich ist die Gruppe aller Elemente gleich y abgeschlossen und sie wird an die Gruppierung der Restliste gehängt.
case (ys, Nil) Die Restliste ist leer also geben wir die Liste mit den gerade geschaufelten Elementen zurück.
Wirklich zusammengebaut wird die Liste von Listen im else . Und ohne ein if-else wirst du nicht auskommen glaube ich.
Den ganzen aufwand muss man Treiben, weil ich grade keine schöne Möglichkeit sehe sonst die Restlisten zu verwalten.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von B0rG* am 20.07.2011 23:17]
|
|
|
|
|
|
Ah ok damit probier ich mal rum.
Anderes Problem. Ich hab einen type namens "Tupel" definiert als (Int, Int) und eine Funktion die aus zwei Listen mit Ints eine Liste mit Tupeln macht. Jetzt soll ich eine Funktion definieren, die das ganze wieder auseinander nimmt. Dabei hab ich Probleme mit der Signatur.
|
Code: |
type Tupel = (Int, Int)
myZip :: [Int] -> [Int] -> [Tupel]
myZip (x:xs) (y:ys) = (x,y) : myZip xs ys
myUnzip :: [Tupel] -> [Int] -> [Int]
myUnzip ((x,y):(xs,ys)) = [] [] |
|
Da gibts Beschwerden, weil die letzte Zeile nicht stimmt. Ich hab ueberhaupt keinen Plan wie ich das sonst ausdruecken soll.
|
|
|
|
|
|
|
Hier ist eine Variante von pack die bisschen näher an dem sein sollte, was man von dir erwartet (Sehr explizit hingeschrieben und vielleicht etwas länger als nötig):
|
Code: |
def pack2[A](l: List[A]): List[List[A]] = {
def take(pred: A => Boolean, l: List[A] ): (List[A], List[A]) = l match {
case Nil => (Nil, Nil)
case (x :: xs) => if (pred(x)) {
take(pred, xs) match {
case (y, z) => (x :: y, z)
}
}
else (Nil, x :: xs)
}
if (l.isEmpty) Nil
else {
val (p, n) = take (_ == l.head, l)
if (n.isEmpty) List(p)
else p :: pack2(n)
}
}
|
|
---
myUnzip :: [Tupel] -> ([Int], [Int])
ist denke ich eher das was du meinst. So wies bei dir dasteht bildest du ein [Tupel] und ein [Int] auf ein [Int] ab.
Hier bietet sich zur Implementierung wohl ein Fold an.
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von B0rG* am 21.07.2011 1:51]
|
|
|
|
|
Framework die vierte
|
So, gestern war die nächste Sitzung. Wir wollten ja die Anforderungen formulieren, endete damit das 2 der 5 Entwickler sich Anforderungen aus dem Internet geladen haben, einer gar nichts hatte. Da ich ja schon tiefer in der Materie stecke waren meine Anforderungen natürlich detailierter.
Dann kriegte ich zuhören, dass man meine Anforderungen doch überspringen könne, weil ich viele Komponenten genannt habe. Sowas wie Zugriffmechaniken, Paginator, Formularklassen usw. die hätten ja eh alle Frameworks.
Dann wollte einer der Kritiker sich ins Symfony einlernen, plötzlich wollte er das gestern nicht mehr. Ihn haben angeblich die Argumente überzeugt. Somit bleiben 0 Entwickler die sich gegen das Zend aussprechen.
Dann wurd ich sauer und hab die vollgemotzt. Der springende Punkt ist, dass er die ganze Zeit am meckern war das Zend zu kompliziert ist. Das war der Hauptpunkt der angeführt wurde, aber der ist immernoch nicht widerlegt. Nach rechts und links schaut sich jetzt keiner mehr um, aber die Kritikpunkte bleiben. Ich weiß ganz genau das ich in einem halben Jahr die Diskussion wieder führen darf.
Spacken, allesamt!
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Gore am 21.07.2011 10:08]
|
|
|
|
|
|
Jetzt weiß ich wieder, warum wir nachher ne Deppen-Liste hatten, die genau solche Leute beinhaltet mit detailierter Beschreibung, die den Eintrag in die Deppen-Liste rechtfertigt.
Eine Handvoll Leute hatte Zugang zum Deppenlisten-SVN und bevor man sich eine Gruppe für irgendwas suchen musste, wurde auf die Liste geschaut und möglichst danach gewählt. Das hat einem schon so viel Ärger erspart, klasse
|
|
|
|
|
|
|
| Zitat von klmann
Jetzt weiß ich wieder, warum wir nachher ne Deppen-Liste hatten, die genau solche Leute beinhaltet mit detailierter Beschreibung, die den Eintrag in die Deppen-Liste rechtfertigt.
Eine Handvoll Leute hatte Zugang zum Deppenlisten-SVN und bevor man sich eine Gruppe für irgendwas suchen musste, wurde auf die Liste geschaut und möglichst danach gewählt. Das hat einem schon so viel Ärger erspart, klasse
| |
Wieso hatte ich so eine Idee nicht VOR dem Programmierpraktikum? Werd ich bei uns definitiv mal einführen (müssen).
|
|
|
|
|
|
|
Nach vier (4!!) Monaten habe ich endlich den bug in meiner Simulation gefunden und die Ergebnisse stimmen mit denen unseres Doktoranden überein.
Und es war - natürlich - so simpel und zugleich dumm.
|
|
|
|
|
|
|
| Zitat von OliOli
Nach vier (4!!) Monaten habe ich endlich den bug in meiner Simulation gefunden und die Ergebnisse stimmen mit denen unseres Doktoranden überein.
Und es war - natürlich - so simpel und zugleich dumm.
| |
Das ist immer so... hab letztens aus versehen ne Variable überschrieben (MATLAB) und mich stundenlang gefragt, wieso das Ding nicht konvergiert
Was wars denn?
|
|
|
|
|
|
|
Periodische Randbedingungen, kürzester Abstand zwischen zwei Punkten.
x1-x2 = dx
if(dx > halbe systemgrösse)
dx -= systemgrösse
ich habe nicht systemgrösse sondern systemgrösse/2 abgezogen.
Das komische ist, dass ich beim Suchen bestimmt 1000 mal die Funktion gecheckt hab, und es ist mir nie aufgefallen. Gnah.
Interessanterweise hatte ich immer nur einen kleinen offset zu den richtigen Ergebnissen, daher hab ich den Fehler an ganz anderer Stelle vermutet.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von OliOli am 21.07.2011 13:54]
|
|
|
|
|
Lineare Algebra Aufgaben mit Lösungen
|
Hat hier wer viele Aufgaben zur Linearen Algebra mit Lösungen? Wäre super!
|
|
|
|
|
|
|
|
|
|
|
Informatik. Aber da tut sich afaik nicht allzu viel.
Gern gesehen sind Aufgaben zu: (orthogonale, orthonormale) Basen, Abbildungsmatrizen, lineare Abbildungen, Kern, Bild, Beweise, Eigenwerte/-räume, inverse/diagonale Matrizen, sonderbare LGS etc. pp
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Gepan.3dsvs.com am 21.07.2011 15:00]
|
|
|
|
|
|
Meine LA
Viel Spass. Und bei uns unterscheiden sich die verschiedenen LA-Kurse doch ziemlich.
|
|
|
|
|
|
|
Du bist ein Schatz. Danke.
|
|
|
|
|
|
|
| Zitat von Gepan.3dsvs.com
Du bist ein Schatz. Danke.
| | Da schließe ich mich mal an. Noch 7 Wochen bis zur Klausur
|
|
|
|
|
|
|
Noch 5 Tage.
|
|
|
|
|
|
|
ich brauch mal jemanden mit photosphop skills der mir
auf das einen Sombrero (mexican hat) drauf shopt....
kann ruhig komplett uebertrieben gross sein
aber sollte halt reinpassen.
|
|
|
|
|
|
|
Noch 4 5 Tage bis zur Klausur, fang morgen an zu lernen. Danke für die LA-Aufgaben, hab noch nicht reingeguckt aber ist sicher großartig. Ich werd unsere Übungen auch nochmal alle lösen, die kann ich dann gerne auch reinstellen, für alle die später schreiben. Themen sind die gleichen wie schon gesagt.
|
|
|
|
|
|
|
| Zitat von con_chulio
ich brauch mal jemanden mit photosphop skills der mir
auf das einen Sombrero (mexican hat) drauf shopt....
kann ruhig komplett uebertrieben gross sein
aber sollte halt reinpassen.
| |
komm irgendwer wird das doch koennen, bitte
|
|
|
|
|
|
|
Du bist hier wirklich im falschen Thread. Frage mal im "Informatiker helfen PC Neulingen".
|
|
|
|
|
|
|
| Zitat von OliOli
Periodische Randbedingungen, kürzester Abstand zwischen zwei Punkten.
x1-x2 = dx
if(dx > halbe systemgrösse)
dx -= systemgrösse
ich habe nicht systemgrösse sondern systemgrösse/2 abgezogen.
Das komische ist, dass ich beim Suchen bestimmt 1000 mal die Funktion gecheckt hab, und es ist mir nie aufgefallen. Gnah.
Interessanterweise hatte ich immer nur einen kleinen offset zu den richtigen Ergebnissen, daher hab ich den Fehler an ganz anderer Stelle vermutet.
| |
Wah, sowas hatte ich auch, das sollte dx/dt stehen und stattdessen stand da dt/dx. das war echt übel besonders da beides ungefähr in der gleichen Größenordnung war und das Ergebnis nicht unbedingt falsch war, nur nicht so gut wie möglich.
|
|
|
|
|
|
|
| Zitat von OliOli
Nach vier (4!!) Monaten habe ich endlich den bug in meiner Simulation gefunden und die Ergebnisse stimmen mit denen unseres Doktoranden überein.
Und es war - natürlich - so simpel und zugleich dumm.
| |
Ja Simulieren macht schon spaß
Ich hab in meinen Simulationen nen Effekt, den mein Betreuer recht seltsam findet, aber dies scheint gerade der entscheidene Effekt zu sein, der alles erklärt
Ich simuliere Teilchenkollisionen und soll erklären, warum sich irgendwelche Verteilungen verschieben, dabei vergleiche ich quasi die Reaktion auf Quarkniveau, mit Partonschauer und Hadronisierung und am ende noch ne Detektorsimulation.
Und so wie es aussieht, ist Gluonenabstrahlung NACH der Reaktion total irrelevant. nur die Abstrahlung vorher macht schon alles.
|
|
|
|
|
|
|
Ich versteh kein Wort.
/E: Natürlich muss das ganz oben hin.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von horscht(i) am 22.07.2011 0:50]
|
|
|
|
|
Thema: pOT-Informatiker, Mathematiker, Physiker VI ( Nur für echte PIMPs ) |