Re: [racket-dev] Release for v5.2 has begun
Let me know if you want me to break anything else. My mom always hated it when I was a kid, but it seems to be useful on pre-releases. On Sun, Oct 9, 2011 at 7:46 PM, Matthew Flatt wrote: > Fixed. > > Some unsafe primitives were marked internally as "functional", but this > annotation was used with two different interpretations: sometimes as > "non-mutating", sometimes as "always produces the same result". The > `unsafe-vector-ref' primitive was marked as "functional" with the > former intent, but the compiler could use the latter interpretation to > move it past an `unsafe-vector-set!'. The solution, of course, is to > have two distinct annotations. > > At Sun, 9 Oct 2011 15:02:13 -0600, Doug Williams wrote: > > I reloaded the older version of Racket on my Windows 7 computer and the > > radix-2 FFTs run fine there. I also tested both versions on my Macbook > Pro > > (32 bit) and got the same behavior - correct results (plots) on 5.1.2 and > > bad radix-2 results (plots) on 5.1.900.1. > > code for the mixed-radix and radix-2. So, it isn't limited to Windows 7 > or > > 64-bit. > > > > Doug > > > > On Sun, Oct 9, 2011 at 1:44 PM, Doug Williams > > wrote: > > > > > I downloaded the latest pre-release version (5.1.900.1) to update the > > > science collection to use the new plot collection. The good news is > that > > > that went very smoothly. The bad news is that some of my FFT routines > seem > > > to be getting incorrect numeric results - at least the plots are very > bad. > > > But, since all of the other plots seem fine, I don't see why these > would be > > > any different. > > > > > > So, I suspect that something has changed that affects the numeric > > > calculations. It is just the radix-2 FFTs that are having the problem. > They > > > do some low-level bit fiddling to do the in-place butterfly addressing > for > > > the FFTs - using things like unsafe-fxlshift (which just looks > unfriendly) - > > > so, I suspect something there. Are the any recent changes that would > affect > > > these kinds of fixed-point operations? > > > > > > I've run the code under a previous version of Racket on a 64-bit Linux > > > (Scientific Linux 6.0) computer and a 32-bit Windows XP computer and > get > > > correct results. So, I don't think it is simply a 32/64 bit problem - > unless > > > it is limited to 64-bit Windows. > > > > > > Sorry that was kind of rambling and non-specific, but I was wondering > where > > > to start looking at the problem or what would help someone else look > into > > > it. > > > > > > Doug > > > > > > > > > > > > On Fri, Oct 7, 2011 at 10:19 PM, Ryan Culpepper > wrote: > > > > > >> The release process for v5.2 has begun: the `release' branch was > > >> created for any work that is left and is now bumped to v5.1.90. You > > >> can go on using the `master' branch as usual, it is now bumped to > > >> v5.2.0.1 (to avoid having two different trees with the same version). > > >> > > >> If you have any bug-fixes and changes that need to go in the release > > >> then make sure to specify that in the commit message or mail me the > > >> commit SHA1s. You can `git checkout release' to try it out directly > if > > >> needed -- but do not try to push commits on it (the server will forbid > > >> it). > > >> > > >> Please make sure that code that you're responsible for is as stable > > >> as possible, and let me know if there is any new work that should > > >> not be included in this release. > > >> > > >> >> NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT <<< > > >> > > >> The time between the `release' branch creation and the actual > > >> release is for fixing new errors that prevent proper functioning of > > >> major components and that show up during the preparation for a > > >> release. You can also finalize piece of work that is not yet > > >> complete, but please avoid merging new features. > > >> > > >> Note that nightly builds will go on as usual (as v5.2.0.1), and > > >> pre-release builds will be available shortly at > > >> > > >> http://pre.racket-lang.org/release/ > > >> > > >> Please tell me if you think that this release is significant enough > > >> that it should be announced on the users list for wider testing. > > >> -- > > >> Ryan Culpepper > > >> _ > > >> For list-related administrative tasks: > > >> http://lists.racket-lang.org/listinfo/dev > > >> > > > > > > > > _ > > For list-related administrative tasks: > > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.2 has begun
Fixed. Some unsafe primitives were marked internally as "functional", but this annotation was used with two different interpretations: sometimes as "non-mutating", sometimes as "always produces the same result". The `unsafe-vector-ref' primitive was marked as "functional" with the former intent, but the compiler could use the latter interpretation to move it past an `unsafe-vector-set!'. The solution, of course, is to have two distinct annotations. At Sun, 9 Oct 2011 15:02:13 -0600, Doug Williams wrote: > I reloaded the older version of Racket on my Windows 7 computer and the > radix-2 FFTs run fine there. I also tested both versions on my Macbook Pro > (32 bit) and got the same behavior - correct results (plots) on 5.1.2 and > bad radix-2 results (plots) on 5.1.900.1. > code for the mixed-radix and radix-2. So, it isn't limited to Windows 7 or > 64-bit. > > Doug > > On Sun, Oct 9, 2011 at 1:44 PM, Doug Williams > wrote: > > > I downloaded the latest pre-release version (5.1.900.1) to update the > > science collection to use the new plot collection. The good news is that > > that went very smoothly. The bad news is that some of my FFT routines seem > > to be getting incorrect numeric results - at least the plots are very bad. > > But, since all of the other plots seem fine, I don't see why these would be > > any different. > > > > So, I suspect that something has changed that affects the numeric > > calculations. It is just the radix-2 FFTs that are having the problem. They > > do some low-level bit fiddling to do the in-place butterfly addressing for > > the FFTs - using things like unsafe-fxlshift (which just looks unfriendly) - > > so, I suspect something there. Are the any recent changes that would affect > > these kinds of fixed-point operations? > > > > I've run the code under a previous version of Racket on a 64-bit Linux > > (Scientific Linux 6.0) computer and a 32-bit Windows XP computer and get > > correct results. So, I don't think it is simply a 32/64 bit problem - unless > > it is limited to 64-bit Windows. > > > > Sorry that was kind of rambling and non-specific, but I was wondering where > > to start looking at the problem or what would help someone else look into > > it. > > > > Doug > > > > > > > > On Fri, Oct 7, 2011 at 10:19 PM, Ryan Culpepper wrote: > > > >> The release process for v5.2 has begun: the `release' branch was > >> created for any work that is left and is now bumped to v5.1.90. You > >> can go on using the `master' branch as usual, it is now bumped to > >> v5.2.0.1 (to avoid having two different trees with the same version). > >> > >> If you have any bug-fixes and changes that need to go in the release > >> then make sure to specify that in the commit message or mail me the > >> commit SHA1s. You can `git checkout release' to try it out directly if > >> needed -- but do not try to push commits on it (the server will forbid > >> it). > >> > >> Please make sure that code that you're responsible for is as stable > >> as possible, and let me know if there is any new work that should > >> not be included in this release. > >> > >> >> NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT <<< > >> > >> The time between the `release' branch creation and the actual > >> release is for fixing new errors that prevent proper functioning of > >> major components and that show up during the preparation for a > >> release. You can also finalize piece of work that is not yet > >> complete, but please avoid merging new features. > >> > >> Note that nightly builds will go on as usual (as v5.2.0.1), and > >> pre-release builds will be available shortly at > >> > >> http://pre.racket-lang.org/release/ > >> > >> Please tell me if you think that this release is significant enough > >> that it should be announced on the users list for wider testing. > >> -- > >> Ryan Culpepper > >> _ > >> For list-related administrative tasks: > >> http://lists.racket-lang.org/listinfo/dev > >> > > > > > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] struct + match not interacting via a macro
On Sun, Oct 9, 2011 at 8:31 PM, Shriram Krishnamurthi wrote: > What exactly does the struct form of match (in the ASL language) use > to identify the structure? The following works fine: I'm not sure if ASL's match is the same as the one in `racket/match', but almost certainly it's using the static struct info bound by to `foo' by `define-struct'. You can see the documentation about that here: http://docs.racket-lang.org/reference/structinfo.html -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] struct + match not interacting via a macro
What exactly does the struct form of match (in the ASL language) use to identify the structure? The following works fine: (define-struct foo (a b)) (match (make-foo 1 2) [(struct foo (x y)) (+ x y)]) But I have a macro over define-struct for which I get the error match: foo does not refer to a structure definition in: foo (pointing at the "foo" in "struct foo (x y)"). My macro uses build-struct-names to synthesize the names of the constructor, selectors, etc. It binds all these names (including the "struct:foo" name); for good measure I'm also binding "foo". The coloring in the Macro Stepper isn't instructive (to me, anyway -- there is only one step of reduction before the error). Here is the sample output (... elides irrelevant detail): (define-struct: foo ([a : Number$] [b : Number$])) --> (begin (define-values (foo struct:foo make-foo foo? foo-a set-foo-a! foo-b set-foo-b!) (let () (begin (define-struct foo (a b) #:transparent #:mutable) (let ([make-foo (lambda (a b) ...)] [set-foo-a! (lambda (struct-inst new-val) ...)] [set-foo-b! (lambda (struct-inst new-val) ...)]) (values foo struct:foo make-foo foo? foo-a set-foo-a! foo-b set-foo-b!)) Any ideas? Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.2 has begun
I reloaded the older version of Racket on my Windows 7 computer and the radix-2 FFTs run fine there. I also tested both versions on my Macbook Pro (32 bit) and got the same behavior - correct results (plots) on 5.1.2 and bad radix-2 results (plots) on 5.1.900.1. code for the mixed-radix and radix-2. So, it isn't limited to Windows 7 or 64-bit. Doug On Sun, Oct 9, 2011 at 1:44 PM, Doug Williams wrote: > I downloaded the latest pre-release version (5.1.900.1) to update the > science collection to use the new plot collection. The good news is that > that went very smoothly. The bad news is that some of my FFT routines seem > to be getting incorrect numeric results - at least the plots are very bad. > But, since all of the other plots seem fine, I don't see why these would be > any different. > > So, I suspect that something has changed that affects the numeric > calculations. It is just the radix-2 FFTs that are having the problem. They > do some low-level bit fiddling to do the in-place butterfly addressing for > the FFTs - using things like unsafe-fxlshift (which just looks unfriendly) - > so, I suspect something there. Are the any recent changes that would affect > these kinds of fixed-point operations? > > I've run the code under a previous version of Racket on a 64-bit Linux > (Scientific Linux 6.0) computer and a 32-bit Windows XP computer and get > correct results. So, I don't think it is simply a 32/64 bit problem - unless > it is limited to 64-bit Windows. > > Sorry that was kind of rambling and non-specific, but I was wondering where > to start looking at the problem or what would help someone else look into > it. > > Doug > > > > On Fri, Oct 7, 2011 at 10:19 PM, Ryan Culpepper wrote: > >> The release process for v5.2 has begun: the `release' branch was >> created for any work that is left and is now bumped to v5.1.90. You >> can go on using the `master' branch as usual, it is now bumped to >> v5.2.0.1 (to avoid having two different trees with the same version). >> >> If you have any bug-fixes and changes that need to go in the release >> then make sure to specify that in the commit message or mail me the >> commit SHA1s. You can `git checkout release' to try it out directly if >> needed -- but do not try to push commits on it (the server will forbid >> it). >> >> Please make sure that code that you're responsible for is as stable >> as possible, and let me know if there is any new work that should >> not be included in this release. >> >> >> NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT <<< >> >> The time between the `release' branch creation and the actual >> release is for fixing new errors that prevent proper functioning of >> major components and that show up during the preparation for a >> release. You can also finalize piece of work that is not yet >> complete, but please avoid merging new features. >> >> Note that nightly builds will go on as usual (as v5.2.0.1), and >> pre-release builds will be available shortly at >> >> http://pre.racket-lang.org/release/ >> >> Please tell me if you think that this release is significant enough >> that it should be announced on the users list for wider testing. >> -- >> Ryan Culpepper >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev >> > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New plot library pushed
None of the contracts for any of the plot routines were a problem. I was talking about contracts on my own functions. For example, if I have a function f(x) with a (>/c 0.0) contract, I still have to use #:x-min 0.001 (or something like it) instead of #:x-min 0.0 to avoid the contract error. But, I would say that is the expected behavior. Yes, the porting page was helpful. And really, the port was not hard at all. The only thing that required much thought was getting the rectangles to work for histograms. I incorrectly homed in on the word histogram. It might be nice to provide a plain histogram renderer. But, it really wasn't hard after I found rectangles. And thanks for writing the discrete-histogram, that was very useful. On Sun, Oct 9, 2011 at 2:27 PM, Neil Toronto wrote: > That was quick! > > > On 10/09/2011 01:10 PM, Doug Williams wrote: > >> I ported all of the science collection graphics to use the new plot >> package. It was relatively painless. Most of the effort was actually in >> improving my graphics using some of the new options - like adding labels >> for legends. Also, there are many places with the old plot package where >> I had to fudge things like #:x-min and #x-max - like #:x-min 0.001 >> instead of #:x-min 0.0 - because the graphics package itself was very >> unforgiving of it's internal numeric errors. Neil's seems to be much >> more robust and forgiving. >> > > I'll take credit for half of that. Internally, it treats any NaNs and INFs > output from user functions as "holes" and handles them in a > graphics-primitive-specific way. (E.g. polygons with at least one "hole" > don't get drawn, lines get split.) > > The other half of the credit goes to Racket for giving me exact rationals > to use for plot bounds and other internal quantities. It's been really nice > to not have to worry about floating-point error. > > > [Obviously I still need to do it in some >> cases where there would be contract violations on functions being >> plotted.] >> > > Are the contract violations because some of PLoT's contracts are a little > stricter? (I'm thinking specifically of 'points'.) > > > Neil, thanks for the good work. >> > > You're very welcome. > > Did you find the "Porting" page helpful? > > Neil T > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New plot library pushed
That was quick! On 10/09/2011 01:10 PM, Doug Williams wrote: I ported all of the science collection graphics to use the new plot package. It was relatively painless. Most of the effort was actually in improving my graphics using some of the new options - like adding labels for legends. Also, there are many places with the old plot package where I had to fudge things like #:x-min and #x-max - like #:x-min 0.001 instead of #:x-min 0.0 - because the graphics package itself was very unforgiving of it's internal numeric errors. Neil's seems to be much more robust and forgiving. I'll take credit for half of that. Internally, it treats any NaNs and INFs output from user functions as "holes" and handles them in a graphics-primitive-specific way. (E.g. polygons with at least one "hole" don't get drawn, lines get split.) The other half of the credit goes to Racket for giving me exact rationals to use for plot bounds and other internal quantities. It's been really nice to not have to worry about floating-point error. [Obviously I still need to do it in some cases where there would be contract violations on functions being plotted.] Are the contract violations because some of PLoT's contracts are a little stricter? (I'm thinking specifically of 'points'.) Neil, thanks for the good work. You're very welcome. Did you find the "Porting" page helpful? Neil T _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.2 has begun
I downloaded the latest pre-release version (5.1.900.1) to update the science collection to use the new plot collection. The good news is that that went very smoothly. The bad news is that some of my FFT routines seem to be getting incorrect numeric results - at least the plots are very bad. But, since all of the other plots seem fine, I don't see why these would be any different. So, I suspect that something has changed that affects the numeric calculations. It is just the radix-2 FFTs that are having the problem. They do some low-level bit fiddling to do the in-place butterfly addressing for the FFTs - using things like unsafe-fxlshift (which just looks unfriendly) - so, I suspect something there. Are the any recent changes that would affect these kinds of fixed-point operations? I've run the code under a previous version of Racket on a 64-bit Linux (Scientific Linux 6.0) computer and a 32-bit Windows XP computer and get correct results. So, I don't think it is simply a 32/64 bit problem - unless it is limited to 64-bit Windows. Sorry that was kind of rambling and non-specific, but I was wondering where to start looking at the problem or what would help someone else look into it. Doug On Fri, Oct 7, 2011 at 10:19 PM, Ryan Culpepper wrote: > The release process for v5.2 has begun: the `release' branch was > created for any work that is left and is now bumped to v5.1.90. You > can go on using the `master' branch as usual, it is now bumped to > v5.2.0.1 (to avoid having two different trees with the same version). > > If you have any bug-fixes and changes that need to go in the release > then make sure to specify that in the commit message or mail me the > commit SHA1s. You can `git checkout release' to try it out directly if > needed -- but do not try to push commits on it (the server will forbid > it). > > Please make sure that code that you're responsible for is as stable > as possible, and let me know if there is any new work that should > not be included in this release. > > >> NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT <<< > > The time between the `release' branch creation and the actual > release is for fixing new errors that prevent proper functioning of > major components and that show up during the preparation for a > release. You can also finalize piece of work that is not yet > complete, but please avoid merging new features. > > Note that nightly builds will go on as usual (as v5.2.0.1), and > pre-release builds will be available shortly at > > http://pre.racket-lang.org/release/ > > Please tell me if you think that this release is significant enough > that it should be announced on the users list for wider testing. > -- > Ryan Culpepper > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
