Optimize serialization of small integers

[fingolfin]

Although this provides a speed up we would need to introduce a limit on Ints to be serialized as number since they could be turned into floats depending on the implementation of the JSON reader. Here we serialize Ints as JSON Numbers when the integer is between 1 - 2^53 and 2^53 - 1 and strings otherwise. However on load we need to check type to know whether we need to parse or not, and this is a big drawback.

I think it would be worth a try, in a separate branch, to try exactly that: whenever an Int is between 1 - 2^53 and 2^53 - 1, we write it as an Int/Float, otherwise as a string. Then, for a semi-randomly selected set of test cases, we can compare the file sizes and timings for write and read.

FYI: @benlorenz

Originally posted by @micjoswig in #4558

[fingolfin]

This also is relevant for e.g. finite field elements in prime fields of size $< 2^{53}$. There we could also encode the coefficients with JSON ints (this may be "automatic" if serialization of integers is adjusted to store small values as JSON floats). E.g.

julia> R,x = F[:x]
(Univariate polynomial ring in x over F, x)

julia> vec = [x, x^3 - 5,  (x^3 - 3*x +1)^4]
3-element Vector{FqPolyRingElem}:
 x
 x^3 + 252
 x^12 + 245*x^10 + 4*x^9 + 54*x^8 + 221*x^7 + 155*x^6 + 108*x^5 + 45*x^4 + 153*x^3 + 54*x^2 + 245*x + 1

julia> save("foo.json", vec)

produces this:

   "data" : [
      [
         [ "1", "1" ]
      ],
      [
         [ "0", "252" ],
         [ "3", "1" ]
      ],
      [
         [ "0", "1" ],
         [ "1", "245" ],
         [ "2", "54" ],
         [ "3", "153" ],
         [ "4", "45" ],
         [ "5", "108" ],
         [ "6", "155" ],
         [ "7", "221" ],
         [ "8", "54" ],
         [ "9", "4" ],
         [ "10", "245" ],
         [ "12", "1" ]
      ]
   ]

In addition to encoding the coefficients (which are in the range 0-256) as strings, it also stores the dense univariate polynomials sparsely (that's otherwise a central design decision in OSCAR: multivariate polynomials are stored sparse, univariate one are store dense -- it seems odd not to follow that here). So the above could be:

   "data" : [
      [
         1
      ],
      [
         252,
         1
      ],
      [
         1,
         245,
         54,
         153,
         45,
         108,
         155,
         221,
         54,
         4,
         245,
         1
      ]
   ]

[lgoettgens]

(that's otherwise a central design decision in OSCAR: multivariate polynomials are stored dense, univariate one are store sparse, it seems odd not to follow that here)

I think you mixed the two cases up here