There is a larger discussion about fixed-point numbers versus floating-point numbers.
And that, ALL programming-languages should have fixed-point numbers built into them.
And that, programmers should be warned against using floating-point numbers in all but a set of very specialized situations — where inexact math is OK.
For most programmers in most situations inexact math is NOT OK. And, they should NOT use floating-point numbers.
This is likely (directly or indirectly) the fault of a single paragraph in IETF RFC-7159 / RFC-8259 (shown in the attached screen-shot).
(And note that, there is a difference between JSON and IETF JSON. JSON did not have this. IETF JSON does.)
That paragraph (in the IETF RFC) was NOT a requirement. But, others made it a requirement — including JSON-LD.
This is from the JSON-LD spec.
ActivityPub / ActivityStream are based on JSON-LD.
I think it was a very bad idea for JSON-LD to define "number" this way!
It makes it so numbers with fractional values are inexact & lossy.
This include values that are common for money.
For example, neither 0.10 and 0.20 can be represented exactly. So, 0.10 + 0.20 does NOT equal 0.30!
It should have used FIXED-point numbers rather than FLOATING-point.
JSON and IETF JSON feel different in spirit in some important ways to me.
For example, numbers.
JSON doesn't seem to put constraints on numbers. JSON also doesn't seem to suggest that decoding numbers in a lossy way is acceptable
IETF JSON suggests a constraint and even a lossy-ness on numbers that has been included some JSON implementations
I would have preferred that the paragraph in the screen-shot, from the latest IETF RFC, did not exist in there
A quick reminder that "standards compliant" doesn't mean that something is any good:
@reiver ⊼ (Charles) 
mathew