Should we add handling for BigInt or BigNumber?

[JohnBrinkman]

Pros:

• Would solve a set of interesting use-cases
• Would fix floating point precision issues

Cons

• Implementations will need 3rd party libraries
• Big Number and Big Int cannot be represented in JSON. Would need conversion functions to/from string
• Would require a new suite of purpose-built operators and functions
• The set of use cases it solves likely does not justify the implementation cost and added complexity

Could we implement Big Number math using existing formulas?

Some limited support seems possible. Here's a sample that registers a function to add two numbers (represented as strings) by:

• converting the number strings to arrays using split()
• adding the arrays
• reducing the arrays to handle the carry using reduce()
• convert the arrays back to a string using join():

register("_bigAdd", 
&(
  split(@[0], "").reverse(@) + 
  split(@[1], "").reverse(@)
).reduce(@, 
 &{
   result: accumulated.result,
   d: accumulated.carry + current
  }.{
   result: result ~ if(d>=10, d-10, d),
   carry: if (d >= 10, 1, 0)
  },
  {result: `[]`, carry: 0}
).if(carry, result ~ 1, result)
.reverse(@)
.join(@, "")
)

_bigAdd(["12345", "6789"]) => "19134"

_bigAdd(["2147483647", "97852516353"]) => "100000000000"

A brute force multiplication function could be registered by leveraging bigAdd():

register("_bigMultiply", 
&{
  a1: rept(@[0] & ",", length(@[1])).split(@, ","),
  a2: @[1].split(@, "").reverse(@)
}.zip(a1,a2)
.map(@, &rept(@[0] & ",", @[1]).split(@, ",")[?@])
.map(@, &reduce(@, &_bigAdd([accumulated, current]), "0"))
.reduce(@, &_bigAdd([accumulated, current & rept("0", index)]), "0"))

Then _bigMultiply(["12345", "6789"]) => "83810205"

[JohnBrinkman]

Received for information.