[ntuple] Precision loss for big integer values

[undefined-panda]

When reading RNTuple data, Int64/UInt64 values above Number.MAX_SAFE_INTEGER or below Number.MIN_SAFE_INTEGER lose precision because they're cast to Number in rntuple.mjs:

// FIXME: let process BigInt in the TTree::Draw
obj[this.name] = Number(this.view.getBigInt64(this.o, LITTLE_ENDIAN));

The FIXME comment suggests this is known. Since Number and BigInt are distinct types in JS, would it make sense to return a BigInt only when the value doesn't fit in a safe integer, and a Number otherwise? Something like:

const num = this.view.getBigInt64(this.o, LITTLE_ENDIAN);
const MIN = BigInt(Number.MIN_SAFE_INTEGER);
const MAX = BigInt(Number.MAX_SAFE_INTEGER);
obj[this.name] = (num >= MIN && num <= MAX) ? Number(num) : num;

I could open a PR if this direction makes sense, though I'm not sure how it interacts with TTree::Draw.

[linev]

One can make extra argument for treeProcess function which let keep BigInt values.
So one get at least all values with TSelector correctly.

But processing in treeDraw is more complicated.
There one has several use-cases, and BigInt has to be handled separately.
Main problem there - use of BigInt in generic arithmetic expressions.
One cannot simply mix Number and BigInt - unfortunately.

[undefined-panda]

Its unfortunate that there is no elegant way of processing BigInt and Number in JS. Here is a proposal for an extra convertBigInt argument to process rntupleDraw slightly different:

// in rntuple.mjs
class ReaderItem {

   constructor(column, name, convertBigInt) {
      this.column = null;
      this.name = name;
      this.id = -1;
      this.coltype = 0;
      this.sz = 0;
      this.simple = true;
      this.page = -1; // current page for the reading
      this.convertBigInt = convertBigInt;
   ...
         case kIndex64:
            this.func = function(obj) {
               const val = this.view.getBigInt64(this.o, LITTLE_ENDIAN)
               obj[this.name] = this.convertBigInt ? Number(val) : val;
               this.shift_o(8);
            };
            this.sz = 8;
            break;
         case kUInt64:
            this.func = function(obj) {
               const val = this.view.getBigUint64(this.o, LITTLE_ENDIAN)
               obj[this.name] = this.convertBigInt ? Number(val) : val;
               this.shift_o(8);
            };
            this.sz = 8;
            break;
   ...
}

async function rntupleProcess(rntuple, selector, args = {}) {
   const {convertBigInt = false, ...restArgs} = args;
   ...
   function addColumnReadout(column, tgtname) {
      const item = new ReaderItem(column, tgtname, convertBigInt);
      item.assignReadFunc();
      handle.columns.push(item);
      return item;
   }
   ...
}

async function rntupleDraw(rntuple, args) {
   if (isStr(args))
      args = { expr: args };
   else if (!isObject(args))
      args = {};

   args.SelectorClass = TDrawSelectorTuple;
   args.processFunction = rntupleProcess;
   args.convertBigInt = true;

   treeDrawCall = true;

   return readHeaderFooter(rntuple).then(builder => {
      return builder ? treeDraw(rntuple, args) : null;
   });
}

Would that be suitable?

[linev]

But probably something like args.preserveBigInt. Then default false or undefined will untouch current behavior.

[linev]

Fixed in #418