Thought I was going to get ninja'd.
No, you can store NaN in a variable in javascript, it just can't be compared with another NaN value (or itself).
again. just use that to your advantage. its the only thing in snap that is not = to itself
infinity is not a number, it's a "size"
no. its a number
I mean, there is no special code in the implementation of Snap! to treat NaN differently from anything else. Whatever we do is whatever the same underlying JS code we use for any other value does.
Sorry, @sonic123cdmania...
When you see "β" in a mathematical context (it's pronounced "infinity" but you'll pretty much never see that spelled out), it never stands alone; you'll see it in a context such as $$\lim_{n \rarr \infin}f(n)$$ ("the limit of f of n as n tends toward infinity"), which really means "the limit of $$f(n)$$ as $$n$$ gets bigger and bigger." There is no actual endpoint of that getting-bigger, no infinite value, no β.
But there are infinite numbers. They have names like $$\aleph_0$$ (pronounced "aleph null") or $$1+\omega$$ ("one plus omega"). There are lots of them, infinitely many, in fact. They're numbers, 100% valid, specific numbers. Because "infinity" has such a confusing history, though, we bend over backward to call them "transfinite numbers" rather than "infinite numbers." When you say "transfinite" it's clear what you mean.
Yeah, Ok.
Yeah, those were what I was talking about.
Yes, NaN is treated the same in snap as in js, I have a feeling there might be some code in the variable block that converts NaN to 0. I come this conclusion, because when I was looking at @avi_shor's is NaN block, they used (item (1) of (this [inputs])) rather than the input (variable) itself.
There should be nothing different between that and this
But apparently there is
That's because the one that uses the variable, converts the value to 0, whereas the one that uses (this [inputs]) doesn't change the value at all.
I have a feeling there may be some code in the variable block that converts NaN to 0, but not lists. This may also explain why you can see NaN in a variable watcher, but get 0 from the variable block.
Set it to NaN⬠(NaN but with the Unicode symbol u+206c in front)
i know i found that when i was creating the block
My guess is that each call to THIS INPUTS generates a fresh list, so the pointers are different, whereas the two instances of the INPUT orange blob are the same pointer.
another thing i found is that you can find letter (X) of NaN but you cant get length of it
no. they are the same. the code for snap does not allowed for NaN to be used for anything, this makes sense considering NaN mean "Not a Number" im assuming that in an effort to prevent the code from destroying itself it just sets its value to 0
That's quite an assumption! :~P Programs do not "destroy themselves" by referring to a NaN value. All that happens is maybe you don't get the result you were expecting.
I say again, Snap! does not take any special pains about NaN. We don't deliberately replace it with a zero value. Jens suggests that there are lots of places where the JS code says things like
bar = (foo || 0)
to catch undefined or nil values, and maybe NaN is falsy.
you can always ringify and evaluate later -- when calling it, it will return NaN.
so maybe javascript does that
sort of
You can store the string just fine. You can't store the Floating point data, though.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.