Unclear INT functionality (documentation issue)

Problem Description

The INT functionality when used to convert a string to a value is unclear and to the unwary user (ie me) can lead to unusual results. This is not a bug but a mismatch in the manual documentation vs the actuality. It's perfectly fine but perhaps unexpected. The INT function operates as follows

int("33") = 33

int("33xx") = 33

init("xx33") = 0

This is similar and probably identical to the javascript implementation of INT, but that implementation is not universal agreed nor is it universally used in C2 where the numeric value of a string containing non-numeric text characters often returns a zero.

Attach a Capx

-unneeded, it's a documentation issue.

Description of Capx

Steps to Reproduce Bug

Observed Result

Expected Result

Affected Browsers

Operating System and Service Pack

Construct 2 Version ID

178

(imo) Just because "33xx" simply works isn't a reason to use such a cast with non numerical numbers... Use regular expressions to extract the number first:

(\d+)[/code:1wgkhukr] and then cast it to int

IndieKiwi

Actually having "33xx" return 33 is a problem, I'd prefer a null or zero response rather than that. However I know why javascript does it that way. So I won't disagree as you're likely right about best practice but as Construct is for non-coders, regex expressions are unlikely the best solution.

My primary comment was that the functionality was not clearly described and there is an inconsistency in C2 about how strings get cast as numbers.

R

Would this definition be better?

http://en.wikipedia.org/wiki/Integer

newt

long time no troll \o/

Otherwise int is the exact translation of the javascript parseInt function

in chrome console:

>  parseInt("33",10);
<· 33

var cast = parseInt(input,10);
input === ""+cast;[/code:3vaeyj07]would be too weak a check, since it wouldn't take into acount the case where input = "0033"  which would be a valid integer representation in my opinion.
And a regex check like might be too much for just that.
(Also, C2 doesn't have any error handling mecanisms...)

I would think if anything, that the manual should state to not use int that way (aka with non number strings), since it is outside of what it is meant to do, and so cannot be guaranted to work consistently that way forever.

I've updated the documentation. The way it works is consistent with every int conversion function I've seen so far (including in C): it parses digits until it doesn't understand something, then stops. If it doesn't understand the first character, it rejects it as probably not a number string. I think it's useful to do it this way around: parsing "33%" allows you to extract 33 even though there's an extra character on the end, and parsing "abcdef33" fails since it does not look like a number and most likely is not (and is an error).