Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Rechnerübung MexHat
Hallo,
leider haben wir festgestellt, dass auf den Unix/Solaris Kisten im CIP Pool die Funktion MexHat, geplottet vom -5e-3 bis 5e-3 gar nicht wirklich komisch aussieht. Das liegt daran, das der Compiler die Funktion optimiert. Wer also sehen will, wie es wirklich komisch aussieht, soll seine MexHat::eval wie folgt implementieren:
float eins_m_cos = 1.0f - cosf(x);
float eins_d_xx = (1.0f) / (x*x);
float result = eins_m_cos * eins_d_xx;
return result.
Gruss, Jochen
Mensch, jetzt hast du die Loesung rausgerueckt!!!111111111111!!!
Muss man das unbedingt sehen? 
:rolleyes:
Ich hätte auch noch ne kleine Frage zu MexHat. Und zwar zu evalToFile() bezogen auf das Beispiel m.evalToFile(“mexHat.txt”, -10, 10, 200):
Im Header heißt es: “Wertet die Funktion ‘numEvals’ Mal auf dem Intervall [x0:x1] aus”
Müsste man dann also beginnend bei -10 pro Schritt 20/199 hoch zählen um im Intervall [-10, 10] auf genau 200 Abtastungen zu kommen? So versteh ich das jetzt momentan, allerdings wären das ziemlich unschöne Werte.
Oder bin ich da gerade viel zu penibel und es ist okay wenn wir pro Schritt um 0,1 hoch zählen dann aber auf 201 Abtastungen kommen?
Danke schonmal!
so ziemlich jeder mit dem ich gesprochen hab hat genauso gemacht, also einfach 201 schritte… denk mal das ist in ordnung… das sollte ja wohl auch nicht die schwierigkeit bei der aufgabe sein;)
Ich sehs schon kommen: “Person x hat von Person y abgeschrieben - 0 Punkte” 
Also imho waere es gerechtfertigt bei allen die 201 Schritte machen Punkte abzuziehen - sorry - aber es ist einfach mal falsch. Es soll numEvals mal ausgewertet werden - dann macht man das halt - ist doch ziemlich egal ob da “gerade / schoene” Werte rauskommen.
Pics or it didn’t happen - bei mir liefern (nach Kompilieren auf faui06c) anscheinend „alle“ Implementationen das gleiche optische Resultat. .oO(Vielleicht mal mit double precision vergleichen… hmmm).
Leider befuerchte ich das auch - da der verlangte Code an vielen Stellen nicht gerade massiv viele Permutationen zulaesst. Da muss man sich ja teilweise schon absichtlich Sachen einfallen lassen damit es Unique wird. Vor allem wird wohl mit Tool ™ automatisch verglichen; wenn es das Tool ist auf das schon in GdA geschworen wurde - dann Prost Mahlzeit. Viele der verlangten Operatoren sind einfach quasi Einzeiler und da bei Tool ™ die Nameswahl von Variablen etc. egal ist wirds eine Menge false positive Matches geben - zumindest auf grossen Abschnitten des Codes. Ich mein, prima, bei den for loops koennte man einfach mal ueber alle erdenklichen Moeglichkeiten permutieren - dann wird man schon unter den Schwellwert kommen - hoffentlich.
TODO:
- for Loops umbauen - partiell while benutzen - das wird lecker.
- nicht immer Iteratoren benutzen sondern auch mal noch ekelhaftere Konstrukte mit wilden Countern und schickem indizierten Zugriff!
- Branching umbauen.
Nachtrag:
Wie sollen wir mit der Polstelle umgehen? Den Wert zurueckgeben den der Graph suggeriert? 
Ja das mit der Polstelle hab ich mal spontan nach meinem Geschmack gemacht ;D
Aber das mitm Abschreiben… Wayne! Wenn mir einer vorwirft ich hätte abgeschrieben, werde ich doch wohl genug Gegenargumente finden, wenn es wirklich mein Werk ist. Da kann mir kein hässliches Tool auch nur annähernd was erzählen wollen. Da wird dann kurz diskutiert, die Diskussion gewinne ich und Feierabend!
You’re welcome
alles was sinnvoll ist ist willkommen
Streber würden hier über den Satz von de L’Hospital nachdenken
Ich hoffe doch dass die AlgoKS Leute so schlau sein werden wie die AUD’ler das entsprechend in den Aufgaben zu berücksichtigen…
ACK- Dank der unendlichen Macht von WolframAlpha - ein total unerwartetes Ergebnis!