363

Not a Number (jemmy.jeena.net)

submitted 7 months ago by jeena@jemmy.jeena.net to c/programmer_humor@programming.dev

54 comments fedilink hide all child comments

Good price.

you are viewing a single comment's thread
view the rest of the comments

[-] nickwitha_k@lemmy.sdf.org 21 points 7 months ago

0*(NaN)... So does that mean the price IS a number?

[-] rikudou@lemmings.world 26 points 7 months ago

Isn't any math operation involving NaNs also a NaN? At least that's my gut feeling.

[-] NegativeInf@lemmy.world 15 points 7 months ago

Based on my frequent exploding and vanishing gradients, that would be a yes.

[-] match@pawb.social 6 points 7 months ago

Thanks, relevant username!

[-] nickwitha_k@lemmy.sdf.org 4 points 7 months ago

Good point.

[-] RecluseRamble@lemmy.dbzer0.com 10 points 7 months ago

I suppressed most of my former js knowledge but I guess it's a string now.

[-] mindbleach@sh.itjust.works 1 points 7 months ago

Javascript carcinization.

[-] tiredofsametab@kbin.run 8 points 7 months ago

In JS, it's just NaN if my browser's console is to be believed. I suspected it would probably be {object} for no clear reason

[-] nickwitha_k@lemmy.sdf.org 7 points 7 months ago

for no clear reason

JS That's the reason. The language has an awful type system.

[-] victorz@lemmy.world 2 points 7 months ago

I think its type system is "okay", I mean inherently dynamic typing is pretty error-prone. But its type coercion algorithms are bonkers. Also that whole "NaN ≠ NaN" business...

[-] nickwitha_k@lemmy.sdf.org 3 points 7 months ago

Also that whole "NaN ≠ NaN" business...

See that's one of the parts that is actually almost in line with other languages. In Go, for example, nil ≠ nil because nil is, by definition, undefined. You can't say whether one thing that you know nothing about is at all like something else that you know nothing about. It really should raise an exception at the attempt to compare NaN though.

[-] victorz@lemmy.world 1 points 7 months ago

If nil ≠ nil, how do you compare a variable to the literal?

[-] nickwitha_k@lemmy.sdf.org 1 points 7 months ago

You'd first check for nil values, then compare like normal. Extra step, yes, but it keeps you from hitting NPEs through that route.

[-] victorz@lemmy.world 1 points 7 months ago

You'd first check for nil values

What does this mean, if not the same as

then compare like normal

[-] nickwitha_k@lemmy.sdf.org 1 points 7 months ago

IIRC, a nil value can be checked against a literal successfully but not against another nil value. Say you want to check for equality of two vars that could be nil. You just need an extra if statement to ensure that you are not trying to compare nil and nil or nil and a non-nil value (that'll give you a type error or NPE):

var a *string
var b *string

...
if a != nil && b != nil {
  if a == b {
    fmt.Println("Party!")
  } else {
    fmt.Println("Also Party!")
}

[-] victorz@lemmy.world 1 points 7 months ago* (last edited 7 months ago)

What I mean is that in JS you can't do NaN != NaN, not even variable != NaN. So you're not saying it's the same in Go, since you can do a != nil?

[-] nickwitha_k@lemmy.sdf.org 1 points 7 months ago* (last edited 7 months ago)

Kinda. nil is a weird value in Go, not quite the same as null or None in JS and Python, respectively. A nil value may or may not be typed and it may or may not be comparable to similar or different types. There is logical consistency to where these scenarios can be hit but it is pretty convoluted and much safer, with fewer footguns to check for nil values before comparison.

I'm other words, in Go (nil == nil) || (nil != nil), depending on the underlaying types. One can always check if a variable has a nil value but may not be able to compare variables if one or more have a nil value. Therefore, it is best to first check for nil values to protect against errors that failure to execute comparisons might cause (anything from incorrect outcome to panic).

ETA: Here's some examples

// this is always possible for a variable that may have a nil value. 
a != nil || a == nil

a = nil
b = nil
// This may or may not be valid, depending on the underlying types.
a != b || a == b

// Better practice for safety is to check for nil first
if a != nil && b != nil {
    if a == b {
        fmt.Println("equal")
    } else {
        fmt.Println("not equal")
    }
} else {
    fmt.Println("a and/or b is nil and may not be comparable")
}

[-] victorz@lemmy.world 2 points 7 months ago

Thoroughly confusing lol. I think I need to check the spec in order to grasp this. I feel like this has more to do with the typing system rather than nil itself, maybe. I'll see.

But yeah, this is nothing like null or undefined in JS, but more similar to NaN.

Thank you for trying to explain!

[-] nickwitha_k@lemmy.sdf.org 2 points 7 months ago

Yeah... It's weird but I find it useful that it is, in a weird way. Treating it as an uncertainty means that one MUST explicitly check all pointers for nil as part of normal practice. This avoids NPEs.