[Monkey] RealMillisecs ()

Übersicht

Andere Programmiersprachen

Beginners-Corner

	BBPro2 Betreff: RealMillisecs ()	Do, Aug 23, 2012 10:32 Antworten mit Zitat
Hi, ich spiele gerade ein wenig mit den Funktionen des Diddy-Moduls rum und bin auf RealMillisecs () gestoßen, welches die Anzahl der ms seit dem 1.1.1970 angibt. Nun entspricht dieser Wert mittlerweile etwa 2^40, was ja deutlich außerhalb der Range von Int liegt. Nichtsdestotrotz gibt RealMillisecs () einen Int Wert zurück und er wird sogar "richtig" verarbeitet. Print RealMilliSecs() gibt mir eine 13-stellige Zahl zurück mit der ich sogar arbeiten kann. Ich kann sie z.B. mit 10 multiplizieren und erhalte eine 14-stellige Zahl. Es scheint also als hätte ich hier eine Art "LongInt" die von Monkey aber eigentlich gar nicht unterstützt wid. Versuche ich ähnliche Ergebnisse mit "normalen" Ints zu rekonstruieren scheitere ich und erhalte die gewöhnlichen Überläufe. Nun zur Frage: wtf? ^^

BBPro2

Betreff: RealMillisecs ()

Do, Aug 23, 2012 10:32
Antworten mit Zitat

Hi,

ich spiele gerade ein wenig mit den Funktionen des Diddy-Moduls rum und
bin auf RealMillisecs () gestoßen, welches die Anzahl der ms seit dem 1.1.1970 angibt.

Nun entspricht dieser Wert mittlerweile etwa 2^40, was ja deutlich außerhalb der Range von Int liegt.
Nichtsdestotrotz gibt RealMillisecs () einen Int Wert zurück und er wird sogar "richtig" verarbeitet.

Print RealMilliSecs() gibt mir eine 13-stellige Zahl zurück mit der ich sogar arbeiten kann.
Ich kann sie z.B. mit 10 multiplizieren und erhalte eine 14-stellige Zahl.
Es scheint also als hätte ich hier eine Art "LongInt" die von Monkey aber eigentlich gar nicht
unterstützt wid.
Versuche ich ähnliche Ergebnisse mit "normalen" Ints zu rekonstruieren scheitere ich und erhalte
die gewöhnlichen Überläufe.

Nun zur Frage: wtf? ^^

	Tornado11	Do, Aug 23, 2012 15:46 Antworten mit Zitat
Also wir reden hier von einem int mit 32bit richtig? Dann solltest du das anschauen (für signed ints) Zitat: Viele, aber bei weitem nicht alle Systeme, welche die Unixzeit verwenden, speichern und verarbeiten die Zeitangabe als vorzeichenbehaftete 32-Bit-Zahl (Integer). Somit umfasst der Sekundenraum die Werte −2.147.483.648 bis +2.147.483.647. Umgerechnet in Jahre entspricht dies etwas mehr als −68 bis +68. Am 19. Januar 2038 um 3:14:08 Uhr UTC wird es daher bei Computersystemen, welche die Unixzeit in einer vorzeichenbehafteten 32-Bit-Variable speichern, zu einem Überlauf kommen. Die darzustellende Zeit wird dann mit der 2.147.483.648sten Sekunde nicht mehr in der Variable gespeichert werden können, womit es dann zum Jahr-2038-Problem kommen würde. Quelle: wikipedia

Tornado11

Do, Aug 23, 2012 15:46
Antworten mit Zitat

Also wir reden hier von einem int mit 32bit richtig? Dann solltest du das anschauen (für signed ints)

Zitat:

Viele, aber bei weitem nicht alle Systeme, welche die Unixzeit verwenden, speichern und verarbeiten die Zeitangabe als vorzeichenbehaftete 32-Bit-Zahl (Integer). Somit umfasst der Sekundenraum die Werte −2.147.483.648 bis +2.147.483.647. Umgerechnet in Jahre entspricht dies etwas mehr als −68 bis +68.

Am 19. Januar 2038 um 3:14:08 Uhr UTC wird es daher bei Computersystemen, welche die Unixzeit in einer vorzeichenbehafteten 32-Bit-Variable speichern, zu einem Überlauf kommen. Die darzustellende Zeit wird dann mit der 2.147.483.648sten Sekunde nicht mehr in der Variable gespeichert werden können, womit es dann zum Jahr-2038-Problem kommen würde.

Quelle: wikipedia

	BBPro2	Do, Aug 23, 2012 18:13 Antworten mit Zitat
