Discussion
Loading...

Discussion

Log in
  • About
  • Code of conduct
  • Privacy
  • About Bonfire
@reiver ⊼ (Charles) :batman:
@reiver ⊼ (Charles) :batman:
@reiver@mastodon.social  ·  activity timestamp 2 days ago

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.

RE: https://mastodon.social/@reiver/115956356584464586

#ActivityPub #ActivityStreams #JSONLD #RFC7159 #RFC8259

This specification allows implementations to set limits on the range and precision of numbers accepted.  Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision.  A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.
This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.
This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.
  • Copy link
  • Flag this post
  • Block
julian
julian
@julian@activitypub.space  ·  activity timestamp yesterday

@reiver@mastodon.social pretty sure this kind of ambiguios why Stripe represents everything in cents, no? 😏

  • Copy link
  • Flag this comment
  • Block
@reiver ⊼ (Charles) :batman:
@reiver ⊼ (Charles) :batman:
@reiver@mastodon.social  ·  activity timestamp yesterday

@julian

Yes, very likely.

When I built the core software for a bank more than a decade ago, I did the same.

  • Copy link
  • Flag this comment
  • Block
Jenniferplusplus
Jenniferplusplus
@jenniferplusplus@hachyderm.io  ·  activity timestamp 2 days ago

@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

  • Copy link
  • Flag this comment
  • Block
@reiver ⊼ (Charles) :batman:
@reiver ⊼ (Charles) :batman:
@reiver@mastodon.social  ·  activity timestamp yesterday

@jenniferplusplus

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.

Sorry, no caption provided by author
Sorry, no caption provided by author
Sorry, no caption provided by author
  • Copy link
  • Flag this comment
  • Block
@reiver ⊼ (Charles) :batman:
@reiver ⊼ (Charles) :batman:
@reiver@mastodon.social  ·  activity timestamp 2 days ago

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.

RE: https://mastodon.social/@reiver/115956356584464586

#ActivityPub #ActivityStreams #JSONLD #RFC7159 #RFC8259

This specification allows implementations to set limits on the range and precision of numbers accepted.  Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision.  A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.
This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.
This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.
  • Copy link
  • Flag this comment
  • Block
@reiver ⊼ (Charles) :batman:
@reiver ⊼ (Charles) :batman:
@reiver@mastodon.social  ·  activity timestamp 2 days ago

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.

#ActivityPub #ActivityStreams #JSONLD #RFC7159 #RFC8259

  • Copy link
  • Flag this comment
  • Block

BT Free Social

BT Free is a non-profit organization founded by @ozoned@btfree.social . It's goal is for digital privacy rights, advocacy and consulting. This goal will be attained by hosting open platforms to allow others to seamlessly join the Fediverse on moderated instances or by helping others join the Fediverse.

BT Free Social: About · Code of conduct · Privacy ·
Bonfire social · 1.0.2-alpha.34 no JS en
Automatic federation enabled
Log in
Instance logo
  • Explore
  • About
  • Code of Conduct