|
|
|
|
Oh mein gott, oh mein gott, oh mein gott....
meine Chefin hat gerade gemeint, als wir so ein bisschen ueber was ich schon gemacht habe und was die Plaene nach 2013* sind, als abschluss Satz gemeint: Naja ein frueherer Abschluss, vor ende der drei Jahre waere jetzt ja auch nicht vekerht, vorallem kann man sich das bei dir vorstellen.
*happy happy joy joy*
*Der LHC laeuft erst 2015 wieder an und ende 2013/anfang 2014 sollen die ganzen Paper mit dem kompletten LHC Run 1 Datensatz rauskommen.
/e
wir leben ja schon in 2013, nicht 2012
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von con_chulio am 02.07.2013 14:09]
|
|
|
|
|
|
Speed-Promotion.
|
|
|
|
|
|
C++: Werte von Pointer/Array
|
Moin. Nochmal ne 0815 Frage:
(rot = lösung)
Ich hatte das auch so. NUR: px hatte ich auf 100, also der Adresse zu x[0] und x[0] auf 5.5. Habe das auch mit nem Programm getestet und er hatte für x[0] auch 5.5 ausgegeben. Demnach kann ja '/' nicht stimmen. PX zeigt ja auf den Anfang des Array bzw. die Adresse des 1. Elements, oder nicht? Demnach schreibt er an die Stelle von x[0] den Wert. PX kann ja schlecht den Wert davon haben. Demnach ist die Lösung falsch? Klärt mich auf! Danke <3
|
|
|
|
|
|
|
double *px=x
Der Pointer px zeigt an die Addresse, die x darstellt. Das SOLLTE eigentlich gar nicht gehen, weil double ja kein Pointer ist. Fehlt da ein &?
|
|
|
|
|
|
|
| Zitat von csde_rats
double *px=x
Der Pointer px zeigt an die Addresse, die x darstellt. Das SOLLTE eigentlich gar nicht gehen, weil double ja kein Pointer ist. Fehlt da ein &?
| |
x ist ein Array, falls übersehen. Array und Pointer sind "ähnlich" zu einander in C++. (x[2] == *(xptr+2) ) z.b.
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Gepan.3dsvs.com am 02.07.2013 16:54]
|
|
|
|
|
|
Ah fuck das py=&y daneben hat mich vergessen lassen, dass es x[2] ist. Ja dann passt das.
double x[2], y=2.0
double *px=x // = &x[0]
double *py=&y
x[1] = *py+1 // = (*py)+1 = 3.0
*px = 5.5 // (*(&x[0])) = x[0] = 5.5
Endstand:
py = &y = 116
px = &x[0] = 100
y = 2.0
x[1] = 3.0
x[0] = 5.5
Ich ziehe B und sage die Lösung ist falsch. 5.5 in einem 4 Byte breiten Speicherbereich, wo doch nur 8 Byte Doubles benutzt werden, ergibt eh keinen Sinn.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 02.07.2013 16:58]
|
|
|
|
|
|
| Zitat von csde_rats
double *px=x
Der Pointer px zeigt an die Addresse, die x darstellt. Das SOLLTE eigentlich gar nicht gehen, weil double ja kein Pointer ist. Fehlt da ein &?
| |
denk dir double* px = x
und das geht doch, da x auch ein pointer auf Double ist, als array
me so slow... sorry
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Ballardbird_Lee am 02.07.2013 17:00]
|
|
|
|
|
|
Siehe gepards und meinen Post. Ich hab mich verlesen.
|
|
|
|
|
|
|
| Zitat von csde_rats
Ich ziehe B und sage die Lösung ist falsch. 5.5 in einem 4 Byte breiten Speicherbereich, wo doch nur 8 Byte Doubles benutzt werden, ergibt eh keinen Sinn.
| |
okay gut, danke! habe schon an mir gezweifelt!
|
|
|
|
|
|
|
Inkonsistenz: Die beiden double, die als array hintereinanderstehen haben je 8 byte, y 4 byte.
Edit: Zwipos werden auf void gecastet.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Admiral Bohm am 02.07.2013 17:00]
|
|
|
|
|
|
| Zitat von Admiral Bohm
Edit: Zwipos werden auf void gecastet.
| |
|
|
|
|
|
|
|
| Zitat von con_chulio
meine Chefin hat gerade gemeint, als wir so ein bisschen ueber was ich schon gemacht habe und was die Plaene nach 2013* sind, als abschluss Satz gemeint:
| |
Also bei den Satz ist grenzt das wirklich an einen Wunder tun, nech?!
¤\Ich hoffe der Wink war Zaunpfahl genug.
Hyp
|
|
|
|
|
|
|
Ich schreibe in 3,5 Wochen Informatik 1 (Algorithmen und Datenstrukturen) und einige Themen sitzen noch recht scheisse bzw hab ich keine Ahnung, wie ich da rangehe, weshalb ich euch jetzt in nächster Zeit etwas häufiger konsultieren werde
Fangen wir an mit der Induktion bei Algorithmen.
In Mathe hatte ich damals damit nicht so sehr das Problem, wenn man mal den Trick raus hat gehts ja. Aber jetzt in Info hab ich mal keinen Plan, wie ich auf die Lösung komme. Hier mal ne Beispielaufgabe (von unserem ersten Übungsblatt)
Da das schon ne Weile her ist, hier die von meiner Übungsgruppe ausgearbeitete Lösung, die ich damals wie heute nicht nachvollziehen kann:
|
Code: |
Behauptung: Programm generiert für n Element N0 die n-te Fibonaccizahl
Induktionsanfang:
Für A(0) ist a=0, b=1 und die Schleife wird nicht betreten. Dementsprechend ist a=F(0) und b=F(1). Der Output ist F(0)=1. Somit ist A(0)=1, was zu keinem Widerspruch führt. Somit ist der Induktionsanfang erfüllt.
Induktionsschritt: mit Hilfe Induktionsvorrausetzung A(n) mit n>=m wobei m in diesem Fall 0 . Sonderfall F(1) wird nicht betrachtet, sondern F(1)=1 als gegeben betrachtet.
a=0 =F(0)
b=1=F(1)
In der Schleife: i ist anfangs 1
t = b => t=F(i)=b, da 1=i
b=a+b => b=F(i-1)+F(i), da 0= i-1 und b=F(i)
a=t => a=F(i), da t=F(i)
VOR der nächsten Schleife sieht es nun folgendermaßen aus
Da i um eins erhöht wird ist a nun = F(i-1) und b=F(i-1-1)+F(i-1)=F(i)
Um jetzt die Korrektheit für alle n zu beweisen:
Zu beweisen: F(n+1) = F(n) + 1 „durchlauf der Schleife“
Wie vorher gezeigt hat VOR einer Schleife F(i) a den Wert F(i-1) und b F(i). Analog zu dem Beweis am Anfang des Induktionsschrittes ist nach der Schleife a F(i) und b F(i+1).
In der nten. Schleife hatte b den Wert b=a+b = F(n)+F(n-1). Wird die Schleife nochmal ausgeführt wird t mit b beschreiben und a mit t und somit wird a(nte Interation) =t(nte Iteration)=b(n-1te Iteration) ausgegeben.
Somit ist F(n) +1 Durchlauf der Schleife =F(n)+F(n-1)
F(n+1)= F(n)+F(n-1)
F(n+1) entspricht F(n)+F(n-1)
Insgesamt
F(n)+F(n-1)=F(n)+F(n-1)
|
|
Ich verhaspel mit schon mit der for-schleife. Ist es bei for-schleifen nicht völlig egal, ob mit i++ oder ++i iteriert wird? Den Teil nach der Korrektheit kann ich auch nach mitlerweile 30 Minuten durchtüfteln nicht nachvollziehen... wieso wird aus F(i) plötzlich F(i+1) in de rnächsten Iteraion usw.
Falls es mir wer kurz erklären kann bzw nen Link hat, der einen Schritt für Schritt an sowas ran führt, immer her damit
|
|
|
|
|
|
|
| Zitat von DasGensu
Ich verhaspel mit schon mit der for-schleife. Ist es bei for-schleifen nicht völlig egal, ob mit i++ oder ++i iteriert wird?
| | Ist es.
++i heißt, dass erst inkrementiert und dann der Wert zurückgegeben wird.
i++ heißt, dass erst der Wert zurückgegeben und dann inkrementiert wird.
Pseudocode:
|
Code: |
i = 10;
print i; // gibt 10 aus
print ++i; // gibt 11 aus
print i++; // gibt 11 aus
print i; // gibt 12 aus |
|
| Zitat von DasGensu Den Teil nach der Korrektheit kann ich auch nach mitlerweile 30 Minuten durchtüfteln nicht nachvollziehen... wieso wird aus F(i) plötzlich F(i+1) in de rnächsten Iteraion usw.
| | Weil im Schleifendurchgang ja Werte berechnet und den beiden Variablen a und b zugewiesen werden.
|
|
|
|
|
|
|
zu 1. http://stackoverflow.com/questions/484462/difference-between-i-and-i-in-a-loop
bevor du in den i-ten Schleifendurchlauf kommst ist:
a=F(i-1)
b=F(i)
das ist die Induktionsannahme
in der Schleife passiert folgendes:
t=b=F(i)
b=a+b=F(i-1)+F(i)=F(i+1) (das gilt nach definition der Fibonaccizahlen
a=t=F(i)
also a=F(i) und b=F(i+1)
das ist der Induktionsschritt
weil ja der Induktionsanfang auch ok ist (für i=0 und i=1) gilt die Aussage nun für alle i
|
|
|
|
|
|
|
Verliere bei der Lösung ein wenig die Lust, weil das alles extrem merkwürdig umständlich formuliert ist . Aber prinzipiell würde ich sowieso eher versuchen, selbst gute Induktionen hinzubekommen als von Kommilitonen gelöste Sachen als Grundlage zu nehmen.
Grundaufbau von Induktionen ist eigentlich super einfach: Suche das einfachste Beispiel (meist das kleinste), das benutzt werden kann. Oft ist das die leere Menge oder im Falle von Programmen der Wert 0.
Dieses Beispiel dient dann als Grundlage, um daraus die Induktion zu beginnen. Du zeigst einfach, dass gegeben irgendein n (du hast ja schon eins mit dem Anfang) der Fall +1 auch noch zutrifft. Gerade hier besonders schön, weil beim n=0 Fall die Schleife nicht betreten wird und bei n=1 einmal - jeder weitere Aufruf danach ist ja wieder identisch, womit das ganze auch intuitiv das Induktionsprinzip schön zeigt.
Letztendlich läuft es dann immer darauf hinaus, dass man anhand der gegebenen Sachen feststellt, in welcher Form eine Veränderung geschieht und dann nochmal einsetzt, dass es für ein n ja schon bekannt ist. Nach dem Motto "von n wissen wir schon, dass es gilt, und für n+1 wissen wir nun, dass es sich um soviel erhöht". So entsteht eine Art verkettung, weil man diesen Induktionsschritt für das damit gezeigte n+1 wieder anwenden kann.
Wie du auf die Unterscheidung zwischen ++i und i++ kommst, ist mir nicht klar. Sehe ich beim überfliegen auch nicht in "eurer" Lösung, dass das angesprochen werden würde. In Schleifen ist das in der Tat egal, es sei denn, man arbeitet mit Objekten (da ist ++i performanter, weil es einen Kopiervorgang spart).
Den einzigen bedeutenden Unterschied zu normalen Induktionen, wie ich sie aus dem theoretischen Bereich kenne, scheint mir da nur zu sein, dass man relativ unformal erzählt, was ne Programmzeile mit den Werten macht. Bei deiner Gruppe haben die Leute da schlichtweg Äquivalenzen zwischen Codezeilen und den Fibonacci-Regeln gemacht.
E: Ui bin ich spät. Fleißige Leute hier!
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Cru$her am 02.07.2013 19:21]
|
|
|
|
|
|
Danke schonmal, die regeln des inkrementieren kenn ich ja, machte nur im kopf der for-schleife wenig sinn (außer um erst mal zu verwirren)
wie gesagt, mathematische induktionen sind auch so eigentlich kein Problem gewesen, aber ich bekomme bei info recht schnell krach mit dem code, insb. wenn ich sagen soll, was VOR einer bestimmten Iteration einer schleife und danach läuft. Für mich im Kopf generell klar, aber wie ich das aufschreibe ist immer sone sache.
3,5 Wochen (und ne nervige Projektmanagement klausur) hab ich noch, bis dahin sollte das sitzen
Hat denn noch wer Links zu beispielen, tutorials etc?
Wenn man nach sowas + induktion sucht, landet man eigentlich nur in matheforen die das halt mathematisch beweisen, aber korrektheitsbeweise von codes findet man da nicht
|
|
|
|
|
|
|
| Zitat von DasGensu
insb. wenn ich sagen soll, was VOR einer bestimmten Iteration einer schleife und danach läuft. Für mich im Kopf generell klar, aber wie ich das aufschreibe ist immer sone sache.
| |
Du kannst die Sachen oft auch mathematisch notieren. Eine for-Schleife kann ja beispielsweise auch eine Summe aus der Mathematik sein. Da iterierst du auch von i=0 bis n. Wenn dir die Logik von Mathe leichter fällt wäre das also eine Möglichkeit, es so anzugehen. For-schleifen angucken und überlegen, wie man diese mathematisch notieren könnte. Dann kannst du das Problem mit den Verfahren lösen, die dir bekannt sind - Geht evtl. auch in diesem Beispiel, soweit ich weiß gibt es ja eine Fibonacci-Summenformel (edit: Kann auch bullshit sein, hab mich von Mathematik immer fern gehalten ).
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Cru$her am 02.07.2013 20:22]
|
|
|
|
|
|
mit fibonacci stand ich allerdings immer aufm kriegsfuß
Laufzeiten von einfachen sortieralgos (selection/insertionsort) krieg ich ja auch mit den summenformeln hin, aber fibonacci war in mathe, im programmierkurs etc immer mein gegner, keine ahnung warum
/¤ achso sorry fürs seite sprengen
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von DasGensu am 02.07.2013 20:57]
|
|
|
|
|
|
Mein Lieblingsfehler der letzten Wochen ... der "BUS ERROR". Wie findet man den Mist? Fehler ist nicht reproduzierbar und knallt mir alle paar Tage, laufende Rechnungen weg an immer unterschiedlichen Stellen im Programm.
|
|
|
|
|
|
|
| Zitat von Hyperdeath
| Zitat von con_chulio
meine Chefin hat gerade gemeint, als wir so ein bisschen ueber was ich schon gemacht habe und was die Plaene nach 2013* sind, als abschluss Satz gemeint:
| |
Also bei den Satz ist grenzt das wirklich an einen Wunder tun, nech?!
¤\Ich hoffe der Wink war Zaunpfahl genug.
Hyp
| |
deswegen promoviere ich ja auch in Physik und nicht in gutes deutsch
|
|
|
|
|
|
|
| Zitat von SilentAssassin
Mein Lieblingsfehler der letzten Wochen ... der "BUS ERROR". Wie findet man den Mist? Fehler ist nicht reproduzierbar und knallt mir alle paar Tage, laufende Rechnungen weg an immer unterschiedlichen Stellen im Programm.
| |
Actually is Segfault. Am besten mit Valgrind drangehen odervon hand wilde pointer jagen.
|
|
|
|
|
|
|
| Zitat von Admiral Bohm
| Zitat von SilentAssassin
Mein Lieblingsfehler der letzten Wochen ... der "BUS ERROR". Wie findet man den Mist? Fehler ist nicht reproduzierbar und knallt mir alle paar Tage, laufende Rechnungen weg an immer unterschiedlichen Stellen im Programm.
| |
Actually is Segfault. Am besten mit Valgrind drangehen odervon hand wilde pointer jagen.
| |
Ich stell mal direkt eine Frage um sicher zu gehen, dass ich den Output verstehe
Ich rufe auf valgrind --leak-check=full --track-origins=yes ./proram und bekomme das hier als output
|
Code: |
==20060== Conditional jump or move depends on uninitialised value(s)
==20060== at 0x452626: bornuct_
==20060== by 0x418D94: Drellyan::BornMassive(int, double)
==20060== by 0x418B69: Drellyan::Born(int)
==20060== by 0x4221C5: Sudakov::HighestBid()
==20060== by 0x41D215: Sudakov::GenEvent()
==20060== by 0x41CF22: Sudakov::Sudakov(phsp, int, int, gsl_rng*, LHE)
==20060== by 0x403DC0: main
==20060== Uninitialised value was created by a stack allocation
==20060== at 0x451AF5: bornuct_
|
|
Sehe ich richtig, dass alle "Conditional Jumps" meldungen den gleichen Fehler haben, der in bornuct_ liegt?
|
|
|
|
|
|
|
Ich glaube, du hast keine Debugsymbole im Code. Dann würde es mehr Informationen wie z.B. Zeilennummern geben.
|
|
|
|
|
|
|
Gibt es einen Weg, wie ich feststellen kann ob der Erwartungswert
gleich dem Maximum
ist, ohne auswerten zu müssen? Also irgendwelche analytischen tricks o.ä.? Symmetrisch ist nicht.
|
|
|
|
|
|
|
weisst du irgendwas von ...?
(Nicht das ich ne gute Idee haette...)
|
|
|
|
|
|
|
| Zitat von con_chulio
weisst du irgendwas von ...?
(Nicht das ich ne gute Idee haette...)
| |
Die Funktion ist auf beiden Seiten vom Maximum monoton fallend und wird nie negativ. Es gibt also ein wohldefiniertes und einziges Maximum.
Außerdem ist es einfacher, das Maximum zu bestimmen als den Erwartungswert. Oder anders formuliert: habe ich schon programmiert, ist also gegeben, würde ich gerne vermeiden zu programmieren.
|
|
|
|
|
|
|
Ist der Erwartungswert nicht sowas wie ein Mittelwert? Dann kann er ja nur das Maximum sein, wenn die Funktion const. ist, oder?
|
|
|
|
|
|
|
Also als Physiker jetzt:
Falls sein Maximum in einem sehr schafen Peak annimmt, kann man näherungsweise annehmen, dass der Erwartungswert der Stelle des Maximums der Verteilungsfunktion entspricht. Ein Beispiel wäre, wenn du sowas wie hast, aber weißt, dass das Ganze für sehr tiefe Temperaturen in Relation zur Skala, auf der die Energie untersucht wird, betrachtet wird.
Generell könntest du also nähern, wenn du abschätzen kannst, dass die Breite der Verteilungsfunktion klein gegenüber deiner Skala von ist.
Das ist jetzt nur ne fixe Idee, ich hab sowas in der Art schon ein paar mal gesehen, oder ähnliche Sachen, bei der die Verteilungsfunktion um den Peak entwickelt wurde um die Integration zu vereinfachen. Falls sowas bei dir der Fall ist, wäre es aber vielleicht trotzdem irgendwie nicht schlecht, zu überprüfen, ob -- falls eine Art Breitenparameter vorhanden ist -- im Grenzfall gegen Null von diesem sich das Ganze eben wie eine Deltadistribution verhält. Das wäre etwas mathematischer.
|
|
|
|
|
|
|
| Zitat von RichterSkala
Ist der Erwartungswert nicht sowas wie ein Mittelwert? Dann kann er ja nur das Maximum sein, wenn die Funktion const. ist, oder?
| |
Ne, die ist nicht constant, habe mich missverständlich ausgedrückt. Vermutlich fällt sie auf einer Seite irgendwie gaussisch ab und auf der anderen exponentiell. Oder so ähnlich.
@Robotronic: Leider eher breit.
Gut, ich rechne es halt aus. Brute force.
|
|
|
|
|
|
Thema: pOT-lnformatik, Mathematik, Physik XIII ( Completely Automated Public User Test To tell PIMP ) |