Introducing the bigint #6670

mununki · 2024-03-08T07:06:50Z

Discussions: #6525

This PR is to introduce the JS bigint as a primitive type. With the addition of the bigint type, this PR implements support for basic arithmetic operators and unary negation operators as a first step. The comparison operator and exponential operator is being added to the initial implementation of this PR for review.

I tried to make all arithmetic operations polymorphic, but the downside of stripping out the optimization logic for existing int and float was that we explicitly added operators.

The main changes are

Changed the deprecated nativeint to bigint: use the *n literal of nativeint for bigint.
~~Added arithmetic operators. (The comma can be changed to something better on the discussion. I initially considered +n, but saw the increased complexity in parsing and implemented it as a comma).~~
Omitted optimizations at build time because there is no API in OCaml that supports bigint-sized numbers, unlike int and float
Added the support untagged variant of VeryLargeNumber(bigint)
Added Js.Bigint module to override the integer operator depending on user needs.

open! Js.Bigint

let a = 1n + 1n
let p = 2n ** 2n

Added the support of bitwise operations

// you can use land, lor, lxor, ... with open! Js.Bigint
landn(1n, 1n)
lorn(1n, 1n)
lxorn(1n, 1n)
lnotn(1n)
lsln(1n, 1n)
asrn(1n, 1n)
// unsingned right shift (>>>) is not supported for BigInt in JS

Support literal in the pattern matching

switch 1n {
| 1n => ...

cometkim · 2024-03-08T17:19:28Z

jscomp/others/js_json.res

@@ -30,6 +30,7 @@ type rec t =
  | @as(null) Null
  | String(string)
  | Number(float)
+  | Bigint(bigint)


BigInt doesn't belong to JSON spec

Ah, correct. I'll remove it, thanks!

Removed c8b78d2

zth · 2024-03-08T17:46:21Z

Can be done in a follow up PR of course, but adding support for it in untagged variants would be nice.

mununki · 2024-03-08T17:48:32Z

Can be done in a follow up PR of course, but adding support for it in untagged variants would be nice.

Oh, this PR already added support the untagged variant with Bigint.

zth · 2024-03-08T17:53:57Z

@mununki haha I'm sorry, you're right... Well done!

zth

Great work! 🎉 This will be great to support. A few smaller questions from me. @cristianoc should have a look at this as well.

I'm not sold on the comma. Comma has such a specific meaning in the language that the code looks broken to me when there's a comma. I don't have a better suggestion yet though, but maybe we could figure one out together.

zth · 2024-03-09T10:29:59Z

jscomp/ml/ast_payload.ml

+              ({pexp_desc = Pexp_constant (Pconst_integer (name, Some n)); _}, _);
+          _;
+        };
+      ] when n = 'n' ->


Nit, but can't this when clause just be directly inside of the pattern?

zth · 2024-03-09T10:31:19Z

jscomp/ml/ast_untagged_variants.ml

