Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
On 01/11/2012 06:32 AM, Marijn wrote: It looks like there is still a residual bug though, that causes the stairs function when zoomed in to have non-vertical parts as you can see in the screenshot, though I can reproduce it also with the C locale, so looks like a genuine plot library bug this time. Although I am surprised at that too, since Neil looked at a similar screenshot by me earlier which also showed this problem. Forgot to push the fix for this Neil? Actually, I just haven't fixed it. I have yet to find the exact spot that flonums can sneak through without getting converted to rationals. Compared to other things, it has been rather low priority, as it seems to require zooming way into the plot of an inexact function. I've mostly been concerned with proper rendering when zoomed into the plots of exact functions. Still, it excites my inner analysis nerd to no end to make plot correct in the limit, even on functions with finite resolution. I have my own test case for it, and it will be fixed. Neil T _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
On Wed, Dec 28, 2011 at 13:18, Matthew Flatt wrote:
> Thanks for all the new info! I don't think that it's a bytcode problem.
> I start to wonder if it's in number parsing...
>
> On line 1102 of "src/racket/src/numstr.c", there's a call to STRTOD().
> Does it change anything if you wrap that call with calls to
> scheme_push_c_numeric_locale() and scheme_pop_c_numeric_locale(loc)?:
>
>{
> GC_CAN_IGNORE char *loc;
> loc = scheme_push_c_numeric_locale();
> d = STRTOD(ffl_buf, &ptr);
> scheme_pop_c_numeric_locale(loc);
>}
>
It works!
Though: I downloaded the nightly Unix sources, and did:
mkdir build
cd build
../configure
make
But no drracket executable appears (did I do something wrong?).
So I did:
gracket/gracket3m
and it took a full minute with 100% CPU to start (same for simply racket3m).
Then
Welcome to Racket v5.2.0.7.
This is a simple window for evaluating Racket expressions.
Quit now and run DrRacket to get a better window.
The current input port always returns eof.
> .3
0.3
>
In case this does not completely solve the issue, here is another
minimalistic interesting interaction in the buggy gracket:
Welcome to Racket v5.2.0.6.
This is a simple window for evaluating Racket expressions.
Quit now and run DrRacket to get a better window.
The current input port always returns eof.
> .3
0.0
> 3.3
3.0
> .3
0.3
So it seems that it's the fact that using a >= 1 floating point number make
the bug go away.
Anyway, I hope this does solves the issue!
Thank you very much,
Laurent
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
> > you're certainly on the right track. I tried starting drracket in this > way: > > LC_ALL="en_US.UTF-8" drracket & > Same here: LC_ALL="en_US.UTF-8" gracket Welcome to Racket v5.2.0.6. This is a simple window for evaluating Racket expressions. Quit now and run DrRacket to get a better window. The current input port always returns eof. > .3 0.3 > Great! *However*, this did not work with: LC_ALL="fr_FR.UTF-8" gracket Weird. Thank you, Laurent > and almost all symptoms were gone. > > Marijn > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.18 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk78JkIACgkQp/VmCx0OL2wedgCfSApHFEmJ6GojTYbTGg/fY4fz > LjoAnREzYAr9VYv/BZyAJEWYNunWNK9s > =1ZSi > -END PGP SIGNATURE- > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
I'm not alone! FWIW, I still have that problem in 5.2.0.6. And I confirm the ".1" minimalist test case. When running 'racket' from the command line, this does not occur however: laurent:~$ racket Welcome to Racket v5.2.0.6. Edit ~/.racketrc to modify inits. > .1 0.1 > But this still happens with gracket: Welcome to Racket v5.2.0.6. This is a simple window for evaluating Racket expressions. Quit now and run DrRacket to get a better window. The current input port always returns eof. > .1 0.0 > Probably irrelevant: Could the GPU be in the loop somehow? Good luck, Laurent On Tue, Dec 27, 2011 at 14:26, Marijn wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 24-12-11 16:23, Matthew Flatt wrote: > > At Wed, 14 Dec 2011 16:49:23 +0100, Marijn wrote: > >> #lang racket (* .1 pi) > >> > >> produces 0.0 reliably in a freshly started drracket even when > >> rerunning it, but: > >> > >> $ racket -e '(* .1 pi)' 0.3141592653589793 > >> > >> and the program: > >> > >> #lang racket pi (* .1 pi) > >> > >> on the first run (drracket again) produces: > >> > >> 3.141592653589793 0.0 > >> > >> while on subsequent runs it produces: > >> > >> 3.141592653589793 0.3141592653589793 > > > > Thanks --- this is very helpful! > > > > I'm still stumped, unfortunately. It looks the same as PR 12070, > > which we never figured out: > > > > > http://bugs.racket-lang.org/query/?debug=&database=default&cmd=view+audit-trail&cmd=view&pr=12070 > > Interesting!, > > > though it is a bit hard to read the Audit Trail because > everything is jumbled together. > > I reproduce that bug and step 7) and 8) can be replaced with a single > re-evaluate for me. > > It seems to indicate very clearly that the problem is in the floating > point start-up somehow and has nothing to do with `pi' or variable > references. > > Another possibility would be that multiplication (*) was at fault, but > my new smallest test-case rules that out: > > #lang racket > .1 > > => 0.0 > > And actually it works also directly in the REPL without running any > program: > > Welcome to DrRacket, version 5.2.0.7--2011-12-15(-/f) [3m]. > Language: racket; memory limit: 128 MB. > > .1 > 0.0 > > 1 > 1 > > .1 > 0.0 > > .2 > 0.0 > > .3 > 0.0 > > .4 > 0.0 > > .5 > 0.0 > > .6 > 0.0 > > .7 > 0.0 > > .8 > 0.0 > > .9 > 0.0 > > 1.0 > 1.0 > > .1 > 0.1 > > So should we look at the byte-code produced for this (how does one do > that and what is the expected code)? > Is there some way to invoke racket from the command line in such a way > that it behaves like the drracket initial repl? > How does one run the byte-code? > > What external suspects are there? I suppose gcc, but are there any > other? My CFLAGS are set to a very conservative AFAIK > CFLAGS="-march=native -ggdb -O2 -pipe", currently on version 4.5.3. > > Marijn > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.18 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk75x5IACgkQp/VmCx0OL2xZRACcC8dubYCSNXScyOG8wdJQxxN1 > xAgAnRVKv8YpTWODEKn2qEMMhcXHZLSk > =n+xT > -END PGP SIGNATURE- > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
At Thu, 29 Dec 2011 10:34:53 +0100, Marijn wrote: > Because the french locale uses comma (,) as the decimal separator like > my dutch one and unlike the english one which uses dot (.). So when > the locale-aware C number reading function gets to it and sees (.) it > fails to recognize is as a valid number character. Now that I've > thought about it more the weird behavior where it starts working > correctly after having seen a number bigger than 1.0 smells like an > unmatched push/pop locale pair. Might this then not also cause quite a > big locale stack to be allocated? Finally I wanted to ask if it was > possible that the automated tests are run with a non-english or random > locale. > > Matthew, I still wanted to remark that I find it strange that plain > racket did not exhibit the same locale-dependence. Do you have an > explanation for that? Does it read some >=1.0 float causing the locale > stack to become ``seeded'' (due to postulated unmatched push/pop). I am not clear on how the LC_NUMERIC locale gets set to anything other than "C". My best guess is that Gtk sets it, and that's why the problem happens only in DrRacket and why the problem showed up relatively recently. There's not really a stack of locales in Racket. Aside from the two clearly matched pairs of scheme_push_c_numeric_locale() and scheme_pop_c_numeric_locale(), Racket sets LC_CTYPE and LC_LOCALE on demand for functions like `bytes->string/locale' or `path->string'. It's possible that Racket and Gtk will interfere with each other and that Racket needs to manage the those settings more tightly (setting them and restoring them more like the LC_NUMERIC handling). _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29-12-11 09:55, Laurent wrote: >> >> you're certainly on the right track. I tried starting drracket in >> this way: >> >> LC_ALL="en_US.UTF-8" drracket & >> > > Same here: LC_ALL="en_US.UTF-8" gracket > > Welcome to Racket v5.2.0.6. This is a simple window for evaluating > Racket expressions. Quit now and run DrRacket to get a better > window. The current input port always returns eof. >> .3 > 0.3 >> > > Great! > > *However*, this did not work with: LC_ALL="fr_FR.UTF-8" gracket Because the french locale uses comma (,) as the decimal separator like my dutch one and unlike the english one which uses dot (.). So when the locale-aware C number reading function gets to it and sees (.) it fails to recognize is as a valid number character. Now that I've thought about it more the weird behavior where it starts working correctly after having seen a number bigger than 1.0 smells like an unmatched push/pop locale pair. Might this then not also cause quite a big locale stack to be allocated? Finally I wanted to ask if it was possible that the automated tests are run with a non-english or random locale. Matthew, I still wanted to remark that I find it strange that plain racket did not exhibit the same locale-dependence. Do you have an explanation for that? Does it read some >=1.0 float causing the locale stack to become ``seeded'' (due to postulated unmatched push/pop). BTW Perhaps coccinelle (http://coccinelle.lip6.fr/) can help identify (and automatically fix) the unmatched uses of the locale stack. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk78ND0ACgkQp/VmCx0OL2xrMwCgyRftnjOkQfIA3rpWKKwT7dKh KaAAoIDRW5XBM9d87FQ1CbCVUhpXPREm =Sw9a -END PGP SIGNATURE- _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28-12-11 17:08, Neil Toronto wrote: > On 12/28/2011 05:18 AM, Matthew Flatt wrote: >> Thanks for all the new info! I don't think that it's a bytcode >> problem. I start to wonder if it's in number parsing... >> >> On line 1102 of "src/racket/src/numstr.c", there's a call to >> STRTOD(). Does it change anything if you wrap that call with >> calls to scheme_push_c_numeric_locale() and >> scheme_pop_c_numeric_locale(loc)?: ... > > Locales? Then maybe I wasn't crazy for thinking the bug might > discriminate against people whose first language isn't English? > Laurent speaks French and I think Marijn speaks Dutch. Locales are a beautiful thing, but they also cause many many weird issues... but it is ever so annoying to see a numeric date and have to wonder which is months and which is days (for exmaple in Thunderbird), so I configured my locale to be a wonderful mix of nl_NL and en_US... > (Beautiful country, BTW, Marijn. I was at Avifauna for a > conference.) Thanks! > I had an email about this ready, but then I tried switching > DrRacket's language to French and Dutch to see if I could duplicate > it. I couldn't, so I deleted the email. I think to switch the locale you would have to do some more work, like set an environment variable. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk78KNcACgkQp/VmCx0OL2yOJgCfVmeUIb7/KyJFfkRXGNoNXb8p fksAnRFYz2ez3HpQgEN3AXxK7iFCZ5vP =Nrgv -END PGP SIGNATURE- _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28-12-11 13:18, Matthew Flatt wrote:
> Thanks for all the new info! I don't think that it's a bytcode
> problem. I start to wonder if it's in number parsing...
>
> On line 1102 of "src/racket/src/numstr.c", there's a call to
> STRTOD(). Does it change anything if you wrap that call with calls
> to scheme_push_c_numeric_locale() and
> scheme_pop_c_numeric_locale(loc)?:
>
> { GC_CAN_IGNORE char *loc; loc = scheme_push_c_numeric_locale(); d
> = STRTOD(ffl_buf, &ptr); scheme_pop_c_numeric_locale(loc); }
Hi Matthew,
you're certainly on the right track. I tried starting drracket in this
way:
LC_ALL="en_US.UTF-8" drracket &
and almost all symptoms were gone.
Marijn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk78JkIACgkQp/VmCx0OL2wedgCfSApHFEmJ6GojTYbTGg/fY4fz
LjoAnREzYAr9VYv/BZyAJEWYNunWNK9s
=1ZSi
-END PGP SIGNATURE-
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
On 12/28/2011 05:18 AM, Matthew Flatt wrote: Thanks for all the new info! I don't think that it's a bytcode problem. I start to wonder if it's in number parsing... On line 1102 of "src/racket/src/numstr.c", there's a call to STRTOD(). Does it change anything if you wrap that call with calls to scheme_push_c_numeric_locale() and scheme_pop_c_numeric_locale(loc)?: ... Locales? Then maybe I wasn't crazy for thinking the bug might discriminate against people whose first language isn't English? Laurent speaks French and I think Marijn speaks Dutch. (Beautiful country, BTW, Marijn. I was at Avifauna for a conference.) I had an email about this ready, but then I tried switching DrRacket's language to French and Dutch to see if I could duplicate it. I couldn't, so I deleted the email. Neil T _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
Thanks for all the new info! I don't think that it's a bytcode problem.
I start to wonder if it's in number parsing...
On line 1102 of "src/racket/src/numstr.c", there's a call to STRTOD().
Does it change anything if you wrap that call with calls to
scheme_push_c_numeric_locale() and scheme_pop_c_numeric_locale(loc)?:
{
GC_CAN_IGNORE char *loc;
loc = scheme_push_c_numeric_locale();
d = STRTOD(ffl_buf, &ptr);
scheme_pop_c_numeric_locale(loc);
}
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24-12-11 16:23, Matthew Flatt wrote: > At Wed, 14 Dec 2011 16:49:23 +0100, Marijn wrote: >> #lang racket (* .1 pi) >> >> produces 0.0 reliably in a freshly started drracket even when >> rerunning it, but: >> >> $ racket -e '(* .1 pi)' 0.3141592653589793 >> >> and the program: >> >> #lang racket pi (* .1 pi) >> >> on the first run (drracket again) produces: >> >> 3.141592653589793 0.0 >> >> while on subsequent runs it produces: >> >> 3.141592653589793 0.3141592653589793 > > Thanks --- this is very helpful! > > I'm still stumped, unfortunately. It looks the same as PR 12070, > which we never figured out: > > http://bugs.racket-lang.org/query/?debug=&database=default&cmd=view+audit-trail&cmd=view&pr=12070 Interesting!, > though it is a bit hard to read the Audit Trail because everything is jumbled together. I reproduce that bug and step 7) and 8) can be replaced with a single re-evaluate for me. It seems to indicate very clearly that the problem is in the floating point start-up somehow and has nothing to do with `pi' or variable references. Another possibility would be that multiplication (*) was at fault, but my new smallest test-case rules that out: #lang racket .1 => 0.0 And actually it works also directly in the REPL without running any program: Welcome to DrRacket, version 5.2.0.7--2011-12-15(-/f) [3m]. Language: racket; memory limit: 128 MB. > .1 0.0 > 1 1 > .1 0.0 > .2 0.0 > .3 0.0 > .4 0.0 > .5 0.0 > .6 0.0 > .7 0.0 > .8 0.0 > .9 0.0 > 1.0 1.0 > .1 0.1 So should we look at the byte-code produced for this (how does one do that and what is the expected code)? Is there some way to invoke racket from the command line in such a way that it behaves like the drracket initial repl? How does one run the byte-code? What external suspects are there? I suppose gcc, but are there any other? My CFLAGS are set to a very conservative AFAIK CFLAGS="-march=native -ggdb -O2 -pipe", currently on version 4.5.3. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk75x5IACgkQp/VmCx0OL2xZRACcC8dubYCSNXScyOG8wdJQxxN1 xAgAnRVKv8YpTWODEKn2qEMMhcXHZLSk =n+xT -END PGP SIGNATURE- _ Racket Developers list: http://lists.racket-lang.org/dev
