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:

Strict
Import mojo


Class Game Extends App

	Field Works:Test=New Test
	Field WorksNot:Test=New Test

	Method OnCreate%()
		SetUpdateRate 30
		Local b$="S"
		WorksNot.Text=Int(b)
		Works.Text=Int("S")
		Print Works.Text + " is " + WorksNot.Text
		EndApp()
		Return 0
	End	

	Method OnUpdate%()
		Return 0
	End	

	Method OnRender%()
		Return 0
	End	
End


Function Main%()
	New Game
	Return 0
End


Class Test
	Field Text$
End

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.