@@ -375,7 +393,7 @@ module DynamicChecks = struct
    in
    let literals_overlaps_with_number () =
      Ext_list.exists literal_cases (function
-        | Int _ | Float _ -> true
+        | Int _ | Float _ | Bigint _ -> true


Bigint doesn't overlap with number, right?

Thanks! a9e4c16

zth · 2024-03-09T10:34:24Z

jscomp/others/js_bigint.res

@@ -1,3 +1,11 @@
 /*** JavaScript BigInt API */

-type t
+type t = bigint


Considering whether we should just remove this one and refer to bigint directly instead. It's breaking so we could wait for a bit before doing that and just deprecate t meanwhile, but we should definitely refer to bigint instead of t in the code below.

Thanks! cf62db8

zth · 2024-03-09T10:34:38Z

jscomp/others/js_bigint.res

+external \"~-": t => t = "%negbigint"
+external \"~+": t => t = "%identity"
+external \"+": (t, t) => t = "%addbigint"
+external \"-": (t, t) => t = "%subbigint"
+external \"*": (t, t) => t = "%mulbigint"
+external \"/": (t, t) => t = "%divbigint"
+external mod: (t, t) => t = "%modbigint"


As said above, I think t should be bigint instead here.

cristianoc · 2024-03-09T11:37:46Z

Having yet another syntax for one more numeric type seems to make an existing problem worse.

The existing problem is having to use + and +. for ints and floats.

I'd rather go the direction of making x+y resolve to int or float or bigint at type checking time.

zth · 2024-03-09T11:55:12Z

While we figure something like that out, can we get away with the following perhaps?

// Using opens, described in this PR
open! Js.Bigint

let a = 1n + 1n

// Or, functions on bigint...?
let a = Js.Bigint.add(1n, 1n)

cknitt · 2024-03-09T12:57:38Z

I'd rather go the direction of making x+y resolve to int or float or bigint at type checking time.

This would be great, but how would it work with type inference? What type would the function

let f = (x, y) => x + y

have?

cristianoc · 2024-03-09T18:41:18Z

I'd rather go the direction of making x+y resolve to int or float or bigint at type checking time.

This would be great, but how would it work with type inference? What type would the function
let f = (x, y) => x + y
have?

Without type annotations, the default numeric type.
One could define a generic numeric type, though it's probably overkill as polymorphic numerical code is not very likely.

cometkim · 2024-03-10T15:53:33Z

I'd rather go the direction of making x+y resolve to int or float or bigint at type checking time.

This would be great, but how would it work with type inference? What type would the function

suggested on #6477

actually we are doing same for comparison operators.

mununki · 2024-03-11T02:45:18Z

I agree adding another number type to make a problem worse. I didn't think about adding the generic number type yet. I think it is very good direction to solve the problem having two different operators for int and float. I grab a chance to look into how int and float type value are handled during compilation while working on this PR. Actually, I couldn't find many reasons to separate two different type(int, float) for emitting the JS output except optimization of int32 for int type value.

How about defining the number type and deprecating the int, float type in future?(maybe we can come back and decide the deprecation later) I can start working on defininig the number type and simplifying the operators with another PR. How about it?

cristianoc · 2024-03-11T10:41:44Z

I suspect a number of users rely on the semantic difference between int and float. Eg with float it's easy to get 0.999999 while 1 is expected so simple equality does not work.

That's why I was suggesting a simple change at the level of type checker, which does not break existing code.
Just, decides at type checking time what number type is intended.

mununki · 2024-03-11T12:08:53Z

I found I missed the coercion for bigint, then I've added the commits b13884d @zth

mununki · 2024-03-11T12:15:20Z

I suspect a number of users rely on the semantic difference between int and float. Eg with float it's easy to get 0.999999 while 1 is expected so simple equality does not work.

That's why I was suggesting a simple change at the level of type checker, which does not break existing code. Just, decides at type checking time what number type is intended.

If I understand correctly, Do you mean letting the type checker infer types for arithmetic operations like it does for comparisons?

// Int operations
external \"+": (int, int) => int = "%addint"
// Float operations
external \"+.": (float, float) => float = "%addfloat"

// to

// Number operations
external \"+": ('a, 'a) => 'a = "%addnumber"

cristianoc · 2024-03-11T19:14:16Z

I suspect a number of users rely on the semantic difference between int and float. Eg with float it's easy to get 0.999999 while 1 is expected so simple equality does not work.

That's why I was suggesting a simple change at the level of type checker, which does not break existing code. Just, decides at type checking time what number type is intended.

If I understand correctly, Do you mean letting the type checker infer types for arithmetic operations like it does for comparisons?
// Int operations

external \"+": (int, int) => int = "%addint"

// Float operations

external \"+.": (float, float) => float = "%addfloat"



// to



// Number operations

external \"+": ('a, 'a) => 'a = "%addnumber"

Yes a bit like for comparison.
Except while fully polymorphic comparison exists, fully polymorphic addition does not.
One can't have a single function that works for both int and float, but needs to generate one or the other.
If the type is not constrained, one can default to int (backwards compatibility) or even give an error.

mununki · 2024-03-12T06:17:07Z

To summarize, if we'll discuss the issue of unifying the int and float operators separately, and if everyone agrees that open! Bigint and make the int operator available to bigint as well, I'm going to add commits for the exponential operator ** and additional optimizations to the comparison operator in this PR.

// exponentiation
let x = 1n ** 1n

// comparison optimization
let y = 1n == 1n
// compiled to var y = true;

zth · 2024-03-12T22:24:52Z

lib/es6/caml.js

+    return 0;
+  } else if (x < y) {
+    return -1;
+  } else if (x > y || x === x) {


Weird or clause

Oh good catch, I didn't notice because I was using the float_compare code as is. Why does float_compare have this branching as opposed to int_compare? Very weird to me too.

I think those conditions are for below test cases;

// float_test.res eq(__LOC__, float_compare(Js.Float._NaN, Js.Float._NaN), 0) eq(__LOC__, generic_compare(Js.Float._NaN, Js.Float._NaN), 0) eq(__LOC__, float_compare(Js.Float._NaN, neg_infinity), -1) eq(__LOC__, generic_compare(Js.Float._NaN, neg_infinity), -1) eq(__LOC__, float_compare(neg_infinity, Js.Float._NaN), 1) eq(__LOC__, generic_compare(neg_infinity, Js.Float._NaN), 1)

I don't know why float_compare was implemented this way at the time, but my best guess is that it was to capitalize on the fact that comparing NaNs is false.

-Infinity === -Infinity // true NaN === NaN // false

~~However, the bigint doesn't have a binding to Infinity or Nan for now. I'm going to fix bigint_compare as int_compare.~~

I changed my mind. I've added interop for NaN and methods to Js.Bigint, and also added the bigint_test.res test. Can you take a look? c972a13

That is the compare function. Those clauses are for the comparing with NaN.

I got your point. NaN can not be produced with BigInt operation. NaN is produced only below 5 cases:

There are five different types of operations that return NaN:

Failed number conversion (e.g. explicit ones like parseInt("blabla"), Number(undefined), or implicit ones like Math.abs(undefined))

Math operation where the result is not a real number (e.g. Math.sqrt(-1))

Indeterminate form (e.g. 0 * Infinity, 1 ** Infinity, Infinity / Infinity, Infinity - Infinity)

A method or expression whose operand is or gets coerced to NaN (e.g. 7 ** NaN, 7 * "blabla") — this means NaN is contagious

Other cases where an invalid value is to be represented as a number (e.g. an invalid Date new Date("blabla").getTime(), "".charCodeAt(1))

So wouldn't it be better to get rid of NaNs in Js_bigint as well?

Yes. NaN is obviously number type. Date, parseInt, Math are all about Number, not BigInt.

Thanks!

6601152
ea49c05

mununki · 2024-03-13T04:13:02Z

While I'm working on the comparison lambda, lam, I think I found there are some codes better to be cleaned up. E.g. the physical comparison (%eq, %noteq) is converted by int_comp for int and float. in js_exp_make.ml. However, the case of %noteq is being omitted from the optimization, and there seems to be some ambiguity in the function name. I'll open an issue and work on it in a separate PR.

mununki · 2024-03-13T12:01:13Z

I've finished adding the comparison operation optimization and exponetiation operator **, for bigint. I have nothing left for this PR now.

cometkim · 2024-03-15T14:47:15Z

jscomp/others/js_bigint.res

+therefore necessary to test for `_NaN`. Return `true` if the given value is
+`_NaN`, `false` otherwise. See [`isNaN`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isNaN) on MDN.
+*/
+external isNaN: bigint => bool = "isNaN"


I don't think this is necessary in bigint module. Unlike number, bigint operations (except comparison) cannot be mixed with other types and never produce NaN.

It makes sense to me.

cometkim · 2024-03-15T14:47:44Z

jscomp/others/js_bigint.res

+Js.Bigint.isFinite(1234.)
+```
+*/
+external isFinite: bigint => bool = "isFinite"


Same here. Js BigInt never produces Infinity

cometkim · 2024-03-15T14:56:31Z

lib/es6/caml.js

+    return 0;
+  } else if (x < y) {
+    return -1;
+  } else if (x > y || x === x) {


NaN is a concept that belongs to Number (typeof NaN === number), not BigInt. BigInt operations never produce NaN AFAIK

cometkim · 2024-03-17T20:15:18Z

jscomp/ml/translcore.ml

+      ("%negbigint", Pnegbigint);
+      ("%addbigint", Paddbigint);
+      ("%subbigint", Psubbigint);
+      ("%mulbigint", Pmulbigint);
+      ("%divbigint", Pdivbigint Safe);
+      ("%powbigint", Ppowbigint);
+      ("%modbigint", Pmodbigint Safe);
+      ("%eqbigint", Pbigintcomp Ceq);
+      ("%noteqbigint", Pbigintcomp Cneq);
+      ("%ltbigint", Pbigintcomp Clt);
+      ("%lebigint", Pbigintcomp Cle);
+      ("%gtbigint", Pbigintcomp Cgt);
+      ("%gebigint", Pbigintcomp Cge);


It seems %lslbigint(<<), %asrbigint(>>), %andbigint(&), %orbigint(|), %xorbigint(^) are missing? (not sure bitwise-not(~) op) Logical operators are the main interface of BigInt.

Note that >>>, Unsigned right shift doesn't accept BigInt.

Initially, I wasn't going to include the bitwise operation implementation in this PR because I was concerned that it would make the PR too large, but now that I think about it, it doesn't make much difference, so I'll add it.

Added 9060aa0

mununki · 2024-03-25T11:24:55Z

Sorry for rebasing during review, there was a conflict in the change log file.

cristianoc · 2024-03-26T08:08:04Z

jscomp/core/js_exp_make.ml

+let bigint_comp (cmp : Lam_compat.comparison) ?comment (e0: t) (e1: t) =
+  bin ?comment (Lam_compile_util.jsop_of_comp cmp) e0 e1
+
+let bigint_div ~checked ?comment (e0: t) (e1: t) =


looks like the option to disable checking divide by zero is really only hidden under some ancient internal-only configuration

at some point, it can be removed, perhaps in a later PR

cristianoc · 2024-03-26T08:10:16Z

jscomp/core/lam_analysis.ml

@@ -27,6 +27,7 @@ let not_zero_constant (x : Lam_constant.t) =
  match x with
  | Const_int { i } -> i <> 0l
  | Const_int64 i -> i <> 0L
+  | Const_bigint i -> i <> "0"


is this normalised, or are -0 and 00 also possible?

00 is normalized, but -0. I'll add another clause i <> "-0"

How about instead using a representation for Conts_bigint with a boolean (sign), and normalised string. So there's no confusion and it's less likely to introduce bugs in future.

Ah, very good. I'll refactor accordingly.

cristianoc · 2024-03-26T08:21:01Z

jscomp/others/js_bigint.res

+Js.Bigint.fromString("")
+
+/* returns 17n */
+Js.Bigint.fromString("0x11")


So this is not supported as literal, but can be constructed in this way via parsing right?

Correct, users can use this way for unsupported literal such as 0x11n

cristianoc · 2024-03-26T08:22:25Z

jscomp/others/js_bigint.res

+@val
+/**
+Parses the given `string` into a `bigint` using JavaScript semantics. Return the
+number as a `bigint` if successfully parsed, `null`, `undefined`, `_NaN` otherwise.


not sure what null, undefined, _NaN refers to.

It is invalid comment, I'll remove this part.

cristianoc · 2024-03-26T08:22:54Z

jscomp/others/js_bigint.res

+
+```rescript
+/* returns 123n */
+Js.Bigint.fromString("123")


is this called fromStringExn?

Oops, you're correct.

cristianoc · 2024-03-26T08:25:28Z

jscomp/others/js_bigint.res

+Js.Bigint.fromString("0o11")
+```
+*/
+external fromStringExn: string => bigint = "BigInt"


What's the exception? It would be good to have an example to see how to catch it.

JS BigInt constructor throws error such as Uncaught SyntaxError in case of passing a non-numeric value. I'll add an example .

cristianoc · 2024-03-26T08:30:56Z

jscomp/ml/bigint_utils.ml

+  | _ ->
+    (* If both numbers are either negative or positive, compare their lengths. *)
+    let len0, len1 = (String.length s0, String.length s1) in
+    if len0 = len1 then String.compare s0 s1  (* If lengths are equal, compare the strings directly. *)


this seems wrong for negative numbers

It seems fine to me. Can you elaborate the case wrong?
https://ocaml.org/play#code=bGV0IGNvbXBhcmUgczAgczEgPQogICgqIGNoZWNrIGlmIG5lZ2F0aXZlICopCiAgbGV0IGlzX25lZyBzID0gU3RyaW5nLmxlbmd0aCBzID4gMCAmJiBzLlswXSA9ICctJyBpbgogIG1hdGNoIChpc19uZWcgczAsIGlzX25lZyBzMSkgd2l0aAogIHwgKHRydWUsIGZhbHNlKSAtPiAtMSAgKCogSWYgb25seSBzMCBpcyBuZWdhdGl2ZSwgaXQncyBzbWFsbGVyLiAqKQogIHwgKGZhbHNlLCB0cnVlKSAtPiAxICAgKCogSWYgb25seSBzMSBpcyBuZWdhdGl2ZSwgczAgaXMgbGFyZ2VyLiAqKQogIHwgXyAtPgogICAgKCogSWYgYm90aCBudW1iZXJzIGFyZSBlaXRoZXIgbmVnYXRpdmUgb3IgcG9zaXRpdmUsIGNvbXBhcmUgdGhlaXIgbGVuZ3Rocy4gKikKICAgIGxldCBsZW4wLCBsZW4xID0gKFN0cmluZy5sZW5ndGggczAsIFN0cmluZy5sZW5ndGggczEpIGluCiAgICBpZiBsZW4wID0gbGVuMSB0aGVuIFN0cmluZy5jb21wYXJlIHMwIHMxICAoKiBJZiBsZW5ndGhzIGFyZSBlcXVhbCwgY29tcGFyZSB0aGUgc3RyaW5ncyBkaXJlY3RseS4gKikKICAgIGVsc2UgaWYgbGVuMCA%2BIGxlbjEgdGhlbiAKICAgICAgaWYgaXNfbmVnIHMwIHRoZW4gLTEgZWxzZSAxICAoKiBBIGxvbmdlciBzMCBtZWFucyBpdCdzIGxhcmdlciB1bmxlc3MgaXQncyBuZWdhdGl2ZS4gKikKICAgIGVsc2UgICgqIGxlbjAgPCBsZW4xICopCiAgICAgIGlmIGlzX25lZyBzMSB0aGVuIDEgZWxzZSAtMSAgKCogQSBsb25nZXIgczEgbWVhbnMgczAgaXMgc21hbGxlciB1bmxlc3MgczEgaXMgbmVnYXRpdmUuICopCgpsZXQgKCkgPQooKiBsZW4wIDwgbGVuMSAgKikKICBhc3NlcnQoKGNvbXBhcmUgIi0xIiAiLTEwIiA9IDEpKTsKICBhc3NlcnQoKGNvbXBhcmUgIjEiICItMTAiID0gMSkpOwogIGFzc2VydCgoY29tcGFyZSAiLTEiICIxMCIgPSAtMSkpOwooKiBsZW4wID4gbGVuMSAgKikKICBhc3NlcnQoKGNvbXBhcmUgIi0xMDAiICItMTAiID0gLTEpKTsKICBhc3NlcnQoKGNvbXBhcmUgIjEwMCIgIi0xMCIgPSAxKSk7CiAgYXNzZXJ0KChjb21wYXJlICItMTAwIiAiMTAiID0gLTEpKTsKKCogbGVuMCA9IGxlbjEgICopCiAgYXNzZXJ0KChjb21wYXJlICItMTAiICItMTAiID0gMCkpOwogIGFzc2VydCgoY29tcGFyZSAiMTAiICItMTAiID0gMSkpOwogIGFzc2VydCgoY29tcGFyZSAiLTEwIiAiMTAiID0gLTEpKTsKICBwcmludF9lbmRsaW5lICJ0ZXN0IHBhc3NpbmchIg%3D%3D

Ah, I figure it out this case is wrong assert((compare "-10" "-12" = 1)) I'll fix it.

cristianoc · 2024-03-26T08:33:12Z

jscomp/ml/bigint_utils.ml

+  000n -> 0n
+  001n -> 1n
+  01_000_000n -> 1000000n
+  0x1 -> 0x1n


this is now a syntax error too right?

cristianoc · 2024-03-26T08:33:19Z

jscomp/ml/bigint_utils.ml

+  001n -> 1n
+  01_000_000n -> 1000000n
+  0x1 -> 0x1n
+  0x001n -> 0x001n


cristianoc · 2024-03-26T08:42:23Z

jscomp/frontend/external_ffi_types.ml

@@ -300,6 +300,9 @@ let inline_int_primitive (i : int32) : string list =
 let inline_int64_primitive (i : int64) : string list =
  [""; to_string (Ffi_inline_const (Const_int64 i))]

+let inline_bigint_primitive (i : string) : string list =
+  [""; to_string (Ffi_inline_const (Const_bigint i))]


This does not check that the bigint is valid, or remove leading zero's.
Don't know if this is a problem, just observing the fact.

One possibility is to do the check is_numeric at parsing time, instead of type checking time. And do the normalisation (remove zeros) whenever a Const_bigint is constructed.

Very good. I'm going to try to refactor Const_bigint bool * string in AST type.

I've changed the model of bigint in asttypes.ml, lam_constant.ml and js_op.ml

9652115

What do you think?

cristianoc · 2024-03-27T07:27:38Z

jscomp/core/js_op.ml

 type number =
  | Float of float_lit
  | Int of { i : int32; c : int option }
  | Uint of int32
-  | Bigint of bigint_lit
+  | Bigint of bool * string


Small style suggestion keep bigint_lit as { positive: bool; value: string }

Good, it seems not going to be unboxed, still okay?

The difference is going to be tiny in practice.

cristianoc · 2024-03-27T07:30:17Z

jscomp/core/js_exp_make.ml

-  | Bigint i -> bigint i
+  | Bigint i -> 
+    let open Bigint_utils in
+    let sign, i = i |> remove_leading_sign in


style/naming: perhaps:
let {positive, value} = parse_bigint i
where parse_bigint also removes the leading zeros, so there's no way one can forget to do that

cristianoc · 2024-03-27T07:35:41Z

jscomp/core/lam.ml

@@ -506,7 +506,7 @@ let prim ~primitive:(prim : Lam_primitive.t) ~args loc : t =
          (* FIXME: could raise? *)
          Lift.bool
            (Lam_compat.cmp_float cmp (float_of_string a) (float_of_string b))
-      | Pbigintcomp cmp, Const_bigint a, Const_bigint b -> default ()
+      | Pbigintcomp cmp, Const_bigint (_, a), Const_bigint (_, b) -> default ()


nit: here a and b are never used, I thought the compiler would give a warning

cristianoc · 2024-03-27T07:39:47Z

jscomp/ml/bigint_utils.ml

+  if len = 0 then (false, str)
+  else
+    if is_neg str || is_pos str then (not (is_neg str), String.sub str 1 (len -1))
+    else (not (is_neg str), str)


nit: in this branch is_neg is impossible, so just (true, str)

cristianoc · 2024-03-27T07:45:35Z

jscomp/ml/parmatch.ml

-      (function Tpat_constant(Const_bigint i) -> String.length i | _ -> assert false)
-      (function i -> Tpat_constant(Const_bigint (String.make i '*')))
+      (function Tpat_constant(Const_bigint (sign, i)) -> String.length (Bigint_utils.to_string sign i) | _ -> assert false)
+      (function i -> Tpat_constant(Const_bigint (true, (String.make i '*'))))


not sure what (String.make i '*') is doing here?
I would have guessed string_of_int i instead.
Not sure how to trigger this code path, perhaps with some example?

Not sure. I guess this function is used in pattern matching for gadt partially. But logically I think we can change (String.make i '*') to string_of_int i here for less space complexity.

cristianoc · 2024-03-27T07:46:41Z

jscomp/syntax/src/res_core.ml

@@ -812,6 +812,12 @@ let parseConstant p =
  let constant =
    match p.Parser.token with
    | Int {i; suffix} ->
+      (* Only decimal literal is allowed for bigint *)
+      if suffix = Some 'n' && not (Bigint_utils.is_numeric i) then


nit: perhaps is_numeric could be called is_valid?

cristianoc · 2024-03-27T07:47:08Z

jscomp/syntax/src/res_core.ml

+      if suffix = Some 'n' && not (Bigint_utils.is_numeric i) then
+        Parser.err p
+          (Diagnostics.message
+             "Invalid decimal literal. Only decimal literal is allowed for \


perhaps "Invalid bigint literal. Only decimal...".

mununki · 2024-03-27T09:17:20Z

Fixed as reviewed. d82b4bc

cristianoc

Looks good to go!
Anything missing?

mununki · 2024-03-27T10:22:15Z

Nothing left.
Thank you for your good reviews!

zth · 2024-03-27T10:28:10Z

Fantastic @mununki , well done! 👏

mununki requested review from cristianoc, cknitt and zth March 8, 2024 07:30

mununki force-pushed the bigint branch from 31c3aee to cd5f765 Compare March 8, 2024 12:13

cometkim requested changes Mar 8, 2024

View reviewed changes

zth reviewed Mar 9, 2024

View reviewed changes

mununki requested a review from cometkim March 11, 2024 13:09

zth reviewed Mar 12, 2024

View reviewed changes

mununki mentioned this pull request Mar 13, 2024

Unified Operator Proposal for int, float, and bigint #6673

Open

fhammerschmidt mentioned this pull request Mar 13, 2024

Add BigInt primitive number type #4677

Closed

cometkim reviewed Mar 15, 2024

View reviewed changes

mununki requested a review from cometkim March 17, 2024 08:46

cometkim reviewed Mar 17, 2024

View reviewed changes

mununki requested a review from cometkim March 18, 2024 02:19

mununki added 8 commits March 25, 2024 20:23

add tests for pattern matching bigint liternal

379dc31

support only decimal bigint literal and pattern matching

990e5ac

fix test

0d40dd9

handle delimiter '_'

79c7013

throw Division_by_zero in bigint div, mod

5748e83

call runtime only when dividing by zero

4a43e39

fix incorrect dividing by zero with non constant

e7e41c4

remove is_safe from Pdivbigint, Pmodbigint

e8e8050

mununki force-pushed the bigint branch from 649dc3e to e8e8050 Compare March 25, 2024 11:23

cristianoc reviewed Mar 26, 2024

View reviewed changes

mununki added 3 commits March 26, 2024 19:56

stale comments

5e963cd

fix bigint_utils.compare

84eecd7

change bigint model to sign * string

9652115

cristianoc reviewed Mar 27, 2024

View reviewed changes

clean up

d82b4bc

cristianoc approved these changes Mar 27, 2024

View reviewed changes

zth merged commit f0dda99 into 11.0_release Mar 27, 2024
14 checks passed

zth deleted the bigint branch March 27, 2024 10:28

mununki mentioned this pull request Mar 27, 2024

RFC: Introducing the Bigint #6525

Closed

Introducing the bigint #6670

Introducing the bigint #6670

Conversation

mununki commented Mar 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zth commented Mar 8, 2024

mununki commented Mar 8, 2024

zth commented Mar 8, 2024

zth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cristianoc commented Mar 9, 2024

zth commented Mar 9, 2024

cknitt commented Mar 9, 2024

cristianoc commented Mar 9, 2024

cometkim commented Mar 10, 2024

mununki commented Mar 11, 2024

cristianoc commented Mar 11, 2024

mununki commented Mar 11, 2024

mununki commented Mar 11, 2024

cristianoc commented Mar 11, 2024 • edited Loading

mununki commented Mar 12, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mununki Mar 13, 2024 • edited Loading

Choose a reason for hiding this comment

mununki Mar 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mununki commented Mar 13, 2024 • edited Loading

mununki commented Mar 13, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cometkim Mar 15, 2024 • edited Loading

Choose a reason for hiding this comment

cometkim Mar 17, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mununki commented Mar 25, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cristianoc Mar 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mununki Mar 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cristianoc Mar 27, 2024 • edited Loading

Choose a reason for hiding this comment

mununki commented Mar 8, 2024 •

edited

Loading

cristianoc commented Mar 11, 2024 •

edited

Loading

mununki Mar 13, 2024 •

edited

Loading

mununki Mar 13, 2024 •

edited

Loading

mununki commented Mar 13, 2024 •

edited

Loading

cometkim Mar 15, 2024 •

edited

Loading

cometkim Mar 17, 2024 •

edited

Loading

cristianoc Mar 26, 2024 •

edited

Loading

mununki Mar 26, 2024 •

edited

Loading

cristianoc Mar 27, 2024 •

edited

Loading

cristianoc Mar 27, 2024 •

edited

Loading

cristianoc Mar 27, 2024 •

edited

Loading