BigInt.asIntN / .asUintN - wo ist der Sinn?

[Rolf B]

Hallo alle,

der BigInt-Typ in JavaScript hat die Methoden BigInt.asIntN und BigInt.asUintN. Ich versuche gerade, mir eine nützliche Anwendung für diese Methoden einfallen zu lassen.

Laut Beschreibung wird ein BigInt-Wert durch diese Methoden auf eine bestimmte Anzahl von Bits beschnitten. War er länger, bleiben die tiefstwertigen Bits übrig.

BigInt.asIntN(16, 42000n) ergibt damit -23536n.

Aber - was hab ich davon? Diejenigen im Web, die diese Methoden diskutieren, schreiben nur die Spec bzw. den TC39-Propsal ab: Ich kann damit erreichen, dass mein BigInt die voreingestellte Bitlänge nicht übersteigt.

Ja. Gut. Für ein Int64Array oder Uint64Array kann ich damit erreichen, dass ich keine zu großen BigInt-Werte hineinschreibe, und sie genauso stumpf beschneiden wie es ein 64-bit Register in einem Prozessor tut.

Aber was nützt mir das, wenn ich damit den gleichen Effekt wie ein 64-bittiges Prozessorregister bekomme, das überläuft, aber ohne dabei ein Carry- und Overflow-Flag eines Prozessors zu bekommen, die mir anzeigen, dass eine Operation gerade übergelaufen ist und mir damit Behandlungsoptionen geben?

Rolf

[Raketenwilli]

Aber was nützt mir das, wenn ich damit den gleichen Effekt wie ein 64-bittiges Prozessorregister bekomme, das überläuft, aber ohne dabei ein Carry- und Overflow-Flag eines Prozessors zu bekommen, die mir anzeigen, dass eine Operation gerade übergelaufen ist und mir damit Behandlungsoptionen geben?

Ich hoffe, ich habe Dich richtig verstanden.

> BigInt.asUintN(8, 8n)

8n

Für das Flag kannst Du also leicht selbst sorgen …

[TS]

Hello Rolf,

als ASM-Oldie könnte ich mir vorstellen, dass man dadurch ganz bewußt mit Überläufen arbeiten kann. Das kann manchmal nützlich sein.

Was kommt den raus, wenn du zu einem BigInt.asUintN (8) mit dem Wert 254d 3d addierst?

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

BigInt.asUintN(8, 254n+3n) sollte 1n ergeben. Bin gerade nur am Handy. Das kann man bei laufendem PC schnell in die Devtoolskonsole tippen.

BigInt.asUintN(8, 254n)+3n ergibt natürlich 257n...

mit Überläufen arbeiten kann. Das kann manchmal nützlich sein.

Ja klar. Aber nur wenn ich ein Carry- oder Overflow Flag habe. Oder ein Gegenstück zu AL und AH Register. Das gibt's bei BigInt alles nicht. Nur die Bitsäge. Ich muss diesen Teil mit & und >> selbst bauen. Und dann brauch ich asUintN nicht mehr. Das ist ja mein Punkt.

Rolf

[Raketenwilli]

Das gibt's bei BigInt alles nicht. Nur die Bitsäge. Ich muss diesen Teil mit & und >> selbst bauen. Und dann brauch ich asUintN nicht mehr. Das ist ja mein Punkt.

Auf derlei trifft man oft, wenn man Programmiersprachen jenseits des ursprünglichen Einsatzwecks benutzt. Und wofür war ECMA/Javascript ursprünglich mal ge[dm]acht? Genau: Kleinkram auf Webseiten verändern. Und wie (fast) alle Programmiersprachen wird auch JS so nach und nach erweitert. Im Extremfall bis es das durch krude Syntax und dadurch bedingter Unerlernbarkeit bewirkte Schicksal von Perl erleidet.

Je nach Laune kann man also sagen „Ui! Toll, dass das jetzt auch geht!“ oder „Menno! Wieso geht das nicht wie in Python, Java, CPP?“

[Gunnar Bittersmann]

@@Raketenwilli

Je nach Laune kann man also sagen „Ui! Toll, dass das jetzt auch geht!“ oder „Menno! Wieso geht das nicht wie in Python, Java, CPP?“

Oder auch „Menno! Wieso geht das genauso bescheuert wie in Python, Java, CPP?“ Looking at you, Zählung der Monate ab 0.

Python zählt richtig.

🖖 Живіть довго і процвітайте

[Raketenwilli]

Zählung der Monate ab 0.

Wenn man so will ist die Zählung der Array-Elemente ab 0 die Ursache.

[Gunnar Bittersmann]

@@Raketenwilli

Zählung der Monate ab 0.

Wenn man so will ist die Zählung der Array-Elemente ab 0 die Ursache.

Das wurde schon sehr früh verkackt. Wieviele Off-by-one-Fehler hätten vermieden werden können, wenn man das richtig gemacht hätte‽

1. Element: a[1]; letztes Element: a[a.length] – so einfach hätte es sein können.

🖖 Живіть довго і процвітайте

[Raketenwilli]

Das wurde schon sehr früh verkackt.

Man könnte auch sagen: „Mit Erfindung der Zahlen“. Die Null kam bekanntermaßen erst spät hinzu.

Sonst käme es uns allen wohl ganz normal vor, jede Zählung mit Null zu beginnen.

[TS]

Hello,

Zählung der Monate ab 0.

