[racket-dev] TR's optimizer eventually going to unbox structs?
Is TR's optimizer eventually going to unbox structs in the same way it unboxes rectangular flonums? I have a design choice right now: how to represent probabilities. Floats are good because of their speed, but because of floating-point limitations, *four different representations* are typically used. (For the curious: p, 1-p, log(p), and log(1-p).) I'd like to make functions that accept any one of these representations, denoted by this type: (define-type Probability (U probability 1-probability log-probability log-1-probability)) The types are simply struct types that tag Float. Of course, manually boxing flonums ruins any chance of the compiler emitting code that keeps the flonums unboxed. If TR's optimizer unboxed structs, though, everything could be speedy. FWIW, by eventually, I mean within the next n years, where n is a smallish number. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] TR's optimizer eventually going to unbox structs?
But don't you need the 'tag' from the struct to distinguish .4 in p from .4 in 1-p? They may be the same number but they denote distinct ideas. -- Matthias ' On Aug 18, 2012, at 2:40 PM, Neil Toronto wrote: Is TR's optimizer eventually going to unbox structs in the same way it unboxes rectangular flonums? I have a design choice right now: how to represent probabilities. Floats are good because of their speed, but because of floating-point limitations, *four different representations* are typically used. (For the curious: p, 1-p, log(p), and log(1-p).) I'd like to make functions that accept any one of these representations, denoted by this type: (define-type Probability (U probability 1-probability log-probability log-1-probability)) The types are simply struct types that tag Float. Of course, manually boxing flonums ruins any chance of the compiler emitting code that keeps the flonums unboxed. If TR's optimizer unboxed structs, though, everything could be speedy. FWIW, by eventually, I mean within the next n years, where n is a smallish number. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] TR's optimizer eventually going to unbox structs?
One could, concievably, still do that without boxing/unblocking by passing wide enough arguments. And it does seem like TR could help with that, but IIUC the untyped portion of the compiler needs significant work to support that before TR's knowledge of the program would help (But doing a better job with structs is, iiuc, a long standing something could be much better here type of thing.) On Saturday, August 18, 2012, Matthias Felleisen wrote: But don't you need the 'tag' from the struct to distinguish .4 in p from .4 in 1-p? They may be the same number but they denote distinct ideas. -- Matthias ' On Aug 18, 2012, at 2:40 PM, Neil Toronto wrote: Is TR's optimizer eventually going to unbox structs in the same way it unboxes rectangular flonums? I have a design choice right now: how to represent probabilities. Floats are good because of their speed, but because of floating-point limitations, *four different representations* are typically used. (For the curious: p, 1-p, log(p), and log(1-p).) I'd like to make functions that accept any one of these representations, denoted by this type: (define-type Probability (U probability 1-probability log-probability log-1-probability)) The types are simply struct types that tag Float. Of course, manually boxing flonums ruins any chance of the compiler emitting code that keeps the flonums unboxed. If TR's optimizer unboxed structs, though, everything could be speedy. FWIW, by eventually, I mean within the next n years, where n is a smallish number. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] TR's optimizer eventually going to unbox structs?
Vincent got TR to 'split' complex numbers, if that's what you mean by 'wide enough' arguments, and he did so w/o changing R. So perhaps there is a way to get the computation on floats and the tag for their meaning. On Aug 18, 2012, at 4:13 PM, Robby Findler wrote: One could, concievably, still do that without boxing/unblocking by passing wide enough arguments. And it does seem like TR could help with that, but IIUC the untyped portion of the compiler needs significant work to support that before TR's knowledge of the program would help (But doing a better job with structs is, iiuc, a long standing something could be much better here type of thing.) On Saturday, August 18, 2012, Matthias Felleisen wrote: But don't you need the 'tag' from the struct to distinguish .4 in p from .4 in 1-p? They may be the same number but they denote distinct ideas. -- Matthias ' On Aug 18, 2012, at 2:40 PM, Neil Toronto wrote: Is TR's optimizer eventually going to unbox structs in the same way it unboxes rectangular flonums? I have a design choice right now: how to represent probabilities. Floats are good because of their speed, but because of floating-point limitations, *four different representations* are typically used. (For the curious: p, 1-p, log(p), and log(1-p).) I'd like to make functions that accept any one of these representations, denoted by this type: (define-type Probability (U probability 1-probability log-probability log-1-probability)) The types are simply struct types that tag Float. Of course, manually boxing flonums ruins any chance of the compiler emitting code that keeps the flonums unboxed. If TR's optimizer unboxed structs, though, everything could be speedy. FWIW, by eventually, I mean within the next n years, where n is a smallish number. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] TR's optimizer eventually going to unbox structs?
Oh right! A generalized version of that strategy might work for Neil's program too. On Saturday, August 18, 2012, Matthias Felleisen wrote: Vincent got TR to 'split' complex numbers, if that's what you mean by 'wide enough' arguments, and he did so w/o changing R. So perhaps there is a way to get the computation on floats and the tag for their meaning. On Aug 18, 2012, at 4:13 PM, Robby Findler wrote: One could, concievably, still do that without boxing/unblocking by passing wide enough arguments. And it does seem like TR could help with that, but IIUC the untyped portion of the compiler needs significant work to support that before TR's knowledge of the program would help (But doing a better job with structs is, iiuc, a long standing something could be much better here type of thing.) On Saturday, August 18, 2012, Matthias Felleisen wrote: But don't you need the 'tag' from the struct to distinguish .4 in p from .4 in 1-p? They may be the same number but they denote distinct ideas. -- Matthias ' On Aug 18, 2012, at 2:40 PM, Neil Toronto wrote: Is TR's optimizer eventually going to unbox structs in the same way it unboxes rectangular flonums? I have a design choice right now: how to represent probabilities. Floats are good because of their speed, but because of floating-point limitations, *four different representations* are typically used. (For the curious: p, 1-p, log(p), and log(1-p).) I'd like to make functions that accept any one of these representations, denoted by this type: (define-type Probability (U probability 1-probability log-probability log-1-probability)) The types are simply struct types that tag Float. Of course, manually boxing flonums ruins any chance of the compiler emitting code that keeps the flonums unboxed. If TR's optimizer unboxed structs, though, everything could be speedy. FWIW, by eventually, I mean within the next n years, where n is a smallish number. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] potentially renaming /usr/bin/planet to /usr/bin/planet-racket in Debian
I've pushed a change to the current git version of Racket that removes the 'planet' binary from plt/bin. (Note that 'raco planet' does all the same things and avoids the conflict mentioned below.) Robby On Sun, Jul 29, 2012 at 2:46 PM, David Bremner brem...@debian.org wrote: Hi All; We're currently trying to figure out the right way to handle a name conflict in Debian between racket and an rss aggregator named planet-venus. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680685 I don't use the command /usr/bin/planet myself, so I was wondering if anybody could explain the likely disruption caused by (hypothetically) renaming it. In particular is it likely to be somether where people are using it from scripts or cron jobs, or would making a shell alias (alias planet planet-racket) suffice to avoid retraining fingers? Thanks David _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Keyword Constructors for Structs
I've updated define-struct/derived to allow creating a keyword argument constructor. https://github.com/wtetzner/racket/compare/v5.3...struct-keyword-args?w=1 It would be good to get some feedback on: - whether or not the option's design is good - if I did anything stupid in the implementation - if there are any cases I didn't cover that will cause things to break All of the collects build fine with the changes, so I haven't (yet) found any cases where it breaks existing code. There is one thing I don't know how to do, but would like to have. When the keyword constructor is the only constructor, it would be nice if the default print for transparent structs would print with keywords. It works like this: If you give a name that's the same as the positional constructor, only the keyword constructor will be defined: (struct person (name age height weight) #:transparent #:keyword-constructor person) (person #:name Bob #:height 6 #:age 45 #:weight 200) (person Bob 45 6 200) By default, all keyword arguments are required. You can set a default value for all fields, or specific defaults for individual fields: (struct person (name age height weight) #:transparent #:keyword-constructor [person #:default #f]) (person #:name Bob #:height 6) (person Bob #f 6 #f) (struct person (name age height weight) #:transparent #:keyword-constructor [person #:default #f (weight 200)]) (person #:name Bob #:height 6) (person Bob #f 6 200) (struct person (name age height weight) #:transparent #:keyword-constructor [person (weight 200)]) (person #:name Bob #:height 6 #:age 45) (person Bob 45 6 200) If the constructor name is different from the positional constructor name, you get both constructors: (struct person (name age height weight) #:transparent #:keyword-constructor make-person) (person Bob 45 6 200) (person Bob 45 6 200) (make-person #:name Bob #:age 45 #:height 6 #:weight 200) (person Bob 45 6 200) (struct person (name age height weight) #:transparent #:constructor-name make-person #:keyword-constructor person) (make-person Bob 45 6 200) (person Bob 45 6 200) (person #:name Bob #:age 45 #:height 6 #:weight 200) (person Bob 45 6 200) -Walter _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] potentially renaming /usr/bin/planet to /usr/bin/planet-racket in Debian
On Sat, Aug 18, 2012 at 08:28:45PM -0500, Robby Findler wrote: I've pushed a change to the current git version of Racket that removes the 'planet' binary from plt/bin. (Note that 'raco planet' does all the same things and avoids the conflict mentioned below.) Thanks. I made a similar change to Debian's package for our 5.3 upload to resolve the bug on our end. I also added a note to our NEWS file mentioning the future removal upstream and raco planet as the replacement. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org _ Racket Developers list: http://lists.racket-lang.org/dev
