|
|
|
|
|
|
|
wer nen ansatz zu a) bzw. b)? ... Vy wird am höchsten Punkt ja 0 sein... Vx wird am höchsten Punkt ja schneller sein als die translationsgeschwindigkeit .. ?!
|
|
|
|
|
|
|
|
|
|
|
welche Geschwindigkeit hat der Reifen am Kontaktpunkt mit dem Boden? Welche Geschwindigkeit wird er dann wohl am "höchsten Punk" haben*?
b) Was ist die Definition der Winkelgeschwindigkeit? Wie können wir unser wissen auf a) dafür verwenden?
*angenommen der Reifen ist ein Kreis in 2D und es gibt keine Deformation oÄ
|
|
|
|
|
|
|
|
|
|
|
Im Vergleich zum untersten Punkt ist ja nur das Vorzeichen anders am oberen Punkt. Allerdings beziehen sich die Vx = 30cm/s ja nur auf den Reifen Mittelpunkt, oder?
Und es wird ja nach Vx und Vy bzw. Vektor V am obersten Punkt gesucht. Vy wird sowohl ganz oben als auch ganz unten 0 sein (Vektor V steht senkrecht zum Radius r, also keine Geschwindigkeit in Y-Richtung).
An der obersten Stelle ist der Abstand zum Boden 2r und nicht wie im Mittelpunkt, wo Vx=30cm/s ist, 1r. Muss man darüber nicht irgendwie gehen? Danke schonmal.
¤2: oder das ganze über energieerhaltung. quasi auf der höhe des reifenmittelpunktes und auf der höhe des höchsten punktes... Ekin_mitte + Epot_mitte = Ekin_oben + Epot_oben.. dann nach v_unbekannt umstellen
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Gepan.3dsvs.com am 13.03.2013 15:59]
|
|
|
|
|
|
|
|
|
| | Zitat von Gepan.3dsvs.com
Im Vergleich zum untersten Punkt ist ja nur das Vorzeichen anders am oberen Punkt. Allerdings beziehen sich die Vx = 30cm/s ja nur auf den Reifen Mittelpunkt, oder?
| |
Da bist du jetzt natürlich im Problem mit der Frage nach dem Bezugssystem.
Bezogen auf das Auto bewegt sich der Reifenmittelpunkt nicht, sonst würde der Reifen ja die Achse verlassen. Dafür bewegen sich aber die äußeren "Punkte" des Reifens.
Jedoch bezogen auf einen Beobachter, der am Straßenrand steht, bewegt sich der Reifenmittelpunkt und das Auto mit 30m/s. Dafür scheint sich der Kontaktpunkt mit dem Boden horizontal nicht zu bewegen. Wenn du ganz nah hinschauen würdest, dann würde es so aussehen, als ob der Punkt des Reifens an der gleichen Stelle verharrt wie der Asphalt darunter. (Wenn das Auto keine Reifen hätte, sondern eine Kette wie ein Panzer, dann würde das gleiche Kettenglied für einige Zeit auf dem selben Punkt auf dem Asphalt bleiben, "obwohl" sich der Panzer bewegt!)
Die Fragestellung musst du jetzt so interpretieren: Wenn sich das Auto in Bezug auf die Straße mit 30m/s bewegt, wie schnell bewegt sich dann der äußere Punkt eines Reifens bezogen auf die Reifenmitte?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von RichterSkala am 13.03.2013 16:00]
|
|
|
|
|
|
|
|
|
hmhm... die aufgabe macht mir echt zu schaffen... b) wäre mit a dann kein problem (v = w x r) das sollte damit ja gehen...
also fehlt mir nur bei a) irgendwie ein genauerer ansatz... rall es einfach iwie nicht 
|
|
|
|
|
|
|
|
|
|
|
|
Für a) sollte dir die anschauliche Methode namens "aufmalen" weiterhelfen. Dann zeichnest du die bekannten Geschwindigkeiten ein (Reifenmittelpunkt, Kontaktpunkt mit Boden) und der Rest sollte sich ergeben. Bedenke, dass ein Reifen rollt! Die sagt dir etwas über die Geschwindigkeit am Kontaktpunkt Boden (das mit den Ketten ist eine gute Verdeutlichung). Dann brauchst du nur noch ein Lineal und kannst mit den beiden Informationen die Geschwindigkeit oben hinzeichnen. Und danach auch ausrechnen.
|
|
|
|
|
|
|
|
|
|
|
wie komme ich mit den informationen dann auf die geschwindigkeit am untersten bzw. höchsten punkt... mit den ketten versteh ich das insofern, dass eben für ein bruchteil einer zeit es nur eine geschwindigkeit in X richtung gibt.. bis er irgendwann weiter ist und eben nicht mehr am höchsten punkt ist und somit auch in Y Richtung geschwindigkeit aufnimmt.. 
¤: der mittelpunkt bewegt sich in 1 sek 30cm => der unterste punkt bewegt sich in 1sek *denk*... irgendwie komm ich immer drauf, dass Vx am obersten/untersten punkt = Vx des Mittelpunkts ist... aber das kann ja nicht
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von Gepan.3dsvs.com am 13.03.2013 18:08]
|
|
|
|
|
|
|
|
|
Da ich im Moment viel Zeit hab, und nix besseres zu tun, dachte ich mir naja kannst ja mal schauen wie man eine Schwarm-Simulation baut und die vlt. später auch auf CUDA portiert, stable fluids nach stam war viel zu viel mathe/physik für mein hirn -.-
Nuja nach ein wenig Recherche stellt sich raus, man benutzt Agents um die einzelnen "Elemente" des Schwarms darzustellen.
Wie lasse ich diese "Simulation" ablaufen? Lasse ich für jeden Agent einen eigenen Thread laufen, der den Agent dauerhaft "belebt" oder schreibe ich einen "Solver" der Schritt für Schritt alle Agents aktuallisiert (Position, Geschwindigkeit)?
Jeden Agent in einen einzelnen Thread zu packen ist ja nur für eine kleine Anzahl von Agents sinnvoll, weil sonst einfach zuviel Rechenzeit für die Wechsel der Threads draufgeht oder irre ich mich da?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Gepan.3dsvs.com
http://i.imgur.com/55W1EOt.png
wie komme ich mit den informationen dann auf die geschwindigkeit am untersten bzw. höchsten punkt... mit den ketten versteh ich das insofern, dass eben für ein bruchteil einer zeit es nur eine geschwindigkeit in X richtung gibt.. bis er irgendwann weiter ist und eben nicht mehr am höchsten punkt ist und somit auch in Y Richtung geschwindigkeit aufnimmt..
¤: der mittelpunkt bewegt sich in 1 sek 30cm => der unterste punkt bewegt sich in 1sek *denk*... irgendwie komm ich immer drauf, dass Vx am obersten/untersten punkt = Vx des Mittelpunkts ist... aber das kann ja nicht
| |
Denk an das Bezugssystem! Welche Geschwindigkeit hat die Kette im Bezug auf den Boden? Welche in Bezug auf den Schwerpunkt?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von illbill
Jeden Agent in einen einzelnen Thread zu packen ist ja nur für eine kleine Anzahl von Agents sinnvoll, weil sonst einfach zuviel Rechenzeit für die Wechsel der Threads draufgeht oder irre ich mich da?
| |
Mit Cuda kannst du Threadwechsel vernachlässigen, die sind so extrem billig...
Dafür musst du auf ein paar andere Sachen achten, z.B. wo und wie du Branches einbaust, da die Threads in einem Warp parallel laufen, also wirklich alle immer die gleiche Instruktion ausführen. Hast du dann mehrere Branches, werden immer einige Threads "deaktiviert" und tuen nichts.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Gepan.3dsvs.com
¤: der mittelpunkt bewegt sich in 1 sek 30cm => der unterste punkt bewegt sich in 1sek *denk*... irgendwie komm ich immer drauf, dass Vx am obersten/untersten punkt = Vx des Mittelpunkts ist... aber das kann ja nicht
| |
Nimm dir eine Rolle Klopapier und roll die auf dem Boden ab 
Was passiert immer mit dem Punkt, der gerade Kontakt mit dem Boden hat? Richtig, er bleibt auf dem Boden liegen. Damit hat der untere Punkt die Geschwindigkeit 0m/s im Bezug auf einen außenstehenden.
Mit dieser Information ergibt sich dann folgendes Bild:
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Redh3ad
| | Zitat von illbill
Jeden Agent in einen einzelnen Thread zu packen ist ja nur für eine kleine Anzahl von Agents sinnvoll, weil sonst einfach zuviel Rechenzeit für die Wechsel der Threads draufgeht oder irre ich mich da?
| |
Mit Cuda kannst du Threadwechsel vernachlässigen, die sind so extrem billig...
Dafür musst du auf ein paar andere Sachen achten, z.B. wo und wie du Branches einbaust, da die Threads in einem Warp parallel laufen, also wirklich alle immer die gleiche Instruktion ausführen. Hast du dann mehrere Branches, werden immer einige Threads "deaktiviert" und tuen nichts.
| |
Leider bin ich noch nicht an dem Punkt die Sache mit CUDA zu bauen  Mir gings eher um einen Lösungsansatz auf der CPU, zunächst. Ich werds wohl erstmal mit wenigen Agents in eigenen Threads testen. Mal schauen bei wievielen Agents er sich dann verschluckt 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von F!5H
| | Zitat von Gepan.3dsvs.com
¤: der mittelpunkt bewegt sich in 1 sek 30cm => der unterste punkt bewegt sich in 1sek *denk*... irgendwie komm ich immer drauf, dass Vx am obersten/untersten punkt = Vx des Mittelpunkts ist... aber das kann ja nicht
| |
Nimm dir eine Rolle Klopapier und roll die auf dem Boden ab
Was passiert immer mit dem Punkt, der gerade Kontakt mit dem Boden hat? Richtig, er bleibt auf dem Boden liegen. Damit hat der untere Punkt die Geschwindigkeit 0m/s im Bezug auf einen außenstehenden.
Mit dieser Information ergibt sich dann folgendes Bild:
http://www.abload.de/img/55w1eotovqeytfua5.jpg
| |
sieht ziemlich nach 60cm/s aus... also 2*Vx... so ganz rall ichs aber nicht. kommt man da nicht irgendwie mit umformungen drauf?
@richterskala: im bezug auf dan boden ja 30cm/s oder? weil es sich ja für den boden nur als 1 objekt bewegt. im bezug zum mittelpunkt keine ahnung..
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Gepan.3dsvs.com am 13.03.2013 19:17]
|
|
|
|
|
|
|
|
|
| | Zitat von Gepan.3dsvs.com
@richterskala: im bezug auf dan boden ja 30cm/s oder?
| |
Die Kette rutscht also auf dem Boden? Ich glaube wir fahren verschiedene Panzer...
|
|
|
|
|
|
|
|
|
|
|
Okay die Kette bewegt sich also quasi nur "innerhalb" des Panzers. Der Boden "merkt" nur den Panzer aber nicht die eigentliche kette, die sich bewegt. ?!
Was für einen Bezug könnt ich denn dann aufstelle, wenn dem so wäre. Also wie kann ich dann die 2 Bezugssysteme verbinden.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von illbill
| | Zitat von Redh3ad
| | Zitat von illbill
Jeden Agent in einen einzelnen Thread zu packen ist ja nur für eine kleine Anzahl von Agents sinnvoll, weil sonst einfach zuviel Rechenzeit für die Wechsel der Threads draufgeht oder irre ich mich da?
| |
Mit Cuda kannst du Threadwechsel vernachlässigen, die sind so extrem billig...
Dafür musst du auf ein paar andere Sachen achten, z.B. wo und wie du Branches einbaust, da die Threads in einem Warp parallel laufen, also wirklich alle immer die gleiche Instruktion ausführen. Hast du dann mehrere Branches, werden immer einige Threads "deaktiviert" und tuen nichts.
| |
Leider bin ich noch nicht an dem Punkt die Sache mit CUDA zu bauen Mir gings eher um einen Lösungsansatz auf der CPU, zunächst. Ich werds wohl erstmal mit wenigen Agents in eigenen Threads testen. Mal schauen bei wievielen Agents er sich dann verschluckt
| |
CPU-Threads sind notorisch ineffizient bei kleinen Workloads und vielen Threads. Da dann doch lieber hingehen und kooperatives Multitasking selber basteln, ist ja sehr einfach. Das ist dann auch bei vielen Workloads sehr effizient.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von illbill
| | Zitat von Redh3ad
| | Zitat von illbill
Jeden Agent in einen einzelnen Thread zu packen ist ja nur für eine kleine Anzahl von Agents sinnvoll, weil sonst einfach zuviel Rechenzeit für die Wechsel der Threads draufgeht oder irre ich mich da?
| |
Mit Cuda kannst du Threadwechsel vernachlässigen, die sind so extrem billig...
Dafür musst du auf ein paar andere Sachen achten, z.B. wo und wie du Branches einbaust, da die Threads in einem Warp parallel laufen, also wirklich alle immer die gleiche Instruktion ausführen. Hast du dann mehrere Branches, werden immer einige Threads "deaktiviert" und tuen nichts.
| |
Leider bin ich noch nicht an dem Punkt die Sache mit CUDA zu bauen Mir gings eher um einen Lösungsansatz auf der CPU, zunächst. Ich werds wohl erstmal mit wenigen Agents in eigenen Threads testen. Mal schauen bei wievielen Agents er sich dann verschluckt
| |
CPU-Threads sind notorisch ineffizient bei kleinen Workloads und vielen Threads*. Da dann doch lieber hingehen und kooperatives Multitasking selber basteln, ist ja sehr einfach. Das ist dann auch bei vielen Workloads sehr effizient.
*weil Kontextwechsel aufgrund des großen Kontexts teuer sind und es präemptiv ist ; afaik wird auf GPUs so eine Art Mischform eingesetzt.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 13.03.2013 19:31]
|
|
|
|
|
|
|
|
|
| | Zitat von Gepan.3dsvs.com
Okay die Kette bewegt sich also quasi nur "innerhalb" des Panzers. Der Boden "merkt" nur den Panzer aber nicht die eigentliche kette, die sich bewegt. ?!
Was für einen Bezug könnt ich denn dann aufstelle, wenn dem so wäre. Also wie kann ich dann die 2 Bezugssysteme verbinden.
| |
Den Bezug den du aufstellen kannst, nennt sich Galilei-Transformation, aber das schießt hier über das Ziel hinaus.
Schreiben wir mal auf, links in Bezug auf das Zentrum das Rads, rechts im Bezug auf die Straße:
v_höchster_Punkt 30cm/s 60cm/s
v_mittelpunkt 0cm/s 30cm/s
v_kontaktpunkt -30cm/s 0cm/s
Vertikale Geschwindigkeit ist immer 0cm/s.
Ich hoffe es wird irgendwann mal noch klar...
|
|
|
|
|
|
|
|
|
|
Man hat mir beigebracht Skizzen helfen bei der Visualisierung!
|
|
|
|
|
|
|
|
|
|
|
ahhhhh kk... mir leuchtet jetzt auch die zeichnung von F!5H ein..
danke euch! vll sollte ich mir einfach mal ne kleine pause gönnen
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
| | Zitat von illbill
| | Zitat von Redh3ad
| | Zitat von illbill
Jeden Agent in einen einzelnen Thread zu packen ist ja nur für eine kleine Anzahl von Agents sinnvoll, weil sonst einfach zuviel Rechenzeit für die Wechsel der Threads draufgeht oder irre ich mich da?
| |
Mit Cuda kannst du Threadwechsel vernachlässigen, die sind so extrem billig...
Dafür musst du auf ein paar andere Sachen achten, z.B. wo und wie du Branches einbaust, da die Threads in einem Warp parallel laufen, also wirklich alle immer die gleiche Instruktion ausführen. Hast du dann mehrere Branches, werden immer einige Threads "deaktiviert" und tuen nichts.
| |
Leider bin ich noch nicht an dem Punkt die Sache mit CUDA zu bauen Mir gings eher um einen Lösungsansatz auf der CPU, zunächst. Ich werds wohl erstmal mit wenigen Agents in eigenen Threads testen. Mal schauen bei wievielen Agents er sich dann verschluckt
| |
CPU-Threads sind notorisch ineffizient bei kleinen Workloads und vielen Threads*. Da dann doch lieber hingehen und kooperatives Multitasking selber basteln, ist ja sehr einfach. Das ist dann auch bei vielen Workloads sehr effizient.
*weil Kontextwechsel aufgrund des großen Kontexts teuer sind und es präemptiv ist ; afaik wird auf GPUs so eine Art Mischform eingesetzt.
| |
Genau die Ineffizienz meinte ich mit verschlucken
Die Frage ist halt eher grundsätzlich ob Thread oder "Solver" für das Problem, egal ob GPU oder CPU da rechnen. Das lässt sich ja auch - ohne jeden Agent in einen Thread zu packen - auf der GPU rechnen.
Zum Workload: ist halt die Frage wie klein er wirklich ist.
Allein die Suche nach anderen Agenten im Raum und dem Abstand könnte schon ziemlich viel sein, kA ob man die Algorithmen zum Cluster finden auf der GPU rechnen sollte/kann und das immer wieder neu . Dann evtl. noch die Interaktion mit der Umgebung falls vorhanden.
Ich hab leider keine Paper oder ähnliches finden können, die sich genauer mit einer konkreten Lösung beschäftigen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von illbill
| | Zitat von csde_rats
| | Zitat von illbill
| | Zitat von Redh3ad
| | Zitat von illbill
Jeden Agent in einen einzelnen Thread zu packen ist ja nur für eine kleine Anzahl von Agents sinnvoll, weil sonst einfach zuviel Rechenzeit für die Wechsel der Threads draufgeht oder irre ich mich da?
| |
Mit Cuda kannst du Threadwechsel vernachlässigen, die sind so extrem billig...
Dafür musst du auf ein paar andere Sachen achten, z.B. wo und wie du Branches einbaust, da die Threads in einem Warp parallel laufen, also wirklich alle immer die gleiche Instruktion ausführen. Hast du dann mehrere Branches, werden immer einige Threads "deaktiviert" und tuen nichts.
| |
Leider bin ich noch nicht an dem Punkt die Sache mit CUDA zu bauen Mir gings eher um einen Lösungsansatz auf der CPU, zunächst. Ich werds wohl erstmal mit wenigen Agents in eigenen Threads testen. Mal schauen bei wievielen Agents er sich dann verschluckt
| |
CPU-Threads sind notorisch ineffizient bei kleinen Workloads und vielen Threads*. Da dann doch lieber hingehen und kooperatives Multitasking selber basteln, ist ja sehr einfach. Das ist dann auch bei vielen Workloads sehr effizient.
*weil Kontextwechsel aufgrund des großen Kontexts teuer sind und es präemptiv ist ; afaik wird auf GPUs so eine Art Mischform eingesetzt.
| |
Genau die Ineffizienz meinte ich mit verschlucken
Die Frage ist halt eher grundsätzlich ob Thread oder "Solver" für das Problem, egal ob GPU oder CPU da rechnen. Das lässt sich ja auch - ohne jeden Agent in einen Thread zu packen - auf der GPU rechnen.
Zum Workload: ist halt die Frage wie klein er wirklich ist.
Allein die Suche nach anderen Agenten im Raum und dem Abstand könnte schon ziemlich viel sein, kA ob man die Algorithmen zum Cluster finden auf der GPU rechnen sollte/kann und das immer wieder neu . Dann evtl. noch die Interaktion mit der Umgebung falls vorhanden.
Ich hab leider keine Paper oder ähnliches finden können, die sich genauer mit einer konkreten Lösung beschäftigen.
| |
Ich würde mir vielleicht OpenCL anschauen, was den Vorteil mit sich bringt, dass es portabel ist.
Von CUDA habe ich gar keine Ahnung; OpenCL kann aber auch so schöne Sachen wie halb-wegs brauchbares Scheduling auf der CPU… je nach Implementierung. AMD müsste das gewesen sein, womit ich da vor einiger Zeit mal rumgespielt habe. Da ging's um Pixelschubserei mit OpenCL+OpenGL, dürften einige tsnd. Workloads gewesen sein. Ging auch auf der CPU ohne große Probleme, von der Verlangsamung abgesehen.
/e: Auf GPUs würde ich auf jeden Fall den Ansatz von möglichst vielen, gleichen Workloads fahren. Genau darauf sind GPUs ausgelegt.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 13.03.2013 20:46]
|
|
|
|
|
|
|
|
|
Ist vielleicht ne blöde Frage aber ich bekomm das grad gar nicht hin..
hab einen .txt Datei in welcher ich alle Grossbuchstaben in kleine umwandeln soll und das ganze danach noch lexikografisch sortieren und in eine neue Datei speichern soll.
Das ganze in ner Bash Shell mittels einer langen Eingabe.
Hab versucht tr "[:upper:]" "[:lower:]" <datei.txt> | sort -d <output.txt>
:/
|
|
|
|
|
|
|
|
|
|
|
|
Was funzt da net? tr ... funktioniert bei mir schonmal.
|
|
|
|
|
|
|
|
|
|
|
Syntaxfehler beim unerwarteten Wort `newline' ...
e: Fehler gefunden.. die <> beim Dateinamen hab ich zu wörtlich genommen
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von b4ckspin am 13.03.2013 22:17]
|
|
|
|
|
|
|
|
|
Bei mir geht das.
tr "[:upper:]" "[:lower:]" < Memo | sort -d
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 13.03.2013 21:15]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Ich würde mir vielleicht OpenCL anschauen, was den Vorteil mit sich bringt, dass es portabel ist.
Von CUDA habe ich gar keine Ahnung; OpenCL kann aber auch so schöne Sachen wie halb-wegs brauchbares Scheduling auf der CPU… je nach Implementierung. AMD müsste das gewesen sein, womit ich da vor einiger Zeit mal rumgespielt habe. Da ging's um Pixelschubserei mit OpenCL+OpenGL, dürften einige tsnd. Workloads gewesen sein. Ging auch auf der CPU ohne große Probleme, von der Verlangsamung abgesehen.
/e: Auf GPUs würde ich auf jeden Fall den Ansatz von möglichst vielen, gleichen Workloads fahren. Genau darauf sind GPUs ausgelegt.
| |
Das Konzept bei OpenCL/CUDA ist halt das gleiche irgendwie (grobe Vereinfachung, nicht steinigen!)
Ich würde auch OpenCL nehmen, der Vorteil in heterogenen Umgebungen ist nicht von der Hand zu weisen, allerdings konnte ich mein VC++Express noch nicht dazu bewegen die richtige lib zu binden, es will einfach nicht, ist evtl. auch der Kombination Intel OpenCL Treiber + nVidia Treiber + VC++ zuzuschreiben
Falls du auch ne AMD CPU hattest, Glückwunsch zu Treibern aus einer Hand 
Werd morgen mal weiter rumspielen
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von illbill am 13.03.2013 21:26]
|
|
|
|
|
|
|
|
|
Und heute, eine weitere Erfahrung aus dem Bereich http://xkcd.com/773/
Ich brauche demnächst ggf. sehr schnell ein Thema in Mathe. (Weil ich Gefahr laufe, ab April exmatrikuliert (nur in Mathe) zu werden...) Ich suche also Forschungsergebnisse. NÜSCHT! Ich finde Semesterpläne für ihr Gebiet, Vorlesungslinks, seit vier Jahren tote SFB-Projekte - aber keine Liste: Paper. Nichts.
wtf.
Hey, you do your experiments - I do mine!
|
|
|
|
|
|
|
|
|
|
|
|
Benutze Name mit arxiv.org
|
|
|
|
|
|
|
|
|
|
|
Bei dem einen klappt es (Stringtheorie, buh!), bei dem anderen bekommt man vier oder fünf ältere Sachen.
Wollust ward dem Wurm gegeben.
|
|
|
|
|
|
|
|
| Thema: pOT-lnformatiker, Mathematiker, Physiker XII ( Jetzt mit Primzahlen > 1024 ) |
