• deegeese@sopuli.xyz
    link
    fedilink
    arrow-up
    31
    ·
    2 days ago

    If you’re using a library to handle deserialization , the ugliness of the serial format doesn’t matter that much.

    Just call yaml.load() and forget about it.

    • BodilessGaze@sh.itjust.works
      link
      fedilink
      arrow-up
      7
      arrow-down
      1
      ·
      2 days ago

      That works until you realize your calculations are all wrong due to floating point inaccuracies. YAML doesn’t require any level of precision for floats, so different parsers on a document may give you different results.

      • deegeese@sopuli.xyz
        link
        fedilink
        arrow-up
        13
        ·
        2 days ago

        What text based serialization formats do enforce numeric precision?

        AFAIK it’s always left up to the writer (serializer)

        • squaresinger@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          9 hours ago

          Technically, JSON enforces a specific numeric precision by enforcing that numbers are stored as JS-compatible floating point numbers with its associated precision.

          Other than that, the best way to go if you want to have a specific precision is to cast to string before serialisation.

        • BodilessGaze@sh.itjust.works
          link
          fedilink
          arrow-up
          6
          ·
          edit-2
          2 days ago

          Cuelang: https://cuelang.org/docs/reference/spec/#numeric-values

          Implementation restriction: although numeric values have arbitrary precision in the language, implementations may implement them using an internal representation with limited precision. That said, every implementation must:

          • Represent integer values with at least 256 bits.
          • Represent floating-point values with a mantissa of at least 256 bits and a signed binary exponent of at least 16 bits.
          • Give an error if unable to represent an integer value precisely.
          • Give an error if unable to represent a floating-point value due to overflow.
          • Round to the nearest representable value if unable to represent a floating-point value due to limits on precision. These requirements apply to the result of any expression except for builtin functions, for which an unusual loss of precision must be explicitly documented.
          • deegeese@sopuli.xyz
            link
            fedilink
            arrow-up
            3
            ·
            edit-2
            18 hours ago

            Thanks for teaching me something, but the obscurity of your answer just illustrates how rare that requirement is in human readable formats, and mostly limited to data formats designed for numeric precision, like HDF5, FITS or protobuf.

            • BodilessGaze@sh.itjust.works
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              19 hours ago

              I don’t think having well-defined precision is a rare requirement, it’s more that most devs don’t understand (and/or care) about the pitfalls of inaccuracy, because they usually aren’t obvious. Also, languages like JavaScript/PHP make it hard to do things the right way. When I was working on an old PHP codebase, I ran into a popular currency library (Zend_Currency) that used floats for handling money, which I’m sure works fine up until the point the accountants call you up asking why they can’t balance the books. The “right way” was to use the bcmath extension, which was a huge pain.