• b3nsn0w@lemmy.world
    link
    fedilink
    arrow-up
    7
    ·
    2 hours ago

    duh, it’s part of the IEEE 754 standard. every language that handles floating point numbers has NaN handling, and in every language NaN is a float. the only reason this is brought up as a javascript thing all the time is that js doesn’t have separate float and int types (aside from special structures like typed arrays and dataviews), it just defaults to float64 for simplicity and calls it number, which lines up with the “NaN is a number? nani???” joke.

    you don’t like it? consult the sorry excuse of thinking sand in the device you’re reading this on, because this is etched straight into it. every FPU capable of handling float32 and float64 numbers knows what NaN is and handles it the exact same way.

    this is one of the many things that sound unintuitive about programming but if you bother to understand the context you realise that if it wasn’t this way, it would be way worse. one of the most important skills in our field is to understand computers for what they are, rather than be puzzled that they aren’t what you thought they were, and it especially comes out in edge cases like this.

    • aksdb@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      1 hour ago

      To add to this: the state of being not a number is only relevant to a number. Everything that’s already not a number doesn’t need a specific value to represent this state. It’s actually quite logical.

      Apparently one of the few examples of JS not being weird.

    • Lena@gregtech.euOP
      link
      fedilink
      arrow-up
      14
      ·
      11 hours ago

      I love that talk.

      And yes, this post is low-effort, but so are most posts on here. Just a bunch of screenshots from various microblogging platforms reposted from Reddit.

  • ThunderComplex@lemmy.today
    link
    fedilink
    arrow-up
    56
    arrow-down
    1
    ·
    14 hours ago

    I think this, and the fact that NaN == NaN is false, make perfect sense.
    NaN is the result of mathematically undefined behavior. You’re not going to get a NaN outside of a number context, so tying it together in the Number scope is fine.

    • LillyPip@lemmy.ca
      link
      fedilink
      English
      arrow-up
      8
      arrow-down
      3
      ·
      11 hours ago

      Same reason NULL != NULL. It makes sense if you understand how these values work.

          • SpaceNoodle@lemmy.world
            link
            fedilink
            arrow-up
            13
            ·
            11 hours ago

            Ah, my brain was in C mode, where NULL is functionally 0. This is about the concept, which doesn’t apply equally to all languages.

            • LillyPip@lemmy.ca
              link
              fedilink
              English
              arrow-up
              6
              ·
              edit-2
              9 hours ago

              Yep. There are some languages where this applies, because it’s a mathematical concept. The point is it’s the same ‘no value’ concept, which isn’t shared by implemented the same way by all languages.

              C is strongly typed, and uses pointers, so NULL sort of intrinsically has a value in C.

              edit: my wording was a bit off

        • djmikeale@feddit.dk
          link
          fedilink
          arrow-up
          6
          ·
          11 hours ago

          You can kinda think of it as null meaning undefined. In this case, “undefined does not equal undefined” seems easier for me to wrap my head around

    • threeonefour@piefed.ca
      link
      fedilink
      English
      arrow-up
      12
      arrow-down
      15
      ·
      14 hours ago

      The result of mathematically undefined behaviour should be an error, but sure, go ahead and return Keleven. 1/0 = keleven fuck it.

      • bss03@infosec.pub
        link
        fedilink
        English
        arrow-up
        27
        ·
        13 hours ago

        NaN is one of the ways IEEE maths signals an erroneous calculation when the only outbound communication channel is the returned IEEE value. Reading the history and rationale of the floating-point standard will likely convince you this was and probably is a good compromise.

        Because IEEE values often have hardware acceleration that is a significant factor in performance, languages rarely (if ever) choose to map all IEEE error values to language-specific error reporting (e.g. a thrown exception or error-tracking algebraic data type).

        JS is hardly an outlier here.

        I do think it probably violates the principle of least surprise, but I don’t think I understand the scale of “momentum” change that would need to take place across society (industry, academia, etc.) to align it with naive expectations.

      • ThunderComplex@lemmy.today
        link
        fedilink
        arrow-up
        15
        arrow-down
        1
        ·
        14 hours ago

        NaN is a error and it’s your responsibility to handle it gracefully. No need to halt the entire program when you fuck up some maths.

          • lime!@feddit.nu
            link
            fedilink
            arrow-up
            12
            ·
            13 hours ago

            nan is a ieee754-defined error. what javascript calls errors these days (it tends to change a lot) has little to nothing to do with that. it’s on every developer to familiarise themself with ieee754, it’s one of the most important documents in the profession.

            while nan is an invalid floating-point number, it is a valid value for a float-typed field. making it into an error is like adding a bit labelled “crash” to every number in your program.

      • Lupie@sopuli.xyz
        link
        fedilink
        arrow-up
        10
        arrow-down
        5
        ·
        13 hours ago

        No, it should not be an error. If you’re making a calculator and your user enters 1/0, your program should not have the propensity to crash; the result should simply be NaN and you should choose how you display that result to your user.

          • bss03@infosec.pub
            link
            fedilink
            English
            arrow-up
            2
            ·
            6 hours ago

            fault v. error v. failure

            In common language they can be synonyms, but often aren’t in places (like computing) where there’s a useful difference. A page fault isn’t an error; a handled error doesn’t result in a failure; fault-tolerant systems fail less often than their components fault.

          • anewfox@lemmy.zip
            link
            fedilink
            arrow-up
            9
            arrow-down
            7
            ·
            12 hours ago

            fun fact: getting NaN from a numeric calculation is the error that you handle. if this wasn’t obvious, please don’t write code for anyone but yourself. hope this helps.

            • 🌞 Alexander Daychilde 🌞@lemmy.world
              link
              fedilink
              English
              arrow-up
              5
              ·
              9 hours ago

              if this wasn’t obvious,

              If this wasn’t obvious, be glad of the chance to learn.

              If we all stopped as soon as something simple wasn’t obvious, nobody would learn and nobody would do anything.

              What a terrible reply to someone. It cuts off curiosity and says “You are too stupid to do anything.”

              Yet I bet there was a time that even with that very specific thing, you didn’t think of it that way.

  • palordrolap@fedia.io
    link
    fedilink
    arrow-up
    17
    arrow-down
    1
    ·
    13 hours ago

    Infinity is also a number in JavaScript / IEEE number formats, but you’ll get a lot of grumbling from mathematicians with that sort of assertion.

  • bigmclargehuge@lemmy.zip
    link
    fedilink
    arrow-up
    15
    ·
    14 hours ago

    The way I think about it: number is a js type. A floating point double, in other languages.

    NaN is a state that a number type can be in, representing a situation where the outcome of the numeric operation cannot be determined.

    Anywho, also yea ….JavaScript is goofy