hi, ja wir reden von einem 32bit int signed/unsigned kenne ich, damit hat das hier aber nichts tun das von dir zitierte problem bezieht sich auf timestamps in Sekunden, denn 2^32 / 2 ~ 2.150.000.000 umgerechnet in jahre ( / 60 / 60 / 24 / 365.25 ) ergibt das etwa 68 in dem fall wäre der aktuelle timestamp (da wir ja noch nicht 2038 haben) noch im rahmen und in den grenzen eines normalen ints. der befehl auf den ich mich beziehe gibt jedoch die zeit seit dem 1.1.1970 in MILLIsekunden an. ist also genau 1000x so groß wie der "normale" timestamp. er passt somit seit einigen jahren (eher jahrzehnten - grad keine lust nachzurechnen) schon nicht mehr in ein (signed oder unsigned egal) Int tatsächlich entspricht der ausgegebene wert der funktion etwa 2^40 und wird "ganz normal" verarbeitet. recht seltsamer effekt wie ich finde

BBPro2

Do, Aug 23, 2012 18:13
Antworten mit Zitat

hi,

ja wir reden von einem 32bit int
signed/unsigned kenne ich, damit hat das hier aber nichts tun

das von dir zitierte problem bezieht sich auf timestamps in Sekunden, denn

2^32 / 2 ~ 2.150.000.000
umgerechnet in jahre ( / 60 / 60 / 24 / 365.25 ) ergibt das etwa 68

in dem fall wäre der aktuelle timestamp (da wir ja noch nicht 2038 haben) noch im rahmen
und in den grenzen eines normalen ints.

der befehl auf den ich mich beziehe gibt jedoch die zeit seit dem 1.1.1970 in MILLIsekunden an.
ist also genau 1000x so groß wie der "normale" timestamp.
er passt somit seit einigen jahren (eher jahrzehnten - grad keine lust nachzurechnen) schon nicht
mehr in ein (signed oder unsigned egal) Int

tatsächlich entspricht der ausgegebene wert der funktion etwa 2^40 und wird "ganz normal" verarbeitet. recht seltsamer effekt wie ich finde

	Noobody	Do, Aug 23, 2012 18:49 Antworten mit Zitat
Es wäre hilfreich, wenn du jeweils angibst, welches Target du denn benutzt HTML5 (bzw. JavaScript) passen wohl am besten auf deine Beschreibung, drum: Monkey unterstützt kein Long, JS intern aber schon (naja, "unterstützt" - es wird emuliert durch Double (wtf wtf wtf)). Die Funktion RealMillisecs wird wohl einfach diesen Datentypen zurückgeben, und da JS schwach typisiert ist, kannst du mit dem rechnen und behältst die Genauigkeit, da implizit alles konvertiert wird. Ich bin nicht sicher, wie JS sich zusammen mit Monkey verhält - je nach dem behältst du die Genauigkeit ohne Probleme und der Typ anderer Variablen wird bei Zuweisung einfach im Hintergrund geändert, oder JS konvertiert dann einfach nach 32bit int. Das müsstest du wohl noch testen. Es ist aber kaum Verhalten, welches auf die anderen Targets portabel ist, darum würde ich mich nicht darauf verlassen.
Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

Noobody

Do, Aug 23, 2012 18:49
Antworten mit Zitat

Es wäre hilfreich, wenn du jeweils angibst, welches Target du denn benutzt Razz

HTML5 (bzw. JavaScript) passen wohl am besten auf deine Beschreibung, drum: Monkey unterstützt kein Long, JS intern aber schon (naja, "unterstützt" - es wird emuliert durch Double (wtf wtf wtf)).
Die Funktion RealMillisecs wird wohl einfach diesen Datentypen zurückgeben, und da JS schwach typisiert ist, kannst du mit dem rechnen und behältst die Genauigkeit, da implizit alles konvertiert wird.

Ich bin nicht sicher, wie JS sich zusammen mit Monkey verhält - je nach dem behältst du die Genauigkeit ohne Probleme und der Typ anderer Variablen wird bei Zuweisung einfach im Hintergrund geändert, oder JS konvertiert dann einfach nach 32bit int. Das müsstest du wohl noch testen.
Es ist aber kaum Verhalten, welches auf die anderen Targets portabel ist, darum würde ich mich nicht darauf verlassen.

Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

	BBPro2	Do, Aug 23, 2012 18:57 Antworten mit Zitat
hey, ja ich hatte das verhalten unter html5 festgestellt. ja, darauf verlassen hätte ich mich wohl so oder so unter keinen umständen, dafür kam mir das alles viel zu seltsam vor aber jetzt versteh ich wenigstens wie es überhaupt dazu kommen konnte, danke ^^

BBPro2

Do, Aug 23, 2012 18:57
Antworten mit Zitat

hey,

ja ich hatte das verhalten unter html5 festgestellt.

ja, darauf verlassen hätte ich mich wohl so oder so unter keinen umständen, dafür
kam mir das alles viel zu seltsam vor Very Happy

aber jetzt versteh ich wenigstens wie es überhaupt dazu kommen konnte, danke ^^

Übersicht

Andere Programmiersprachen

Beginners-Corner

Nach Oben

BlitzBasic Portal

[Monkey] RealMillisecs ()

BBPro2

Betreff: RealMillisecs ()

Tornado11

BBPro2

Noobody

BBPro2