Der Beweis, dass C++ für Physik die beste Sprache ist
-
Auch wenn der Thread sicher gleich geschlossen wird...
Boost Units ist der Beweis, dass C++ für Physikaufgaben einfach unschlagbar ist.
:p
-
Definiere unschlagbar.
Ich glaub, dass MATLAB oder ähnliche Speziallösungen noch ne ganze Menge mehr bietet als diese Lib.
-
TheChampionOfTheWorld schrieb:
Definiere unschlagbar.
Ich glaub, dass MATLAB oder ähnliche Speziallösungen noch ne ganze Menge mehr bietet als diese Lib.Na ich meine doch für richtige Programmierung, nicht zum spielen.
-
@Mr. N:
1. Die meisten Leute, die ernsthaft im Rahmen der Physik programmieren, kommen auch mehr oder weniger aus der Physik. Und nicht aus der Informatik. Deren Hauptinteresse gilt der Physik und nicht der Programmierung. Wenn diese Leute mit C++ programmieren, dann kommt da typischerweise irgendeine Variation von C raus. Zumindest sind diese Leute typischerweise meilenweit davon entfernt, einen C++ Stil zu haben, wie er in diesem Forum anzutreffen ist. Ebensoweit sind sie davon entfernt, sich derart weitgehend mit Programmiersprachen zu befassen, dass sie auf etwas wie Boost Units stoßen und ernsthaft nutzen. Im wissenschaftlichen Bereich haben sie dafür auch keine Zeit: Dort geht es darum, zu Veröffentlichungen zu kommen. Und wer erstmal eine Sprache wie C++ soweit lernt, dass er sie wirklich gut beherrscht, der verliert seine Stelle bevor er auch nur irgendeine Veröffentlichung hat. Entsprechend muss man sich damit abfinden, dass in derartigen Bereichen eher schlechte Codequalität vorliegt und nur wenige Sprachmittel der verwendeten Sprachen ausgenutzt werden.
2. Nur selten fängt man in der Physik von 0 an. Typischerweise gibt es schon irgendwelche Programme, die teilweise auch schon sehr alt sind. Diese Programme werden dann modifiziert. Und bei solchen Programmen ist es typischerweise so, dass viele Leute mit ganz unterschiedlichen Programmierfähigkeiten daran mitgearbeitet haben, die zudem kein Gesamtprojekt im Blick hatten, sondern jeweils nur ihre eigene kleine Modifikation. Entsprechend sind die Probleme der Leute, die in der Physik programmieren auch ganz andere, als die Einheiten sinnvoll in den Code reinzukriegen. Viel gravierender sind fehlende Dokumentation und Kommentare, kryptische Bezeichner und so weiter.
3. Durch den Codebestand hat man oft nicht die Wahl der Programmiersprache. Wenn der Code 20 jahre alt ist, dann ist er in Fortran geschrieben und deshalb nimmt man auch Fortran um ihn zu modifizieren.
4. Ok, ich erinnere mich daran, dass diese eine Marssonde wegen falscher Einheiten verloren gegangen ist. Aber das hat die Situation in der Programmierung in der Physik auch nicht verändert.
-
Gregor, ich glaube du übertreibst ein bisschen mit deinem negativen Bild. Ich glaube nämlich, an Boost arbeiten durchaus ein paar Physiker mit.
Außerdem ändert das nichts an der Tatsache: C++ ist die beste Sprache dafür, ob sie nun verwendet wird oder nicht. :p
-
Mr. N schrieb:
Gregor, ich glaube du übertreibst ein bisschen mit deinem negativen Bild. Ich glaube nämlich, an Boost arbeiten durchaus ein paar Physiker mit.
Kann sein. Ein paar gibt es immer. Es gibt ja auch in diesem Forum einige Physiker und Physikstudenten. Aber diese paar Leute sind nicht für die Wissenschaftslandschaft der Physik repräsentativ.
-
Mr. N schrieb:
Außerdem ändert das nichts an der Tatsache: C++ ist die beste Sprache dafür, ob sie nun verwendet wird oder nicht. :p
Bei einer derartigen Aussage solltest Du noch hinzufügen, dass sie alleine auf technischen Aspekten der Sprache beruht. Wenn Du das tust, kann man darauf aufbauend natürlich diskutieren.
...aber selbst dann spricht einiges dafür, dass Sprachen, die in CAS eingebaut sind, teilweise besser geeignet sind. Oder was ist zum Beispiel mit Fortress? 
-
Mr. N schrieb:
Außerdem ändert das nichts an der Tatsache: C++ ist die beste Sprache dafür, ob sie nun verwendet wird oder nicht.
weils dafür 'ne library^^ gibt, die mit einheiten rumrechen kann, oder wieso nimmst du das an?
-
das ist der schlechteste trollversuch, den ich jemals gesehen habe
-
Gregor schrieb:
@Mr. N:
1. Die meisten Leute, die ernsthaft im Rahmen der Physik programmieren, kommen auch mehr oder weniger aus der Physik. Und nicht aus der Informatik. Deren Hauptinteresse gilt der Physik und nicht der Programmierung. Wenn diese Leute mit C++ programmieren, dann kommt da typischerweise irgendeine Variation von C raus. Zumindest sind diese Leute typischerweise meilenweit davon entfernt, einen C++ Stil zu haben, wie er in diesem Forum anzutreffen ist. Ebensoweit sind sie davon entfernt, sich derart weitgehend mit Programmiersprachen zu befassen, dass sie auf etwas wie Boost Units stoßen und ernsthaft nutzen. Im wissenschaftlichen Bereich haben sie dafür auch keine Zeit: Dort geht es darum, zu Veröffentlichungen zu kommen. Und wer erstmal eine Sprache wie C++ soweit lernt, dass er sie wirklich gut beherrscht, der verliert seine Stelle bevor er auch nur irgendeine Veröffentlichung hat. Entsprechend muss man sich damit abfinden, dass in derartigen Bereichen eher schlechte Codequalität vorliegt und nur wenige Sprachmittel der verwendeten Sprachen ausgenutzt werden.
Deswegen verwenden Physiker einfache Programmiersprachen die schnell zu lernen sind.
Z.B wäre hier D zu nennen.
Der Sprachumfang ist sehr gut überschaubar und die Sprache ist performant.Im Worst Case Fall programmieren sie mit C#, ich kenne z.b. jemanden der Mathematik an der UNI studiert und die programmieren nur in C#.
Und vielleicht gib es auch noch Python Leute, denn nur um zu wissen ob eine bestimmte Veröffentlichung das richtige Ergebnis liefert, dafür reicht auch Python, auf Performance kommt es ja nicht immer an.
Dann rechnet der Rechner halt mal 48 h. Was macht das schon wenn der Physiker dafür 2 Monate Einarbeitungszeit in C++ und Co spart.
-
TheChampionOfTheWorld schrieb:
Definiere unschlagbar.
Ich glaub, dass MATLAB oder ähnliche Speziallösungen noch ne ganze Menge mehr bietet als diese Lib.Es geht nichts über GNU BC und GNUPlot.
-
@Progger²: Naja, die Realität ist praktisch Fortran und auch C oder C++. Alles auf recht einfachem Niveau. Das ist einfach durch den bisher vorhandenen Code vorgegeben. Angefangen von Numerik-Bibliotheken bis hin zu spezifischerem Physik-Code. D kannst Du eigentlich genauso vergessen wie Java oder C#. Die sind einfach nicht präsent, was historisch zu begründen ist. Ok, Java sieht man im Physikbereich manchmal, wenn Leute Applets programmieren, um irgendetwas zu demonstrieren. Matlab wurde schon erwähnt und ist auch relativ präsent.
...das sind meine subjektiven Erfahrungen.
-
sothis_ schrieb:
das ist der schlechteste trollversuch, den ich jemals gesehen habe
Pfft. Ich wollte mit dem Thread nur meiner Freude über Boost.Units Ausdruck verleihen. :p
fricky schrieb:
weils dafür 'ne library^^ gibt, die mit einheiten rumrechen kann, oder wieso nimmst du das an?
Genau.
.oO(Alle plöd und Boost toll.)
-
Mr. N schrieb:
Ich wollte mit dem Thread nur meiner Freude über Boost.Units Ausdruck verleihen.
beneidenswert, für welche banalen dinge sich manche begeistern können. bei einer 'physik-engine' würdest du bestimmt luftsprünge vor entzückung machen.
-
-fricky- schrieb:
Mr. N schrieb:
Ich wollte mit dem Thread nur meiner Freude über Boost.Units Ausdruck verleihen.
beneidenswert, für welche banalen dinge sich manche begeistern können. bei einer 'physik-engine' würdest du bestimmt luftsprünge vor entzückung machen.
Nö die wär mir egal.
Boost.Units ist NICHT banal.
-
-fricky- schrieb:
weils dafür 'ne library^^ gibt, die mit einheiten rumrechen kann, oder wieso nimmst du das an?
So eine Library ist schon hilfreich. Ich hatte das Beispiel mit der Marssonde ja schon erwähnt. Wenn man Fehler bezüglich der verwendeten Einheiten einbaut, dann kann das enorme Probleme verursachen. Wenn nun eine Library vorhanden ist, die einen eleganten Umgang mit Einheiten erlaubt, so dass sich Einhaiten auch schön in die Syntax eingliedern, dann unterstützt das Leute, die dimensionsbehaftete Größen verarbeiten müssen, doch enorm. Nicht nur bei der Umrechnung, sondern zudem beim Debugging. Es bietet völlig neue Möglichkeiten, wenn man überprüfen kann, ob an einer bestimmten Stelle die richtige Einheit vorliegt. Eine derartige Library bietet ist eine gute Grundlage, um physiklastige Programme zu schreiben.
beneidenswert, für welche banalen dinge sich manche begeistern können. bei einer 'physik-engine' würdest du bestimmt luftsprünge vor entzückung machen.
Eine "Physik-Engine" ist hingegen Kinderkram. Soetwas brauchst Du für'n Ballerspiel oder ähnliches. Da hat man also Anwendungsgebiete, die sich doch sehr vom ursprünglichen Gedanken dieses Threads unterscheiden.
Andererseits ist eine Eingliederung von Einheiten in eine Programmiersprache auch nicht wirklich etwas neues. Insofern muss man da nicht sooo begeistert sein. In anderen Sprachen gibt es das auch und jetzt hat C++ diesbezüglich wohl eine Schwachstelle weniger. Man würde sich aber wohl noch eine deutlich angenehmere Darstellung physikalischer Formeln wünschen, wie es beispielsweise einige Computeralgebrasysteme bieten oder auch Fortress. Leute, die in diesem Bereich programmieren, arbeiten typischerweise auf einer höheren Abstraktionsebene. Insofern ist es eigentlich erst dann wirklich zufriedenstellend, wenn eine physikalische Formel auch wirklich wie eine physikalische Formel aussieht. ...mit Integralzeichen und so weiter.
-
Gregor schrieb:
Andererseits ist eine Eingliederung von Einheiten in eine Programmiersprache auch nicht wirklich etwas neues.
Es dauert immer eine Weile bis die theoretischen Konzepte auch in praktischen Sprachen ankommen. Die Theorie dahinter gab es bestimmt schon in den 70ern. Aber erst in den letzten Jahren haben Haskell, Python usw. dieses Feature bekommen.
Boost.Units bzw. die Vorläufer sind seit Jahrem im Gespräch. Erst jetzt gibt es eine Bibliothek, die den Qualitätsanforderungen der Boost Reviewer genügt. Ich kann aber natürlich nicht einschätzen, wie sich die Haskell/Python-Varianten gegen Boost.Units schlagen.
[Gregor der ***** hat behauptet, Fortress sei Vaporware, wobei es gar keine ist, daher wird die Aussage entfernt.]
-
Mr. N schrieb:
[Gregor der ***** hat behauptet, Fortress sei Vaporware, wobei es gar keine ist, daher wird die Aussage entfernt.]
Da sind übrigens die Downloads, falls einer Interesse hat:
-
http://home.scarlet.be/be052320/Unum.html
>>> distance = 50 * M >>> distance 50.0 [m] >>> volume = distance ** 3 >>> volume 125000.0 [m3] >>> duration = 25 * S >>> duration 25.0 [s] >>> speed = distance / duration >>> speed 2.0 [m/s] >>> mass = 1.5 * KG >>> kinetic_energy = (mass * speed**2) / 2 >>> kinetic_energy 3.0 [kg.m2/s2]
man vergleiche die komplexität die man bei boost units braucht um sowas aufzuschreiben.edit: größeres beispiel:
# -- Import of units from ubase import * # -- Constants K = 6.673E-11 * N*M**2/KG**2 earth_mass = 5.980E24 * KG g = 9.81 * M/S**2 c = 300000 * KM/S earth_radius = ((K*earth_mass/g)**.5).as(KM) # -- Input Data distances = (5*CM, earth_radius, c * 365*24*H) masses = (5*G, earth_mass, 1000*earth_mass) # -- Processing and display print "G = %s" % K print "Earth mass = %s" % earth_mass print "Earth radius = %s" % earth_radius print "distances = %s" % str(distances) print "masses = %s" % str(masses) print for m1 in masses: for m2 in masses: if m1 >= m2: for d in distances: force = K*m1*m2/d**2 a1 = force/m1 a2 = force/m2 print "m1 = %s, m2 = %s, d = %s" % (m1, m2, d) print "f = %s, a1 = %s, a2 = %s\n" \ % (force.as(N), a1.as(M/S**2), a2.as(M/S**2)) Ausgabe: G = 6.673e-011 [N.m2/kg2] Earth mass = 5.98e+024 [kg] Earth radius = 6377.88450862 [km] distances = (5.0 [cm], 6377.88450862 [km], 9.4608e+012 [km]) masses = (5.0 [g], 5.98e+024 [kg], 5.98e+027 [kg]) m1 = 5.0 [g], m2 = 5.0 [g], d = 5.0 [cm] f = 6.673e-013 [N], a1 = 1.3346e-010 [m/s2], a2 = 1.3346e-010 [m/s2] m1 = 5.0 [g], m2 = 5.0 [g], d = 6377.88450862 [km] f = 4.10117056856e-029 [N], a1 = 8.20234113712e-027 [m/s2], a2 = 8.20234113712e-027 [m/s2] m1 = 5.0 [g], m2 = 5.0 [g], d = 9.4608e+012 [km] f = 1.86382619077e-047 [N], a1 = 3.72765238154e-045 [m/s2], a2 = 3.72765238154e-045 [m/s2] m1 = 5.98e+024 [kg], m2 = 5.0 [g], d = 5.0 [cm] f = 7.980908e+014 [N], a1 = 1.3346e-010 [m/s2], a2 = 1.5961816e+017 [m/s2]
-
borg schrieb:
man vergleiche die komplexität die man bei boost units braucht um sowas aufzuschreiben.
Dann vergleich mal. Übrigens ist das von dir nicht wirklich typsicher. Nichts hindert dich daran, eine Masse in eine Funktion zu stecken, die eine Beschleunigung benötigt.
-
Mr. N schrieb:
Übrigens ist das von dir nicht wirklich typsicher. Nichts hindert dich daran, eine Masse in eine Funktion zu stecken, die eine Beschleunigung benötigt.
die funktion kann mich daran hindern. und es ist schon in sofern typsicher das man zB nicht dinge miteinander addieren kann die keinen sinn ergeben.