Small bug fix for int and float

5 views
Skip to first unread message

Brad Miller

unread,
Jun 23, 2011, 3:43:14 PM6/23/11
to sku...@googlegroups.com
I have pushed a small fix to my branch for the following problem.

In skulpt:  int("28balloons") --> 28
In Python  int("28balloons") --> ValueError

Same thing with float.  so I've implemented a fix in which for bases <= 10 I check to be sure the argument to int is numeric.  Much more validation would need to be done to ensure that only the proper characters for a particular base are allowed, but this is a step in the right direction.

Its very strange to me that javascripts parseInt function lets you pass in just about anything.

Brad

-- 
Brad Miller
Sent with Sparrow

Philip Peterson

unread,
Jun 23, 2011, 5:44:13 PM6/23/11
to sku...@googlegroups.com
I filed a bug report about this a while ago; parseInt just looks at a string, and gets all the digits until it sees something that doesn't look like a number.

Kees Bos

unread,
Jun 24, 2011, 1:33:10 AM6/24/11
to Skulpt
> Sent with Sparrow (http://www.sparrowmailapp.com)

I don't know how it's done in skulpt, but in pyjamas we do a regex
match
on the string.

if (v.match($radix_regex[radix]) === null) {
v = NaN;
}

var $radix_regex = [
/^$/i, // 0
/^$/i, // 1
/^ *-? *[01]+ *$/i, // 2
/^ *-? *[0-2]+ *$/i, // 3
/^ *-? *[0-3]+ *$/i, // 4
/^ *-? *[0-4]+ *$/i, // 5
/^ *-? *[0-5]+ *$/i, // 6
/^ *-? *[0-6]+ *$/i, // 7
/^ *-? *[0-7]+ *$/i, // 8
/^ *-? *[0-8]+ *$/i, // 9
/^ *-? *[0-9]+ *$/i, // 10
/^ *-? *[0-9a]+ *$/i, // 11
/^ *-? *[0-9ab]+ *$/i, // 12
/^ *-? *[0-9a-c]+ *$/i, // 13
/^ *-? *[0-9a-d]+ *$/i, // 14
/^ *-? *[0-9a-e]+ *$/i, // 15
/^ *-? *[0-9a-f]+ *$/i, // 16
/^ *-? *[0-9a-g]+ *$/i, // 17
/^ *-? *[0-9a-h]+ *$/i, // 18
/^ *-? *[0-9a-i]+ *$/i, // 19
/^ *-? *[0-9a-j]+ *$/i, // 20
/^ *-? *[0-9a-k]+ *$/i, // 21
/^ *-? *[0-9a-l]+ *$/i, // 22
/^ *-? *[0-9a-m]+ *$/i, // 23
/^ *-? *[0-9a-n]+ *$/i, // 24
/^ *-? *[0-9a-o]+ *$/i, // 25
/^ *-? *[0-9a-p]+ *$/i, // 26
/^ *-? *[0-9a-q]+ *$/i, // 27
/^ *-? *[0-9a-r]+ *$/i, // 28
/^ *-? *[0-9a-s]+ *$/i, // 29
/^ *-? *[0-9a-t]+ *$/i, // 30
/^ *-? *[0-9a-u]+ *$/i, // 31
/^ *-? *[0-9a-v]+ *$/i, // 32
/^ *-? *[0-9a-w]+ *$/i, // 33
/^ *-? *[0-9a-x]+ *$/i, // 34
/^ *-? *[0-9a-y]+ *$/i, // 35
/^ *-? *[0-9a-z]+ *$/i // 36
];



Philip Peterson

unread,
Jun 24, 2011, 12:38:39 PM6/24/11
to sku...@googlegroups.com
That sounds very inefficient. Did y'all compare that with a top-down parser for speed?

Kees Bos

unread,
Jun 24, 2011, 12:54:52 PM6/24/11
to Skulpt


On Jun 24, 6:38 pm, Philip Peterson <ppeter...@ufl.edu> wrote:
> That sounds very inefficient. Did y'all compare that with a top-down parser
> for speed?
>
Nope. We didn't (as far a I know). But do you expect a top-down parser
to be faster then a single regex (based on the radix)?

Philip Peterson

unread,
Jun 24, 2011, 2:43:03 PM6/24/11
to sku...@googlegroups.com
I actually had been confusing this problem with the problem of parsing float values, so a top-down parser would probably be overkill. It's worth testing, although.

Kees Bos

unread,
Jun 24, 2011, 1:26:31 AM6/24/11
to sku...@googlegroups.com

I don't know how it's done in skulpt, but in pyjamas we do a regex match

Philip Peterson

unread,
Jun 28, 2011, 12:12:31 AM6/28/11
to sku...@googlegroups.com
Kees: looks like you sent an empty message?

BTW, Pyjamas's method is slightly flawed, as the spaces should in fact be \ses, since int("\t\r\n 3") == 3

Kees Bos

unread,
Jun 28, 2011, 1:33:21 AM6/28/11
to Skulpt
On Jun 28, 6:12 am, Philip Peterson <ppeter...@ufl.edu> wrote:
> Kees: looks like you sent an empty message?

Nah. That was the first message I sent. I've sent that with my normal
email client, but then the message didn't show up in the list an I
remembered that for some obscure reason it can take days on the skulpt
list before they appear. So, I copied the message to the groups web
interface.

>
> BTW, Pyjamas's method is slightly flawed, as the spaces should in fact be
> \ses, since int("\t\r\n 3") == 3
>
Thanks.

I've dismissed the thought of trying a top-down parser. Just a matter
priorities. It could be faster, but for now I (personally) don't need
a faster int string parser and I need my time for other issues. There
are a lot of issues :-)

BTW. For floats we use Number(v), which doesn't allow you to postfix
the value with weird characters. Python is more permissive in float()
than javascript in Number() (e.g. the space in '- 1.0' is not allowed
in Number()).


Philip Peterson

unread,
Jun 28, 2011, 10:40:57 PM6/28/11
to cornel...@gmail.com, sku...@googlegroups.com
So after creating a mockup parser, I can say that it's definitely about 80% slower than the regex. Test is here.

On Tue, Jun 28, 2011 at 3:23 AM, Philip Peterson <ppet...@ufl.edu> wrote:
Interesting. If you're not already aware, by the way, float('inf') gives you Infinity in python.

Kees Bos

unread,
Jun 29, 2011, 3:12:05 AM6/29/11
to Skulpt


On Jun 29, 4:40 am, Philip Peterson <ppeter...@ufl.edu> wrote:
> So after creating a mockup parser, I can say that it's definitely about 80%
> slower than the regex. Test is
> here<http://jsperf.com/python-int-validation-methods>
> .
>
Very nice.

Not surprising, but the 80% tells me that it's not worth pursuing
faster interpreted code.
Reply all
Reply to author
Forward
0 new messages