Lorentz-Faktor - Rechner

[Higgs]

Hallo zusammen.

Ich möchte für ein paar Geschwindigkeiten den Lorentzfaktor berechnen.
Dabei habe ich meine Ergebnisse mit ein paar "Calculators" verglichen.
Auf der Seite:
http://www.abenteuer-universum.de/einstein/zeit.html#de
http://www.1728.org/reltivty.htm

Jetzt kamen für große Geschwindigkeiten ganz andere Werte raus, als ich berechnet habe. Wie kann das sein?

Für eine Geschwindigkeit v = 0,99999999999999*c bekomme ich als Lorentzfaktor den Wert ==> 7071067,8118654929216779732848027 heraus. Diesen und weitere Werte habe ich mit dem Windows-Taschenrechner berechnet.

Bei den automatischen Rechnern kommt aber ein anderer Wert heraus (bei allen derselbe)!?

[seeker]

Keine Ahnung was du getan hast.
Ich habe geprüft: Bei deinen beiden angegebenen Links kommt bei deinem angegebenen Wert "0,99999999999999c" gar keinWert mehr heraus:NaN
D.h.: Die beiden Programme können mit dieser Ziffernanzahl nicht mehr umgehen.
Stichwort Rechentiefe: Unterschiedliche Ergebnisse können sich dadurch ergeben, dass mit unterschiedlich vielen Nachkommastellen gerechnet wird.
Bei der letzten verwendeten Nachkommastelle wird dabei gerundet. Je nach dem ab welcher Ziffer gerundet wird unterschieden sich die Ergebnisse.

Bei deinen angegebenen 0,99999999999999c bekomme ich mit dem Google-Rechner den Wert 7073895,38088 heraus.

Grüße
seeker

[gravi]

Ich habe das gerade einmal in "meinen Rechner" auf der Homepage (siehe oberen Link von Higgs) eingegeben. Ergebnis: 7073895.38.
Geht also doch.
Ich habe das seinerzeit in Javascript geschrieben, habe nur nicht so viele Nachkommastellen.
Vielleicht hast du einen etwas anderen Wert für c genommen...?

Gruß
gravi

[positronium]

