What even is a JSON number?

Post by akubera » Tue, Apr 02, 2024, 5:12 AM UTC

kccqzy wrote: post #68

akubera wrote: post #54

Earlier quoted context omitted.

I was attempting to solve this very problem in the Rust BigDecimal crate this weekend. Is it better to just let it crash with an out of memory error, or have a compile-time constant limit (I was thinking ~8 billion digits) and panic if any operation would exceed that limit with a more specific error-message (does that mean it's no longer arbitrary-precision?). Or keep some kind of overflow-state/nan, but then the com…

I think Haskell's warning-in-the-doc approach is not strong enough. I'd be in favor of distinguishing small and huge values using the type system. Have a Rust enum that contains either a small-ish number (the absolute value being 10^100 or less, but the threshold should be configurable preferably as a type parameter) or a huge number. Then the user will be required to handle it. Most of the time the user does not wan…

Post by jbboehr » Tue, Apr 02, 2024, 6:30 AM UTC

bterlson wrote: post #57

js2 wrote: post #51

Earlier quoted context omitted.

If you're going to extend Go the courtesy of customizing the parser, oughtn't you do the same for Python (and all the languages)? To wit, Python's json module has `parse_float` and `parse_int` hooks: https://docs.python.org/3/library/json.html#encoders-and-dec... Example: >>> json.loads('{"int":12345,"float":123.45}', parse_int=str, parse_float=str) {'int': '12345', 'float': '123.45'} FWIW, when I've cared about inte…

I'm just a JS guy trying to understand the world around me and documenting what I find, not trying to be discourteous (or even courteous). I'll add the note about Python, thanks for calling it out. FWIW JS does not have a similar capability so I can't add a note there.

  const bigJSON = '{"gross_gdp": 12345678901234567890}';
  const bigObj = JSON.parse(bigJSON, (key, value, context) => {
    if (key === "gross_gdp") {
      // Ignore the value because it has already lost precision
      return BigInt(context.source);
    }
    return value;
  });

Post by Dylan16807 » Tue, Apr 02, 2024, 7:11 AM UTC

golergka wrote: post #66

greggyb wrote: post #65

Earlier quoted context omitted.

Until you want faster joins, in which case, comparisons of integers tend to be much faster on hardware I am aware of than string comparisons.

We're talking about deserialising JSONs in the application server here, nobody stops you from treating ids as numbers on the database side of things. But also, this sounds like a premature optimisation. Most applications will never reach a level where their performance is actually impacted by string comparison, and when you reach that stage, you're likely have already thrown out a lot of other common sense stuff like…

Post by jillesvangurp » Tue, Apr 02, 2024, 7:37 AM UTC

yawaramin wrote: post #76

Long story short: don't use JSON numbers to represent money or monetary rates. Always use decimals encoded as string. It's surprising how many APIs fall short of this basic bar.

Post by CJefferson » Tue, Apr 02, 2024, 7:48 AM UTC

akubera wrote: post #54

kccqzy wrote: post #28

I'll add that for Haskell, the library everyone uses for JSON parses numbers into Scientific types with almost unlimited size and precision. I say almost unlimited because they use a decimal coefficient-and-exponent representation where the exponent is a 64-bit integer. The documentation is quite paranoid that if you are dealing with untrusted inputs, you could parse two JSON numbers from the untrusted source fine an…

I was attempting to solve this very problem in the Rust BigDecimal crate this weekend. Is it better to just let it crash with an out of memory error, or have a compile-time constant limit (I was thinking ~8 billion digits) and panic if any operation would exceed that limit with a more specific error-message (does that mean it's no longer arbitrary-precision?). Or keep some kind of overflow-state/nan, but then the com…