This is from the JSON-LD spec.
General Discussion
5
Posts
2
Posters
0
Views
-
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.
-
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.
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 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.
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 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.
@reiver that's a json thing, which is itself a JavaScript thing. JS doesn't have an integer type, only number, which is a double precision floating point. Json is a serialization spec for JavaScript objects, and jsonld is spec for pretending that adding one property to a json document makes it a collection of rdf triples and then getting mad about it when the rest of the world just wants things to be parseable
-
@reiver that's a json thing, which is itself a JavaScript thing. JS doesn't have an integer type, only number, which is a double precision floating point. Json is a serialization spec for JavaScript objects, and jsonld is spec for pretending that adding one property to a json document makes it a collection of rdf triples and then getting mad about it when the rest of the world just wants things to be parseable
AFAIK, it is an IETF JSON thing, and wasn't part of the original (pre-IETF) JSON.
Here's the oldest version of the JSON spec I could find:
https://web.archive.org/web/20030228034147/http://www.crockford.com/JSON/index.html
It defines "number" as in the screen-shot, and doesn't say anything about floating-point numbers.
...
I do agree with you that the reason IETF JSON talked about floating-point numbers is almost certainly because of JavaScript.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
AFAIK, it is an IETF JSON thing, and wasn't part of the original (pre-IETF) JSON.
Here's the oldest version of the JSON spec I could find:
https://web.archive.org/web/20030228034147/http://www.crockford.com/JSON/index.html
It defines "number" as in the screen-shot, and doesn't say anything about floating-point numbers.
...
I do agree with you that the reason IETF JSON talked about floating-point numbers is almost certainly because of JavaScript.
-
@reiver that's a json thing, which is itself a JavaScript thing. JS doesn't have an integer type, only number, which is a double precision floating point. Json is a serialization spec for JavaScript objects, and jsonld is spec for pretending that adding one property to a json document makes it a collection of rdf triples and then getting mad about it when the rest of the world just wants things to be parseable
-
@silverpill @sabrinkmann @naturzukunft2026 @julian
i should use socialhub more... i'll catchup on the dicussion, soon
-
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.
-
@smallcircles @ben Unfortunately, the top-down approach often stalls under its own inertia and never develops into anything at all.
If you try for too much interoperability too fast, the costs aren't evenly distributed: some implementors will have to make very few changes (usually the ones who had the most power and influence during the standardisation process), while others will have to tear up a lot of stuff and start over.
In the business/government/aid world, that can have ripples far beyond the IT systems, right into the way they organise their operations; in the FOSS world, it can mean abandoning popular features, losing users, and even destroying the contributor culture.
An 800 lb gorilla like Walmart can force that level.of dirigisme on its suppliers, but in the open world, we can just ignore or fork if we think someone's getting too restrictive: note how most web syndicators stuck with RSS 2.0 even after Atom came along to "fix" its "problems," for example (and Atom wasn't even that bad). 🤷
-
@naturzukunft2026@mastodon.social yes that's correct, it's just a flat list for ease of processing. The tree building takes place after all of the objects are received and processed.