Zum einen musst Du natürlich aufpassen, dass Du statt dem Komma einen Punkt verwendest, weil sonst NaN als Ergebnis kommt. 0,999 versteht ja ein Amerikaner (Computer sind Amerikaner ) als 999.
Auch was seeker bzgl. der Rechengenauigkeit schreibt, kann natürlich eine Rolle spielen. Dein Wert für c hat 14 Stellen Genauigkeit. Damit kommst Du schon in einen Bereich, wo mit double precision nicht mehr unbedingt zuverlässig zu rechnen ist. (Zu den Datentypen: http://de.wikipedia.org/wiki/IEEE_754) D.h. je nach Rechenweg kann das Ergebnis unbrauchbar sein.

[seeker]

Zum einen musst Du natürlich aufpassen, dass Du statt dem Komma einen Punkt verwendest...

Und so war es auch! Ich hatte einfach paste/copy gemacht. Das ging natürlich schief.
Das mit der Rechentiefe ist aber dennoch zu beachten.

Grüße
seeker

[Higgs]

@ gravi

Erstmal ein Lob auf deinen Rechner. Toll, dass es solche Rechenhilfen gibt. Jedoch tauchen bei Werten, die mehr als 14 Stellen haben, unterschiedliche Werte im vergleich zum Windows-Taschenrechner auf!
Probier es mal aus.

Z.B. für v = 0.9999999999999999*c beträgt der Lorentz-Faktor laut deinem Rechner 67108864 !

Laut meinem Windows-Taschenrechner müsste der Lorentz-Faktor bei dieser Geschwindigkeit den Wert 70710678,118654754207851389176855 haben!

Also was stimmt denn da nicht?

Für den Wert c habe ich genommen c = 299792458 m/s.

[gravi]

Da müsste ich noch mal in das Programm gehen um zu sehen, wie viele Stellen das mitmacht. Liegt halt schon einige Jahre zurück, als ich das schrieb...
Aber bei der Geschwindigkeit kommt es doch auf einen Schnaps auch nicht mehr an

Ich seh aber mal nach.

Gruß
gravi

[Higgs]

Hallo gravi.

Hast du inzwischen etwas herausgefunden bezüglich deines Online-Rechners für den Lorentzfaktor?

Was mich interessiert ist, warum dein Rechner für die Geschwindigkeit v=0.9999999999999999*c den Wert 67108864 anzeigt, mein Rechner hingegen 70710678,118654754207851389176855.

Welcher Wert stimmt den nun?

[positronium]

seeker und ich haben es oben schon geschrieben: Es liegt an der Genauigkeit der verwendeten Datentypen und daran, wie die CPU diese verarbeitet.
gravis Code sieht so aus:

Code: Alles auswählen

c = 1;
...
        zwischenwert = 1-((v*v)/(c*c));
        tbeweg = (1/Math.sqrt(zwischenwert));
        tbeweg_int = Math.round(tbeweg*100)/100;
...

Wie Du siehst, ist daran nichts ungewöhnliches.

Das Ergebnis lautet korrekt: .
Dein Ergebnis ist numerisch richtig; das von gravis Rechner bei dieser Genauigkeit von v nicht mehr. gravis Berechnung wird als double precision direkt auf der CPU durchgeführt. Und Dein Programm verwendet entweder einen Datentyp mit grösserer Genauigkeit oder aber es rechnet nicht direkt auf der CPU, sondern es werden alle Rechenoperationen in Software umgesetzt.

Diese Unterschiede haben aber nichts mit der Physik zu tun, sondern sind einzig Folge der numerischen Berechnung.

[gravi]

@positronium: Danke für deine Erklärung, ich bin noch nicht dazu gekommen (hab gerade erst meinen Rechner "umgestrickt" und erst jetzt wieder "einsatzfähig").

Gruß
gravi

[gravi]

Ich habe inzwischen ein wenig mit dem (Java-) Script gespielt und anstelle von _int auch mit _float und allen erdenklichen Variationen experimentiert, um mit Gleitkommazahlen zu rechnen. Es nutzt alles nichts, bei der von Higgs angegebenen Höhe von c bekomme ich (wie auch andere in JS geschriebene Programme) stets den falschen Wert heraus. Gibt man dazu noch eine Kommastelle mehr ein (.999....9) steigt das Programm entweder mit NaN (Not a number) oder infinty aus. Das scheint mir die Grenze zu sein.

Da mich die Geschichte nun doch wurmt denke ich daran, die Berechnung anstatt in JS vielleicht auch mal in Pearl (als CGI- Script) zu versuchen, alternativ könnte man eine Berechnung auch in php probieren.
Allerdings bin ich in diesen Sprachen nicht sehr bewandert - für Unterstützung wäre ich daher dankbar, falls sich jemand damit auskennt. Möglicherweise ließe sich die Rechnung auch in einer ganz anderen Sprache (z.B. C++ ?) durchführen - wovon ich nun gar keine Ahnung habe. Wer sich damit auskennt, sei hiermit zur Mitarbeit motiviert...

Gruß
gravi

[positronium]

php liefert das gleiche Ergebnis wie Dein Code.

Code: Alles auswählen

<html><head></head><body>
<?php echo 1/sqrt(1-$_GET['v']*$_GET['v']) ?>
</body></html>

Aufruf: .../.datei.php?v=0.999

[gravi]

Danke, dann liegt es wohl nur an der Rechenart der CPU. Da kann man dann vermutlich mit einer anderen Programmiersprache auch nichts ausrichten.
Wieso aber funktioniert es dann auf 'nem einfachen Taschenrechner? Was macht der anders?

Vielleicht wäre noch ein gangbarer Weg, wenn man anstelle von Verhältnissen (c = 1) mit Absolutwerten, also km/s, evtl. in exponentieller Schreibweise operiert...?

Gruß
gravi

[positronium]

Perl gibt bei 16 mal die 9 eine Divison durch Null aus.

Code: Alles auswählen

#!/usr/bin/perl -w

print "Content-type: text/html\n\n";
print "<html><head></head><body>\n";

my @v = split(/=/, $ENV{'QUERY_STRING'});

print 1/sqrt(1-$v[1]*$v[1]);

print "</body></html>\n";

Aufruf genau so.

[positronium]

Danke, dann liegt es wohl nur an der Rechenart der CPU.

Ja, natürlich. Es gibt aber auch Umgebungen, in denen mit grösserer Genauigkeit gerechnet werden kann.

Da kann man dann vermutlich mit einer anderen Programmiersprache auch nichts ausrichten.

Die Sprache muss entweder entsprechende Datentypen bereit stellen, oder eben eine Klasse, welche das softwareseitig implementiert.

Wieso aber funktioniert es dann auf 'nem einfachen Taschenrechner? Was macht der anders?

Ich denke, dass der Windows-Taschenrechner nicht direkt auf der CPU rechnet, d.h. die Rechenoperationen so zerlegt, dass die Genauigkeit der CPU ausreicht.

Vielleicht wäre noch ein gangbarer Weg, wenn man anstelle von Verhältnissen (c = 1) mit Absolutwerten, also km/s,...

So etwas ist immer nur eine Bastellösung. Vielleicht könntest Du damit eine Dezimalstelle an Genauigkeit gewinnen, aber das war es dann.

...evtl. in exponentieller Schreibweise operiert...?

Das spielt gar keine Rolle. Es kommt auf die Bits an.

Gerade habe ich kurz geschaut: gcc bietet so etwas. Ich habe das noch nie gemacht; von daher bin ich mir in der Benutzung nicht sicher. Aber wenn Du interessiert bist, kann ich ein kleines C-Programm als CGI dazu schreiben.

[gravi]

Gerne, man kann es ja einfach mal versuchen.

Inzwischen habe ich mich auch noch etwas schlauer gemacht. Javascript (mit dem ich ja den Rechner gebastelt habe) kann nur bis max. 15 Stellen rechnen. Das steigt dann ab einer bestimmten Größe einfach aus und gibt die Fehlermeldungen aus ("Wert >1!"). Ist damit für solche extrem großen Werte unbrauchbar.
Dann habe ich mal mit 'nem normalen Taschenrechner gerechnet bis hin zu 18 9ern hinter dem Komma, und dies auch auf dem Windows- Taschenrechner. Hier gab es jedes Mal dasselbe, korrekte Ergebnis.
Nun, der Windows- Rechner arbeitet mit bis zu 32 Stellen, das sieht dann anders aus.
Ich fand auch Hinweise, dass der verwendete Browser eine Rolle spielen kann, mit dem man ein solches Script ansieht.

Danke noch für das Pearl- Script, ich hatte auch schon vermutet, dass es nicht funktioniert.

Gruß
gravi

[positronium]

Jetzt habe ich das ausprobiert.
Mit dem Datentyp __float128 kann ich auf dem Webserver nicht compilieren.
Mit long double klappt es, allerdings ist die Genauigkeit noch nicht genug, aber besser als die Ergebnisse mit double, also JavaScript, php, Perl... Möglicherweise hängt die Rechengenauigkeit bei diesem Typ auch von der zur Verfügung stehenden FPU ab - sprich: wenn kein long double hardwareseitig möglich ist, wird mit double oder per Software gerechnet. Also, wenn Du, gravi das auf Deinem Server compilierst, könnten bessere Ergebnisse heraus kommen. Auf meinem Server erhalte ich:

Parameter: 0.9999999999999999
long double: 0.99999999999999989998234958821221596281247911974788
Lorentz-Faktor: 70704438.581688

"Parameter" ist einfach der an das .cgi übergebene Wert als String.
"long double" ist dieser String nach long double konvertiert und formatiert ausgegeben.

Den Code kann man mit
gcc lorentz.c -o lorentz.cgi -lm
übersetzen.

Code: Alles auswählen

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>

int main(void) {
  printf("Content-type: text/html\n\n");
  printf("<html><body>\n");

  char *param = malloc(1024);
  param = getenv("QUERY_STRING");
  if (param != NULL && strlen(param) > 2) {
    char *vc = &param[2];
    printf("Parameter: %s<br>", vc);
    long double v = strtold(vc, NULL);
    printf("long double: %.50Lf<br>", v);
    long double l = 1.0L / sqrtl(1.0L - v * v);
    printf("Lorentz-Faktor: %Lf", l);
  }

  printf("</body></html>");
  return 0;
}

[gravi]

Besten Dank für deine Bemühungen!
Nun ist mir so einiges klar geworden.

Ist doch prima, wenn man solche Fachleute hier im Forum hat!

Schönen Gruß
gravi

[gravi]

Nochmals Danke, dein Applet ist auf der Seite.
Nun gibt's keine Diskrepanzen mehr

Netten Gruß
gravi

[Higgs]

@ gravi

Wenn ich dich richtig verstanden habe, dann hast du das Appelt zur Berechnung des Lorentz-Faktors neu geschrieben!?

Wo findet man dieses neue Applet??? Ich habe auf der Seite gesucht, wo es vorher war, habe es aber nicht gefunden.

[gravi]

Nicht ich habe es geschrieben, sondern positronium. Er hat es mir als Java- Applet zur Verfügung gestellt.

Okay, es ist ein wenig unscheinbar, aber zu finden unter

http://abenteuer-universum.de/einstein/zeit.html#de

unterhalb der Tabelle zum Gamma- Faktor. Du musst lediglich die Ausführung des Applets auf deinem Rechner zulassen...
In jedem Fall aber werden damit nun die korrekten Werte angezeigt, auch wenn man 16, 18 oder mehr Stellen hinter dem Komma eingibt.

Gruß
gravi

[Higgs]

Hallo gravi.

Was ist denn mit dem Rechner für den Lorentz-Faktor los? Erst war der neue Rechner eingerichtet worden, der auch wunderbar richtig gerechnet hat, und jetzt ist wieder der alte Rechner da, der falsche Werte bringt.

Was stimmt da nicht?

[gravi]

Aaah, sorry!

Ich stelle gerade die Homepage auf HTML 5 um und habe wohl eine falsche (alte) Datei hoch geladen.
Das wird selbstverständlich gleich korrigiert - nur noch der neue Rechner wird ab jetzt zu sehen sein!

War nur ein Versehen...

Gruß
gravi

[Higgs]

Hallo gravi.

Kein Problem! Jetzt funktioniert ja der Rechner wieder!

Ich wollte dir und positronium auch nochmal ein dickes Lob aussprechen für diesen Rechner! Soweit ich weiß, habt ihr ihn zusammen erstellt, und wie gesagt, er bringt jetzt korrekte Ergebnisse.
Überhaupt ist die Seite "Abenteuer Universum" eine der besten Seiten zu diesem Thema. Also

Mir ist aber noch aufgefallen, dass etwas an zwei Formeln verändert werden müsste.

Über der Tabelle sieht man zwei Formeln. Diese müssten umgeändert werden, denn wenn T'=Eigenzeit für bewegte Uhr ist, und T=Zeit für ruhende Uhr, dann gilt
==> T/T' = Lorentz-Faktor

T'/T= Wurzel(1-v^2/c^2)

Viele Grüße
Higgs

[tomS]

Hallo, ein grundsätzliches Problem der Berechnung ist, dass die beiden Terme 1 und v[up]2[/up] beide fast exakt gleich groß werden, und dass das Ergebnis der Differenzbildung dadurch sehr ungenau werden kann. Differenzen von Zahlen, deren signifikante Unterschiede sich in den letzten Stellen verbergen, sind numerisch extrem ungenau und sollten vermieden werden.

Ich sehe allerdings nicht direkt, wie man diese Differenz vermeiden kann.

Alternative wäre, nicht mehr mit v/c, sondern mit x = 1 - v/c zu starten und alle Rechnungen direkt mit x durchzuführen. Dann wäre x präzise bekannt.