Wenn man so will ist die Zählung der Array-Elemente ab 0 die Ursache.

Das wurde schon sehr früh verkackt. Wieviele Off-by-one-Fehler hätten vermieden werden können, wenn man das richtig gemacht hätte‽

1. Element: a[1]; letztes Element: a[a.length] – so einfach hätte es sein können.

Das liegt daran, dass die (Ordnungszahl * Elementgröße) direkt den Offst im Speicherblock angibt / angab.

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@TS

Zählung der Monate ab 0.

Wenn man so will ist die Zählung der Array-Elemente ab 0 die Ursache.

Das wurde schon sehr früh verkackt. Wieviele Off-by-one-Fehler hätten vermieden werden können, wenn man das richtig gemacht hätte‽

1. Element: a[1]; letztes Element: a[a.length] – so einfach hätte es sein können.

Das liegt daran, dass die (Ordnungszahl * Elementgröße) direkt den Offst im Speicherblock angibt / angab.

Das ist kein Grund, den Unsinn in Hochsprachen so zu machen.

🖖 Живіть довго і процвітайте

[JürgenB]

Hallo Zusammen,

Das ist kein Grund, den Unsinn in Hochsprachen so zu machen.

wären wir mal bei Fortran geblieben 😎

Gruß
Jürgen

[TS]

Hello Gunnar,

Zählung der Monate ab 0.

Wenn man so will ist die Zählung der Array-Elemente ab 0 die Ursache.

Das wurde schon sehr früh verkackt. Wieviele Off-by-one-Fehler hätten vermieden werden können, wenn man das richtig gemacht hätte‽

1. Element: a[1]; letztes Element: a[a.length] – so einfach hätte es sein können.

Das liegt daran, dass die (Ordnungszahl * Elementgröße) direkt den Offst im Speicherblock angibt / angab.

Das ist kein Grund, den Unsinn in Hochsprachen so zu machen.

Das Problem liegt in der Entstehensgeschichte der Hochsprachen und der Ratlosigkeit der Entwickler, wie sie einerseits kompatibel bleiben können mit den älteren Versionen und trotzdem z. B. solche Änderungen einführen könnten.

Man könnte in neueren Compilern durchaus eine Zwischenschicht einziehen, die die in der Hochsprache benutze N für die ASM-Ebene auf N-1 zurückrechnet, ähnlich, wie man das beim Rangecheck (Turbo-Pascal) auch schon gemacht hat.

Spätestens bei den 4GL-Sprachen, die meistens als Scriptsprachen daherkommen, und ohnehin keinen Direktzugriff auf die Speicherverwaltung mehr zulassen, wäre das sicherlich möglich gewesen.

Bei PHP z. B. hätte man das mMn durchaus berücksichtigen können. Die einzigen Funktionen, die ich da kenne, die irgendwie noch eine Direktmanipulation der Datenstrukturen zulassen, sind die Funktionen pack() und unpack().

Aber direkt an den RAM lassen die Dich auch nicht heran. Zwischenschicht ist wieder ein "Array", das ja bekanntermaßen keines mehr ist, sondern eher eine Baumstruktur (im Modell). Im Hintergund sind es dann verknüpfte Hashtables mit referenzierten Records. Wenn man darin manuell herupfuschen würde, wäre vermutlich ganz schnell der Ofen aus.

Aber noch eine Frage zum Schluss: wie würdest Du "Dateianfang einer (leeren) Datei" definieren, bzw. wie darauf zugreifen?

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

Aber noch eine Frage zum Schluss: wie würdest Du "Dateianfang einer (leeren) Datei" definieren, bzw. wie darauf zugreifen?

Ja, Betriebssysteme arbeiten beim fseek mit Offsets relativ zu Start, Ende oder Current und darum liegt der Anfang bei Offset 0. Das ist - meine ich - eine andere Fragestellung als "Bei welchem Index sollten Arrays starten?". C und Nachfolger verwenden die 0 (Cs Vorgänger vermutlich auch), weil C bewusst maschinennah ist. Pascal ist frei definierbar, weil es bewusst maschinenfern ist. Dito FORTRAN und PL/1. Basic kann auf 0 (default) oder 1 eingestellt werden (OPTION BASE) und COBOL startet immer bei 1. In C++ kannst Du Dir sicherlich eine Klasse bauen, die Pascal-Arrays simuliert.

Wir entfernen uns jetzt aber deutlich von meiner Frage.

Rolf

[TS]

Hello,

Wir entfernen uns jetzt aber deutlich von meiner Frage.

Stimmt. @Gunnar Bittersmann hat Schuld ;-P

break;

Glück Auf
Tom vom Berg

[Der Martin]

Hallo,

Je nach Laune kann man also sagen „Ui! Toll, dass das jetzt auch geht!“ oder „Menno! Wieso geht das nicht wie in Python, Java, CPP?“

oder halt auch: "Schön, dass das jetzt geht. Aber wer braucht das?"

Einen schönen Tag noch
 Martin

[JürgenB]

Hallo Rolf,

hatten wir nicht mal die Diskussion über logische Operationen in Javascript und deren „unerwartete“ Resultate? So hat man eine definierte Bitzahl.

Ich habe vor einiger Zeit ^[1] aus einem Buch einen Zufallsgenerator abgeschrieben, der als Modulo den Integerüberlauf verwendet hat.

Gruß
Jürgen

---

1. Das muss so 1983 gewesen sein ↩︎