Dividing int by a float freezes browser #5

Closed
jmtame opened this Issue Dec 8, 2011 · 3 comments

Comments

Projects
None yet
3 participants
@jmtame

jmtame commented Dec 8, 2011

I'm not able to replicate this on repl.it right now since the editor isn't loading, so it's possible this is an isolated problem, however I wanted to report it anyway: when I try to divide an integer by a float, it freezes the editor and the browser tab. I've had other users report this issue when trying it on www.trybloc.com.

As an example, if you type 3/3, that's fine, but 3/3.0 will cause the freeze.

Edit: In some cases, if you type 12/3.5, it works, but when trying 12/3.0 it won't work. So it appears to only be some floats causing the freeze.

@amasad

This comment has been minimized.

Show comment Hide comment
@amasad

amasad Dec 8, 2011

Member

Looks like its not a dividing issue. But a general float issue.
Floats with no significant decimal places or that have 4-6 decimal places would hang the browser.
Examples:

1.1111
9.9999
0.12345
0.123456```

As strange as it may sound 7 significant decimal places would work while 8 would produce NaN. anymore than that would just work fine.

```> 1.1234567
=> 1.1234567
 > 1.12345678
=> NaN
 > 1.123456789
=> 1.123456789
 > 1.1234567891
=> 1.1234567891
 > 1.12345678911
=> 1.12345678911
 > 1.123456789112
=> 1.123456789112

I believe its not a setjmp -> exception transformation issue. But its an emscripten number precision issue.

BTW @jmtame what do you mean by editor not loading?

Member

amasad commented Dec 8, 2011

Looks like its not a dividing issue. But a general float issue.
Floats with no significant decimal places or that have 4-6 decimal places would hang the browser.
Examples:

1.1111
9.9999
0.12345
0.123456```

As strange as it may sound 7 significant decimal places would work while 8 would produce NaN. anymore than that would just work fine.

```> 1.1234567
=> 1.1234567
 > 1.12345678
=> NaN
 > 1.123456789
=> 1.123456789
 > 1.1234567891
=> 1.1234567891
 > 1.12345678911
=> 1.12345678911
 > 1.123456789112
=> 1.123456789112

I believe its not a setjmp -> exception transformation issue. But its an emscripten number precision issue.

BTW @jmtame what do you mean by editor not loading?

@max99x

This comment has been minimized.

Show comment Hide comment
@max99x

max99x Jan 28, 2012

Member

Tracked this down to ruby_strtod(), which fiddles with the bits of the floating point number that it's creating, something that you can't do in Emscripten unless you use typed arrays. I could try to dig into the (huge and super-messy) function itself and try to save something, but given that all it does is provide a tiny precision improvement, the easier fix was just to disable it and use the system strtod() (which is implemented in JS in Emscripten). This makes things a tiny bit less precise, but sure as hell beats half the floating point numbers being outright broken.

Member

max99x commented Jan 28, 2012

Tracked this down to ruby_strtod(), which fiddles with the bits of the floating point number that it's creating, something that you can't do in Emscripten unless you use typed arrays. I could try to dig into the (huge and super-messy) function itself and try to save something, but given that all it does is provide a tiny precision improvement, the easier fix was just to disable it and use the system strtod() (which is implemented in JS in Emscripten). This makes things a tiny bit less precise, but sure as hell beats half the floating point numbers being outright broken.

@max99x max99x closed this Jan 28, 2012

@amasad

This comment has been minimized.

Show comment Hide comment
@amasad

amasad Feb 1, 2012

Member

Pushed, verified on production. (clear cache).

Member

amasad commented Feb 1, 2012

Pushed, verified on production. (clear cache).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment