0 is NaN?

Monkey Forums/Monkey Bug Reports/0 is NaN?

Midimaster(Posted 2013) [#1]
Is this a feature or a bug?

Both Strings return different values:



Seen on V71...


ziggy(Posted 2013) [#2]
Then, what's "Test"? Are you comparing different stances of a Test object, so they will never be the same.--> EDIT: Nevermind, this is not the issue.

In the ther hand, to get the UTF character index, you may use this instead:
Local b$="S"
		WorksNot.Text=b[0]
		Works.Text="S"[0]

Int(b)will fail and is target dependant if "b" does not contain a string representation of a number. On JavaScript, it may continue executing and assign a "n/a" value, wich is always false.

Si your Int(String) is not getting UTF (ascii) value of the character, is trying to parse the string representation of a number. So, Int("123") returns a numeric 123. Int("S") will fail depending on target, will return "0" or a n/a value or any other thing, or even crash at runtime. If you need a cross platform numeric parser, you will be safer by implementing your own.

No bug here. n/a is "not a number" wich is what I would expect from an "S". "S" is not a number.


Midimaster(Posted 2013) [#3]
you missunderstood what happened!

This did not happen on different platforms, but on the same HTML5 target. If...
Local b$="S"
WorksNot.Text=Int(b)
...returns "NaN", why does...
Works.Text=Int("S")
...not return also "NaN" but "0"? I do not search for a algo, which returns the asc or utf index. I expected to get twice a "NaN"!



"...No bug here. n/a is "not a number" wich is what I would expect from an "S". "S" is not a number..."

That's the bug I found... "S" return "0" and "NaN".

Print WorksNot.Text prints "NaN", while Print Works.Text prints "0"

I exchanged the code above to a complete runnable sample So you can see too!


muddy_shoes(Posted 2013) [#4]
Int("S") isn't being evaluated at runtime. There's some sort of optimisation being attempted to evaluate the constant string at compile time. Considering the variation across targets in string->int parsing the difference between the Monkey compile time evaluation and the target runtime evaluation is inevitable.