Loading ...
Sorry, an error occurred while loading the content.

Re: Floating point leading zero problem

Expand Messages
  • Douglas Crockford
    ... 0.625 a correct JSON number, and is accepted by org.json.JSONObject and by json2.js.
    Message 1 of 5 , Jan 18, 2010
    • 0 Attachment
      --- In json@yahoogroups.com, "glanca" <guy@...> wrote:
      >
      > I'm using the JSON_Parser C library on one end and the org.json Java library on the other and they don't agree on the encoding for the floating point value 0.625. The diagram on the JSON.org website suggests that the leading zero is okay whereas the RFC4627 specification states that "Leading zeros are not allowed." for numbers. The org.json won't accept the leading zero and the JSON_Parser library won't accept a leading decimal point.
      >
      > Which is right and which is wrong?

      0.625 a correct JSON number, and is accepted by org.json.JSONObject and by json2.js.
    • John Cowan
      ... If that remark were interpreted literally, then 0 would not be a valid JSON number, which is absurd. In context, it clearly means that if the integer part
      Message 2 of 5 , Jan 18, 2010
      • 0 Attachment
        glanca scripsit:

        > I'm using the JSON_Parser C library on one end and the org.json
        > Java library on the other and they don't agree on the encoding for
        > the floating point value 0.625. The diagram on the JSON.org website
        > suggests that the leading zero is okay whereas the RFC4627 specification
        > states that "Leading zeros are not allowed." for numbers.

        If that remark were interpreted literally, then 0 would not be a valid
        JSON number, which is absurd. In context, it clearly means that if
        the integer part is other than zero, it must not begin with a 0 digit.
        The RFC 4627 grammar clearly shows that the integer part is mandatory,
        so 0.625 is the correct representation and .625 is incorrect.

        > The org.json won't accept the leading zero and the JSON_Parser library
        > won't accept a leading decimal point.
        >
        > Which is right and which is wrong?

        The org.json implementation is wrong; the JSON_Parser library is right.

        --
        Why are well-meaning Westerners so concerned that John Cowan
        the opening of a Colonel Sanders in Beijing means cowan@...
        the end of Chinese culture? [...] We have had http://www.ccil.org/~cowan
        Chinese restaurants in America for over a century,
        and it hasn't made us Chinese. On the contrary,
        we obliged the Chinese to invent chop suey. --Marshall Sahlins
      • glanca
        ... right. ... Thanks for the quick feedback guys. Looking further in to what the org.json Java library is doing reveals this comment: /* * If it might be a
        Message 3 of 5 , Jan 19, 2010
        • 0 Attachment
          --- In json@yahoogroups.com, John Cowan <cowan@...> wrote:
          >
          > The org.json implementation is wrong; the JSON_Parser library is
          right.
          >

          Thanks for the quick feedback guys. Looking further in to what the
          org.json Java library is doing reveals this comment:

          /*
          * If it might be a number, try converting it. We support the 0- and 0x-
          * conventions. If a number cannot be produced, then the value will just
          * be a string. Note that the 0-, 0x-, plus, and implied string
          * conventions are non-standard. A JSON parser is free to accept
          * non-JSON forms as long as it accepts all correct JSON forms.
          */

          The word "try" is meant literally in that it uses try blocks and the
          code is throwing an exception when handling the legal string "0.625". I
          consider exceptions to be *of interest* and therefore trap on them and
          the code doesn't throw an exception on the non-standard value ".625",
          thus my confusion when I read the spec. With a leading zero it does
          eventually manage to return the correct Double object but only after
          dumping a stack trace.

          It looks like a simple re-arrangement should resolve my problem but I'm
          not set up to do regression testing against the specifications. For now
          I'll probably just comment out the contents of the catch block (which
          just dumps a stack trace) and if I do try to fix it I'll try sending a
          patch to the anonymous feedback address for the code.

          Thanks again.

          -- Guy




          [Non-text portions of this message have been removed]
        • Mark Joseph
          This is our first release of our combined JSON XML product SDK Press Release: https://www.p6r.com/company/news.html Product Page:
          Message 4 of 5 , May 10, 2010
          • 0 Attachment
            This is our first release of our combined JSON XML product SDK

            Press Release: https://www.p6r.com/company/news.html
            Product Page: https://www.p6r.com/software/xjr.html


            Regards,

            Mark Joseph, Ph.D.
            President
            P6R, Inc
            408-205-0361
            mark@...
            Skype: markjoseph_sc



            [Non-text portions of this message have been removed]
          Your message has been successfully submitted and would be delivered to recipients shortly.