nicht angemeldet
MudGuard
Camping_RIDER
Camping_RIDER
Robert B.
Rolf B
Camping_RIDER
Rolf B
Camping_RIDER
Rolf B
Rolf B
Camping_RIDER
Rolf B
Hi,
Ohne BigInt-Literale müssten Sie die in b1 abgelegte Konstante mühsam aus höchsten 15-stelligen Zeilen zusammensetzen:
Das sind wohl eher Teile als Zeilen …
Das "höchsten" würde sich auch noch über ein abschließendes s freuen.
console.log(b2 - b1); // Hoffentlich 1
ergibt keinen Sinn, wenn vorher eine BigInt-Zahl b3 erzeugt wird.
Aber wie ändern? Noch ein b4 erzeugen und dann b4 - b3? Oder weglassen? Oder b2 - b1?
(Deswegen hab ich das jetzt nicht selbst geändert - wofür ich mich erst hätte anmelden müssen, darum hab ich auch den Kleinkram oben nicht geändert)
Die Spezifikation von asm.js verlässt sich darauf
Die verlinkte asm.js sagt von sich selbst, daß sie deprecated sei …
Ich hab aber keine Zeit, asm.js mit WebAssembly zu vergleichen, um rauszufinden, ob es Sinn ergibt, den Link auf asm.js durch einen auf WebAssembly zu ersetzen …
cu,
Andreas a/k/a MudGuard
Aloha ;)
Vorweg: den zweiten Teil...
Die Spezifikation von asm.js verlässt sich darauf
Die verlinkte asm.js sagt von sich selbst, daß sie deprecated sei …
Ich hab aber keine Zeit, asm.js mit WebAssembly zu vergleichen, um rauszufinden, ob es Sinn ergibt, den Link auf asm.js durch einen auf WebAssembly zu ersetzen …
...hab ich nicht angefasst, weil ich da grad auch zu wenig Überblick habe.
Den ersten Teil habe ich folgendermaßen verändert:
Ohne BigInt-Literale müssten Sie die in b1 abgelegte Konstante mühsam aus mehreren Teilen zusammensetzen, die aus höchstens 15-stelligen Number-Literalen entstehen:
(Das „entstehen“ ist hier wohlüberlegte Absicht, „bestehen“ wäre sachlich falsch...)
Aber wie ändern? Noch ein b4 erzeugen und dann b4 - b3? Oder weglassen? Oder b2 - b1?
Wenn man mich fragt: Minimalinvasiv, so dass das Beispiel hier nicht noch weiter aufgebläht wird. Es geht darum, ein b3 zu erzeugen, das b1 entspricht - also vergleicht man einfach b3 mit b1 und lässt den Kram mit b2 weg. Ich habe das folgendermaßen angepasst:
console.log(b3 - b1); // Hoffentlich 0
Den Vergleich zwischen b3 und b1 habe ich auch hier durch eine Differenz gelöst, könnte man auch mit „===“ und „Hoffentlich true“ machen, gerne Meinungen dazu ob das besser wäre... Die Differenzbildung hier macht halt nochmal klarer, dass es sich um Zahlen handelt, mit denen man auch rechnen kann.
Meine 5ct zum Thema:
Ich glaube man könnte (und sollte) den Nachsatz mit "falls es keine BigInt-Literale gäbe" mitsamt Beispiel dazu streichen.
Ich glaube nicht, dass es eine Erklärung braucht, warum man auf BigInt-Literale angewiesen ist - wir weisen ja bei Number-Literalen auch nicht darauf hin, dass man Numbers, wenn es keine Number-Literale gäbe, aus Strings konvertieren müsste (o.ä.). Ein nativer Datentyp sollte auch eine Literal-Notation haben, und Punkt.
Die Frage, die da beantwortet wird ist rein akademisch und bietet keinen großen Mehrwert, gleichzeitig aber viel Verwirrpotential - gerade Leser, die nicht so den Durchblick haben, werden die Intention vmtl. nicht verstehen und sich dann fragen, was das ganze soll; dabei werden Ressourcen verbraten, die gerade diese Leser eigentlich besser ins weiterlesen stecken sollten.
Was denkt ihr: Weg mit dem Absatz und dem Beispiel? Oder nur weg mit dem Beispiel (auch dann wäre schon was gewonnen). Oder so lassen?
Grüße,
RIDER
@@Camping_RIDER
Meine 5ct zum Thema:
Ich leg noch was drauf. All in!
Ich glaube man könnte (und sollte) den Nachsatz mit "falls es keine BigInt-Literale gäbe" mitsamt Beispiel dazu streichen.
Full ACK. Weg damit!
Das einleitende „Der JavaScript-Datentyp BigInt ist dafür vorgesehen, ganze Zahlen mit beliebiger Größe zu verarbeiten“ reicht völlig.
🖖 Живіть довго і процвітайте
Hallo Gunnar,
All In
ACKzeptiert. Ist nun All Out.
Rolf
@@Gunnar Bittersmann
Das einleitende „Der JavaScript-Datentyp BigInt ist dafür vorgesehen, ganze Zahlen mit beliebiger Größe zu verarbeiten“ reicht völlig.
Wobei das nicht ganz stimmt. Die Zahlen können zwar ziemlich groß sein, aber nicht beliebig groß.
Ich glaube nicht, dass BigInt für $$9^{9^{9^9}}$$ (9^9^9^9) reicht. 😏
🖖 Живіть довго і процвітайте
PS: Ist das LaTeX-Dingens beim Forenumzug kaputtgegangen?
Hallo Gunnar,
$$3^2+2^3=4^2+1^2$$
sieht so aus...
Gut dass ich Corona habe, da kann ich besser ins Github hineinniesen.
ISSUE!
Merkwürdig ist aber, dass nach jeder Eingabe zunächst mal ganz kurz die Formel erscheint und sie dann durch Math Processing Error ersetzt wird.
Rolf
Hallo,
das Forum wurde in Efeuextrakt gebadet und der Issue-Schleim ist erfolgreich gelöst. Gunnars Exponentialtürmchen ist wieder sichtbar.
Danke, Christian!
Rolf
Aloha ;)
Zum Zweiten Teil:
Die Spezifikation von asm.js verlässt sich darauf
Die verlinkte asm.js sagt von sich selbst, daß sie deprecated sei …
Ich hab aber keine Zeit, asm.js mit WebAssembly zu vergleichen, um rauszufinden, ob es Sinn ergibt, den Link auf asm.js durch einen auf WebAssembly zu ersetzen …
Ich hab jetzt keine mega krasse Ahnung davon, aber irgendwie liest sich für mich auch die Begründung mit asm.js irgendwie quatschig. Zumindest schreiben wir:
Der unäre +-Operator kann für BigInt-Werte nicht verwendet werden. Für diesen Operator ist spezifiziert, dass er einen Number-Wert erzeugt. Die Spezifikation von asm.js verlässt sich darauf und würde verletzt, wenn in der Variablen a ein BigInt Wert stünde und +a ein BigInt liefert.
Und der verlinkte asm.js-Artikel der MDN sagt:
It is a very small, strict subset of JavaScript that only allows things like while, if, numbers, top-level named functions, and other simple constructs. It does not allow objects, strings, closures, and basically anything that requires heap allocation.
Hallo? asm.js erlaubt keine Objekte oder andere Dinge, die heap allocation brauchen, also auch keine BigInt-Objekte, oder was übersehe ich hier? Und wenn asm.js gar keine BigInt-Objekte erlaubt, warum begründen wir dann das Verhalten des unären +-Operators in Bezug auf BigInts mit asm.js, und wenn das für den unären +-Operator eine valide Begründung wäre, warum dann nicht auch für den normalen +-Operator?
Irgendwie habe ich das Gefühl, dass diese Begründung von vornherein nicht so sinnvoll war, oder ich verstehe sie nicht richtig (beides möglich). In zweiterem Fall braucht es eine erklärende Umformulierung, in ersterem Fall könnte sie auch weg. Das stünde für mich da an erster Stelle, vor der Frage, ob man jetzt stattdessen auf WebAssembly verlinkt.
Ich habe mal noch in einem Draft der BigInt-Erfinder nachgelesen (siehe Unterpunkt 4.2.2 und dort den Block „Motivation“). Dort wird auch auf asm.js verwiesen, der Link geht in die eigene Readme-Datei des Proposals - nur ist dort der entsprechende Absatz schon gelöscht worden.
Um den Absatz wiederzufinden, kann man in der History zurückgehen und findet dort die Begründung:
Don't break asm.js
Although this proposal introduces operator overloading, it throws in any of the cases that asm.js depends on for setting up type checking. asm.js relies on a few identies:
Unary + followed by an expression is always either a Number, or results in throwing. For this reason, unfortunately, + on a BigInt needs to throw, rather than being symmetrical with + on Number: Otherwise, previosly "type-declared" asm.js code would now be polymorphic.
[...]
This proposal makes special allowances to make BigInt usable in asm.js code to build support for 64-bit integers, by including the standard library functions BigInt.asUintN and BigInt.asIntN as well as BigUint64Array and BigInt64Array. The operator overloading in this proposal should not complicate the asm.js model: asm.js already treats operators as "overloaded" between floats, doubles, and signed and unsigned integers.
Interessant ist, dass diese Begründung und ein zugehöriges Beispiel mittlerweile aus dem Readme-Dokument gestrichen wurde (mit Verweis „BigInt will not be added to asm.js; use WebAssembly instead.“), dass das Proposal zu BigInt aber den unären +-Operator immer noch nicht enthält, mittlerweile ohne sinnvolle Begrüdung.
Das alles liest sich für mich wie „wir haben das ursprünglich so gebaut, um asm.js nicht zu verletzen, haben jetzt aber festgestellt, dass wir asm.js gar nicht unterstützen werden weil ist eh deprecated, aber die Entscheidung mit dem unären + können wir jetzt erstmal trotzdem nicht rückgängig machen“.
Vielleicht sollten wir das dann auch so schreiben? Z.B.:
Der unäre +-Operator kann für BigInt-Werte nicht verwendet werden. Für diesen Operator ist spezifiziert, dass er einen Number-Wert erzeugt oder eine Exception wirft. Ursprünglich wäre das ein Problem im Zusammenhang mit dem mittlerweile veralteten asm.js gewesen, das sich auf dieses Verhalten verlässt. Ob nun, da asm.js nicht weiter unterstützt wird, irgendwann die Unterstützung des unären +-Operators für BigInt-Werte kommen wird, ist noch unklar.
Grüße,
RIDER
Moin @MudGuard,
Ich hab aber keine Zeit, asm.js mit WebAssembly zu vergleichen, um rauszufinden, ob es Sinn ergibt, den Link auf asm.js durch einen auf WebAssembly zu ersetzen …
asm.js ist ein reduzierter Umfang von JavaScript; WebAssembly ist kompilierter Code aus unterschiedlichen Programmiersprachen (C, Rust, …), der direkt in der JavaScript-VM im Browser ausgeführt wird.
Viele Grüße
Robert
Hallo MudGuard,
danke, merke ich mir vor.
WebAssembly und asm.js sind unterschiedliche Dinge.
Zu der Zeit, wo BigInt eingeführt wurde, war asm.js noch en vogue und hat deshalb die Spec geprägt. Und nun ist es so. Abgesehen davon wäre es ein breaking change, wenn
Gunnar Bittersmannlet a = 10n
let b = +a;
in b ein BigInt statt einer Number speicherte. Und breaking changes meidet man in Sprachen wie die Pest. Es sei denn, man heißt Lerdorf…
Update: Ich lese Janoschs Beitrag erst jetzt. Also warte ich mal ab, was sich aus dem Artikel ohne mich entwickelt. Danke für die Unterstützung 😀
Rolf
Aloha ;)
Update: Ich lese Janoschs Beitrag erst jetzt. Also warte ich mal ab, was sich aus dem Artikel ohne mich entwickelt. Danke für die Unterstützung 😀
Deine Meinung interessiert mich trotzdem 😂
Grüße,
RIDER
Hallo Janosch,
das Beispiel mit dem Literalersatz habe ich entfernt. Ihr habt recht, das war Rolfsche "vom Stöckchen zum Pinnchen" Weitschweifigkeit.
Als ich den Teil über +n schrieb, war mir der Missbilligungsstatus von asm.js nicht bewusst. Wenn man das einbezieht, ist die Argumentation sicherlich schräg.
Dennoch war das wohl damals das Argument, dass man unäres + nicht auf BigInt anwenden kann ("ENTWEDER eine Number liefern ODER eine Exception werfen"). Wenn die Spec sich auf ein "geht nun mal nicht" reduziert, können wir das sicherlich auch. Wer ändern will, mag ändern, ansonsten guck ich mir das heute abend noch mal an.
Rolf
Aloha ;)
Dennoch war das wohl damals das Argument, dass man unäres + nicht auf BigInt anwenden kann ("ENTWEDER eine Number liefern ODER eine Exception werfen").
Klar, habe ich ja auch so gefunden.
Wenn die Spec sich auf ein "geht nun mal nicht" reduziert, können wir das sicherlich auch. Wer ändern will, mag ändern, ansonsten guck ich mir das heute abend noch mal an.
Hast du dir mal meinen Vorschlag am Ende dieses Postings angeschaut?
Grüße,
RIDER
Hallo Janosch,
ja, hatte ich. Eine Frage:
Ob nun, da asm.js nicht weiter unterstützt wird, irgendwann die Unterstützung des unären +-Operators für BigInt-Werte kommen wird, ist noch unklar.
Ist das eine Theoriefindung deinerseits oder eine bequellbare Äußerung eines TC39 Mitglieds? Das unäre + ist definiert als "Mach eine Number draus. Geht das nicht, erzeuge NaN". BigInt in diesen Satz einzubauen führt zu einem Haufen Regeln, wann BigInt, wann Number und wann ein Error rauskommen soll, und wird definitiv irgendwelchen Code zerbröseln. Sowas macht PHP[1], ich bin froh, dass das in JavaScript nicht passiert
Rolf
Weil sie den Augiasstall, den PHP 1-4 vollgeschissen haben, sonst nie sauber kriegen ↩︎
Aloha ;)
Ob nun, da asm.js nicht weiter unterstützt wird, irgendwann die Unterstützung des unären +-Operators für BigInt-Werte kommen wird, ist noch unklar.
Ist das eine Theoriefindung deinerseits oder eine bequellbare Äußerung eines TC39 Mitglieds?
Reine Theoriefindung meinerseits. Beziehungsweise: eine ehrliche Auseinandersetzung mit der Sachlage - denn ob das noch kommen wird oder nicht ist zumindest mir unklar.
Das unäre + ist definiert als "Mach eine Number draus. Geht das nicht, erzeuge NaN". BigInt in diesen Satz einzubauen führt zu einem Haufen Regeln, wann BigInt, wann Number und wann ein Error rauskommen soll, und wird definitiv irgendwelchen Code zerbröseln.
Jein. Mir ist das mit der Inkonsistenz mit Bestandscode ehrlich gesagt da nicht so klar. Das unäre + könnt ja auch einfach bei Number-Argumenten das bisherige Standardverhalten zeigen und bei BigInt-Argumenten statt Number ein BigInt liefern. Mir ist nicht klar, wo das Bestandscode, der keine BigInts verwendet, in irgendeiner Form beeinträchtigt.
Was für mich auch nach wie vor unklar ist: Warum ist das unäre Minus kein Problem? Das ist ja für BigInt durchaus definiert, wenn ich das richtig gesehen habe... Und das führt mich zu der Unklarheit, ob das unäre Plus denn jetzt noch kommen wird oder nicht.
Und da mir die klare Begründung völlig fehlt (vielleicht verstehe ich sie auch nur nicht) ist mir halt auch nicht klar, ob das unäre + nicht vielleicht doch noch kommt.
Grüße,
RIDER
Hallo Janosch,
ich hab mal was verändert, was hältst Du davon?
Rolf
Aloha ;)
ich hab mal was verändert, was hältst Du davon?
Hm. Sehr viel klarer ist mir die neue Version auch nicht. Vielleicht verstehe ich auch das ursprüngliche Problem bei asm.js noch nicht richtig.
Du schreibst:
Ein Grund dafür war, dass die geplante asm.js Teilmenge von JavaScript ihn als "Dies ist ein Number-Objekt" Markierung verwendete.
Das liest sich für mich so, als würde asm.js das + als Marker für ein Number-Objekt-Literal verwenden. Ist das so?
Ich hätte noch einen Vorschlag zur Güte, mit minimalistischem Ansatz um möglichst wenig Verwirrung hervorzurufen:
Der unäre +-Operator kann für BigInt-Werte nicht verwendet werden. Zum Zeitpunkt der Spezifikation von BigInt wurden Kompatibilitätsprobleme mit bestehendem Code, z.B. in asm.js, befürchtet, was zu der Entscheidung geführt hat, diesen Operator für BigInt-Werte nicht neu zu definieren.
Grüße,
RIDER
Hallo Janosch,
ja, kann man so schreiben, denke ich.
Ich habe mich nur ganz kurz in asm.js eingelesen. Mitgenommen habe ich, dass man dort ständig Konstrukte notiert, die die Operanden in den Number-Bereich zwingen, also sowas wie (+a) oder ((a+b)>>0). Die Der JIT kann daraus eine reine INT-Arithmetik ableiten und Code generieren, der vom Tempo her nativem Code nahekommt.
Wenn +a für BigInt ein BigInt und für Number ein Number liefert, ist das nicht alles. Was ist mit (+a) für a="789345897459837598375893748934578934893"? Zur Zeit ist das ein Number, 7.893E+39 (wenn ich jetzt richtig gezählt habe). Aber als BigInt wäre das doch viel schicker, oder? ODER? 💥
asm.js würde das nicht tun, dort verwendet man keine Strings (weil man den JavaScript-Heap nicht verwendet). Aber ein JIT müsste bei der Verarbeitung von (+a) mit diesem Szenario rechnen, und ich denke, das war der Grund, warum +a immer Number liefern soll. Und auch der Grund dafür, asm.js in die Tonne zu treten.
Zum unären - wollte ich was geschrieben haben, hab ich nicht? Codeminifizierer und Codegolfer verwenden das + gerne als toNumber-Operation. Das unäre - nicht, deswegen ist das scheinbar unkritisch. Oder die Existenz von unärem Minus ist so wichtig, dass man dafür den breaking change riskiert hat. Ach, ich weiß es doch auch nicht. Meine Kristallkugel ist bekanntlich aus Milchglas. Isnumalso 😟
Rolf
Aloha ;)
ja, kann man so schreiben, denke ich.
Ich habe das mal so übernommen.
Ich habe mich nur ganz kurz in asm.js eingelesen. Mitgenommen habe ich, dass man dort ständig Konstrukte notiert, die die Operanden in den Number-Bereich zwingen, also sowas wie (+a) oder ((a+b)>>0). Die Der JIT kann daraus eine reine INT-Arithmetik ableiten und Code generieren, der vom Tempo her nativem Code nahekommt.
asm.js ist für mich ein gesiegeltes Buch mit undichtem Siegel. Immer mal wieder glaube ich etwas zu verstehen, und dann endet das ganze schließlich doch wieder in einem „wtf, warum eigentlich?“-Moment.
Wenn +a für BigInt ein BigInt und für Number ein Number liefert, ist das nicht alles. Was ist mit (+a) für a="789345897459837598375893748934578934893"? Zur Zeit ist das ein Number, 7.893E+39 (wenn ich jetzt richtig gezählt habe). Aber als BigInt wäre das doch viel schicker, oder? ODER? 💥
Schicker vielleicht, aber ob das so notwendig ist, dass man sich dann zwischen „wir machens nur schick“ oder „wir machens gar nicht“ entscheidet, das ist für mich schon komisch.
Zum unären - wollte ich was geschrieben haben, hab ich nicht?
Gesehen habe ich nix.
Codeminifizierer und Codegolfer verwenden das + gerne als toNumber-Operation. Das unäre - nicht, deswegen ist das scheinbar unkritisch. Oder die Existenz von unärem Minus ist so wichtig, dass man dafür den breaking change riskiert hat. Ach, ich weiß es doch auch nicht. Meine Kristallkugel ist bekanntlich aus Milchglas. Isnumalso 😟
😀 wer macht jetzt Theoriefindung? 😉 Offenbar bleibt bei uns beiden das Gefühl, dass die BigInt-Erfinder den Punkt mit dem unären + nicht so richtig durchdacht haben, oder zumindest (benefit of the doubt) diese Gedanken nicht sauber dokumentiert haben...
Grüße,
RIDER