[racket-dev] Short-circuiting comprehensions
I would like the for/... comprehension macros to have #:while and #:until clauses similar to the #:when and #:unless clauses. I often find I want to short-circuit the sequence at some point, but there is no elegant way to do it. I could probably write sequence-while and sequence-until, but I don't want to move this condition into the sequence any more than I want to write sequence-filter instead of #:when or #:unless. Has this been brought up before? I can't recall. Does anyone else run into the same issue? Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Short-circuiting comprehensions
I think this is a good idea. The technique to implement it is embedded in `for/vector' (to handle a vector length), and I can generalize that and move it into `for...'. Also, I think the names `#:while' and `#:until' are too close to `#:when' and `#:unless'. I suggest `#:break-when' and `#:break-unless'. Compare: (for*/list ([j 2] [i 10] #:when (i . . 5)) i) '(0 1 2 3 4 0 1 2 3 4) (for*/list ([j 2] [i 10] #:break-unless (i . . 5)) i) '(0 1 2 3 4) I imagine that `#:break-when' and `#:break-unless' are allowed among the clauses much like `#:when' and `#:unless', but also allowed at the end of the body. Is that what you had in mind? At Fri, 14 Sep 2012 10:09:52 -0400, Carl Eastlund wrote: I would like the for/... comprehension macros to have #:while and #:until clauses similar to the #:when and #:unless clauses. I often find I want to short-circuit the sequence at some point, but there is no elegant way to do it. I could probably write sequence-while and sequence-until, but I don't want to move this condition into the sequence any more than I want to write sequence-filter instead of #:when or #:unless. Has this been brought up before? I can't recall. Does anyone else run into the same issue? Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Short-circuiting comprehensions
I agree that #:while and #:until are easily confused with #:when and #:unless. I slightly prefer #:stop- to #:break- as a prefix here, it seems a more natural word. I like the idea of allowing these clauses at the end of the body to give a notion of stopping after the current iteration. I had been wondering how to do that, and hadn't come up with anything nearly so simple. On Fri, Sep 14, 2012 at 11:40 AM, Matthew Flatt mfl...@cs.utah.edu wrote: I think this is a good idea. The technique to implement it is embedded in `for/vector' (to handle a vector length), and I can generalize that and move it into `for...'. Also, I think the names `#:while' and `#:until' are too close to `#:when' and `#:unless'. I suggest `#:break-when' and `#:break-unless'. Compare: (for*/list ([j 2] [i 10] #:when (i . . 5)) i) '(0 1 2 3 4 0 1 2 3 4) (for*/list ([j 2] [i 10] #:break-unless (i . . 5)) i) '(0 1 2 3 4) I imagine that `#:break-when' and `#:break-unless' are allowed among the clauses much like `#:when' and `#:unless', but also allowed at the end of the body. Is that what you had in mind? At Fri, 14 Sep 2012 10:09:52 -0400, Carl Eastlund wrote: I would like the for/... comprehension macros to have #:while and #:until clauses similar to the #:when and #:unless clauses. I often find I want to short-circuit the sequence at some point, but there is no elegant way to do it. I could probably write sequence-while and sequence-until, but I don't want to move this condition into the sequence any more than I want to write sequence-filter instead of #:when or #:unless. Has this been brought up before? I can't recall. Does anyone else run into the same issue? Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Short-circuiting comprehensions
+1 I've been using let/ec for this same functionality, and it's made me sad. -Ian - Original Message - From: Carl Eastlund c...@ccs.neu.edu To: Matthew Flatt mfl...@cs.utah.edu Cc: PLT Developers d...@lists.racket-lang.org Sent: Friday, September 14, 2012 11:49:20 AM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] Short-circuiting comprehensions I agree that #:while and #:until are easily confused with #:when and #:unless. I slightly prefer #:stop- to #:break- as a prefix here, it seems a more natural word. I like the idea of allowing these clauses at the end of the body to give a notion of stopping after the current iteration. I had been wondering how to do that, and hadn't come up with anything nearly so simple. On Fri, Sep 14, 2012 at 11:40 AM, Matthew Flatt mfl...@cs.utah.edu wrote: I think this is a good idea. The technique to implement it is embedded in `for/vector' (to handle a vector length), and I can generalize that and move it into `for...'. Also, I think the names `#:while' and `#:until' are too close to `#:when' and `#:unless'. I suggest `#:break-when' and `#:break-unless'. Compare: (for*/list ([j 2] [i 10] #:when (i . . 5)) i) '(0 1 2 3 4 0 1 2 3 4) (for*/list ([j 2] [i 10] #:break-unless (i . . 5)) i) '(0 1 2 3 4) I imagine that `#:break-when' and `#:break-unless' are allowed among the clauses much like `#:when' and `#:unless', but also allowed at the end of the body. Is that what you had in mind? At Fri, 14 Sep 2012 10:09:52 -0400, Carl Eastlund wrote: I would like the for/... comprehension macros to have #:while and #:until clauses similar to the #:when and #:unless clauses. I often find I want to short-circuit the sequence at some point, but there is no elegant way to do it. I could probably write sequence-while and sequence-until, but I don't want to move this condition into the sequence any more than I want to write sequence-filter instead of #:when or #:unless. Has this been brought up before? I can't recall. Does anyone else run into the same issue? Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] What are single flonums good for?
On Sep 12, 2012, at 1:03 PM, Jay McCarthy wrote: On Wed, Sep 12, 2012 at 8:31 AM, Neil Toronto neil.toro...@gmail.com wrote: Compatibility with C code? Why not have the FFI convert them? Save space? I can see that. It won't help much if they're sent to math library functions, though. Those will convert them to flonums and usually box the converted values. I think these are big deals with respect to libraries that you deliver large float matrices to where you want to efficiently store a big f32vector rather than an f64vector. Examples of this include OpenGL where vector coordinates, colors, etc are typically floats and not doubles. Jay's concern is the same as mine; there are situations (getting rarer) where a huge c-style array of f32s is the only way to interact with a library. For instance, in the extremely popular JACK library (Golly, I wish it worked on windows…), all audio data is represented as 32-bit floating point values (from their web page). I haven't followed the conversation closely enough to understand the ramifications of the proposed change, though; my guess is that the ffi can still address such arrays, it's just that computing with these values will require coercion. I could be okay with that; based on my understanding of the IEEE floating-point spec, such a translation could be pretty fast; 32bit - 64bit looks like it would just be adding zeros, and 32bit to 64bit would require checking for exponent overflow; either way, this sounds like something that might be done on-chip by modern processors, and in fact might *already* be taking place in floating point 32-bit operations. (Anyone know whether Intel chips internally represent 32-bit floats as 64-bit ones?) John smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] What are single flonums good for?
As far as I can tell, if this pollutes TR programs in any interesting way, then it would be a cause for concern. Robby On Fri, Sep 14, 2012 at 12:21 PM, John Clements cleme...@brinckerhoff.org wrote: On Sep 12, 2012, at 1:03 PM, Jay McCarthy wrote: On Wed, Sep 12, 2012 at 8:31 AM, Neil Toronto neil.toro...@gmail.com wrote: Compatibility with C code? Why not have the FFI convert them? Save space? I can see that. It won't help much if they're sent to math library functions, though. Those will convert them to flonums and usually box the converted values. I think these are big deals with respect to libraries that you deliver large float matrices to where you want to efficiently store a big f32vector rather than an f64vector. Examples of this include OpenGL where vector coordinates, colors, etc are typically floats and not doubles. Jay's concern is the same as mine; there are situations (getting rarer) where a huge c-style array of f32s is the only way to interact with a library. For instance, in the extremely popular JACK library (Golly, I wish it worked on windows…), all audio data is represented as 32-bit floating point values (from their web page). I haven't followed the conversation closely enough to understand the ramifications of the proposed change, though; my guess is that the ffi can still address such arrays, it's just that computing with these values will require coercion. I could be okay with that; based on my understanding of the IEEE floating-point spec, such a translation could be pretty fast; 32bit - 64bit looks like it would just be adding zeros, and 32bit to 64bit would require checking for exponent overflow; either way, this sounds like something that might be done on-chip by modern processors, and in fact might *already* be taking place in floating point 32-bit operations. (Anyone know whether Intel chips internally represent 32-bit floats as 64-bit ones?) John _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] What are single flonums good for?
Two hours ago, John Clements wrote: I haven't followed the conversation closely enough to understand the ramifications of the proposed change, though; my guess is that the ffi can still address such arrays, it's just that computing with these values will require coercion. I could be okay with that; based on my understanding of the IEEE floating-point spec, such a translation could be pretty fast; 32bit - 64bit looks like it would just be adding zeros, and 32bit to 64bit would require checking for exponent overflow; either way, this sounds like something that might be done on-chip by modern processors, and in fact might *already* be taking place in floating point 32-bit operations. (Anyone know whether Intel chips internally represent 32-bit floats as 64-bit ones?) The main cost is that such a back-and-forth translation will require allocation. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Short-circuiting comprehensions
5 hours ago, Carl Eastlund wrote: Has this been brought up before? I can't recall. Does anyone else run into the same issue? (I think that I brought this up when the comprehensions were first discussed, pointing at the similar tool I have in Swindle which makes implementing them very easy.) Four hours ago, Matthew Flatt wrote: Also, I think the names `#:while' and `#:until' are too close to `#:when' and `#:unless'. I suggest `#:break-when' and `#:break-unless'. Compare: (for*/list ([j 2] [i 10] #:when (i . . 5)) i) '(0 1 2 3 4 0 1 2 3 4) (for*/list ([j 2] [i 10] #:break-unless (i . . 5)) i) '(0 1 2 3 4) I imagine that `#:break-when' and `#:break-unless' are allowed among the clauses much like `#:when' and `#:unless', but also allowed at the end of the body. Is that what you had in mind? Sorry for the bike-shedding, but to me that `#:break-unless' is even harder to read than `#:until'. Possible explanation: break unless makes me parse two words and figure out how they combine, and while is something that I know without doing so. Another point to consider in favor of `#:while' and `#:until' is that they're extremely common names, so they're unlikely to be *that* problematic. (I intentionally left the typo in the first sentence as a demonstration of how it's confusing to read...) A different point is that maybe there should also be a `while' and `until' looping constructs in the language? (Whatever they're called.) Every once in a while (ahem) I want that when I write: (let loop () (when (more-work-to-do) (work!))) And it looks like this: (for (#:while (more-work-to-do)) (work!)) would not work in the same way that (for () (work!)) doesn't loop forever(?). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Short-circuiting comprehensions
My $0.02: I find #:while and #:when to be too close, and #:until and #:unless even closer. Robby On Fri, Sep 14, 2012 at 2:30 PM, Eli Barzilay e...@barzilay.org wrote: 5 hours ago, Carl Eastlund wrote: Has this been brought up before? I can't recall. Does anyone else run into the same issue? (I think that I brought this up when the comprehensions were first discussed, pointing at the similar tool I have in Swindle which makes implementing them very easy.) Four hours ago, Matthew Flatt wrote: Also, I think the names `#:while' and `#:until' are too close to `#:when' and `#:unless'. I suggest `#:break-when' and `#:break-unless'. Compare: (for*/list ([j 2] [i 10] #:when (i . . 5)) i) '(0 1 2 3 4 0 1 2 3 4) (for*/list ([j 2] [i 10] #:break-unless (i . . 5)) i) '(0 1 2 3 4) I imagine that `#:break-when' and `#:break-unless' are allowed among the clauses much like `#:when' and `#:unless', but also allowed at the end of the body. Is that what you had in mind? Sorry for the bike-shedding, but to me that `#:break-unless' is even harder to read than `#:until'. Possible explanation: break unless makes me parse two words and figure out how they combine, and while is something that I know without doing so. Another point to consider in favor of `#:while' and `#:until' is that they're extremely common names, so they're unlikely to be *that* problematic. (I intentionally left the typo in the first sentence as a demonstration of how it's confusing to read...) A different point is that maybe there should also be a `while' and `until' looping constructs in the language? (Whatever they're called.) Every once in a while (ahem) I want that when I write: (let loop () (when (more-work-to-do) (work!))) And it looks like this: (for (#:while (more-work-to-do)) (work!)) would not work in the same way that (for () (work!)) doesn't loop forever(?). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Short-circuiting comprehensions
At Fri, 14 Sep 2012 15:30:22 -0400, Eli Barzilay wrote: Four hours ago, Matthew Flatt wrote: Also, I think the names `#:while' and `#:until' are too close to `#:when' and `#:unless'. I suggest `#:break-when' and `#:break-unless'. Compare: (for*/list ([j 2] [i 10] #:when (i . . 5)) i) '(0 1 2 3 4 0 1 2 3 4) (for*/list ([j 2] [i 10] #:break-unless (i . . 5)) i) '(0 1 2 3 4) I imagine that `#:break-when' and `#:break-unless' are allowed among the clauses much like `#:when' and `#:unless', but also allowed at the end of the body. Is that what you had in mind? Sorry for the bike-shedding, but to me that `#:break-unless' is even harder to read than `#:until'. Possible explanation: break unless makes me parse two words and figure out how they combine, and while is something that I know without doing so. After trying out various options, I agree that `break-when' is too many words. I'm currently trying just `break' and dropping `break-unless', and that feels better. At Fri, 14 Sep 2012 11:49:20 -0400, Carl Eastlund wrote: I agree that #:while and #:until are easily confused with #:when and #:unless. I slightly prefer #:stop- to #:break- as a prefix here, it seems a more natural word. I like break because it goes with for, it avoids potential confusion with stop in `stop-after' and `stop-before', and it is more clearly different from final (which is used below). I like the idea of allowing these clauses at the end of the body to give a notion of stopping after the current iteration. It turns out that allowing `#:break' at the very end of the body causes problems with scope and composition. Imagine trying to implement `for/set' by wrapping its body in an expansion to `for/fold'. Maybe you can look from the end of the body and skip back over `#:break' clauses, but now imagine that the last form before `break' expands to a combination of a definition and an expression, and the `#:break' clause wants to refer to the identifier that is bound in the expansion. We could probably make all that work with `local-expand' and internal-definition contexts, but that gets complicated. Requiring an expression at the end of a `for' body --- while allowing `#:break' clauses otherwise interspersed in the body --- avoids composition and scope problems. Macros still have to do a little work to juggle `#:break' clauses, but a `split-for-body' helper function is straightforward to use. Meanwhile, to support breaking after the current element, I'm trying out `#:final'. A `#:final' clause is like `#:break', except that it ends the loop after the next run of the body. (The two kinds of clauses closely related to `stop-before' and `stop-after'.) (for/list ([i 10]) #:break (= i 2) i) '(0 1) (for/list ([i 10]) #:final (= i 2) i) '(0 1 2) (for ([book '(Guide Story Reference)] #:break (equal? book Story) [chapter '(Intro Details Conclusion)]) (printf ~a ~a\n book chapter)) Guide Intro Guide Details Guide Conclusion (for* ([book '(Guide Story Reference)] [chapter '(Intro Details Conclusion)]) #:break (and (equal? book Story) (equal? chapter Conclusion)) (printf ~a ~a\n book chapter)) Guide Intro Guide Details Guide Conclusion Story Intro Story Details (for* ([book '(Guide Story Reference)] [chapter '(Intro Details Conclusion)]) #:final (and (equal? book Story) (equal? chapter Conclusion)) (printf ~a ~a\n book chapter)) Guide Intro Guide Details Guide Conclusion Story Intro Story Details Story Conclusion (for ([book '(Guide Story Reference)] #:final (equal? book Story) [chapter '(Intro Details Conclusion)]) (printf ~a ~a\n book chapter)) Guide Intro Guide Details Guide Conclusion Story Intro _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Short-circuiting comprehensions
On Sep 14, 2012, at 1:14 PM, Robby Findler wrote: My $0.02: I find #:while and #:when to be too close, and #:until and #:unless even closer. More bike-shedding: I agree. In response to eli: I find the difficulty of reading break-when to be an adequate cost to pay to highlight the difference between just skip this one and stop the loop completely. Just to add my own tint to the can of paint, I would personally drop #:break-unless completely, and just make do with #:break-when, which I find quite a bit more readable. (To be fair, I'd also be very happy getting rid of unless altogether; I nearly always find (when (not …) …) more readable. John Robby On Fri, Sep 14, 2012 at 2:30 PM, Eli Barzilay e...@barzilay.org wrote: 5 hours ago, Carl Eastlund wrote: Has this been brought up before? I can't recall. Does anyone else run into the same issue? (I think that I brought this up when the comprehensions were first discussed, pointing at the similar tool I have in Swindle which makes implementing them very easy.) Four hours ago, Matthew Flatt wrote: Also, I think the names `#:while' and `#:until' are too close to `#:when' and `#:unless'. I suggest `#:break-when' and `#:break-unless'. Compare: (for*/list ([j 2] [i 10] #:when (i . . 5)) i) '(0 1 2 3 4 0 1 2 3 4) (for*/list ([j 2] [i 10] #:break-unless (i . . 5)) i) '(0 1 2 3 4) I imagine that `#:break-when' and `#:break-unless' are allowed among the clauses much like `#:when' and `#:unless', but also allowed at the end of the body. Is that what you had in mind? Sorry for the bike-shedding, but to me that `#:break-unless' is even harder to read than `#:until'. Possible explanation: break unless makes me parse two words and figure out how they combine, and while is something that I know without doing so. Another point to consider in favor of `#:while' and `#:until' is that they're extremely common names, so they're unlikely to be *that* problematic. (I intentionally left the typo in the first sentence as a demonstration of how it's confusing to read...) A different point is that maybe there should also be a `while' and `until' looping constructs in the language? (Whatever they're called.) Every once in a while (ahem) I want that when I write: (let loop () (when (more-work-to-do) (work!))) And it looks like this: (for (#:while (more-work-to-do)) (work!)) would not work in the same way that (for () (work!)) doesn't loop forever(?). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev _ 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] Short-circuiting comprehensions
I like most of that and don't object to the rest, except for leaving out a version of #:break-unless. Especially because break is already a negative word. Just like #:unless (bad?) is more natural than #:when (not (bad?)), #:something (ok-to-continue?) is more natural than #:break (not (ok-to-continue?)). I'd suggest #:continue, but in C-like languages I believe that means something different. Actually, we could make the whole thing more positive (or, ironically, less negative) by going with #:do-while and #:do-until, something like that. It brings back the nicely mnemonic while and until, is hard to confuse with when and unless, and do isn't that much extra to read. And it's positive, so it doesn't reverse the meaning of the second word. Carl Eastlund On Fri, Sep 14, 2012 at 4:25 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 14 Sep 2012 15:30:22 -0400, Eli Barzilay wrote: Four hours ago, Matthew Flatt wrote: Also, I think the names `#:while' and `#:until' are too close to `#:when' and `#:unless'. I suggest `#:break-when' and `#:break-unless'. Compare: (for*/list ([j 2] [i 10] #:when (i . . 5)) i) '(0 1 2 3 4 0 1 2 3 4) (for*/list ([j 2] [i 10] #:break-unless (i . . 5)) i) '(0 1 2 3 4) I imagine that `#:break-when' and `#:break-unless' are allowed among the clauses much like `#:when' and `#:unless', but also allowed at the end of the body. Is that what you had in mind? Sorry for the bike-shedding, but to me that `#:break-unless' is even harder to read than `#:until'. Possible explanation: break unless makes me parse two words and figure out how they combine, and while is something that I know without doing so. After trying out various options, I agree that `break-when' is too many words. I'm currently trying just `break' and dropping `break-unless', and that feels better. At Fri, 14 Sep 2012 11:49:20 -0400, Carl Eastlund wrote: I agree that #:while and #:until are easily confused with #:when and #:unless. I slightly prefer #:stop- to #:break- as a prefix here, it seems a more natural word. I like break because it goes with for, it avoids potential confusion with stop in `stop-after' and `stop-before', and it is more clearly different from final (which is used below). I like the idea of allowing these clauses at the end of the body to give a notion of stopping after the current iteration. It turns out that allowing `#:break' at the very end of the body causes problems with scope and composition. Imagine trying to implement `for/set' by wrapping its body in an expansion to `for/fold'. Maybe you can look from the end of the body and skip back over `#:break' clauses, but now imagine that the last form before `break' expands to a combination of a definition and an expression, and the `#:break' clause wants to refer to the identifier that is bound in the expansion. We could probably make all that work with `local-expand' and internal-definition contexts, but that gets complicated. Requiring an expression at the end of a `for' body --- while allowing `#:break' clauses otherwise interspersed in the body --- avoids composition and scope problems. Macros still have to do a little work to juggle `#:break' clauses, but a `split-for-body' helper function is straightforward to use. Meanwhile, to support breaking after the current element, I'm trying out `#:final'. A `#:final' clause is like `#:break', except that it ends the loop after the next run of the body. (The two kinds of clauses closely related to `stop-before' and `stop-after'.) (for/list ([i 10]) #:break (= i 2) i) '(0 1) (for/list ([i 10]) #:final (= i 2) i) '(0 1 2) (for ([book '(Guide Story Reference)] #:break (equal? book Story) [chapter '(Intro Details Conclusion)]) (printf ~a ~a\n book chapter)) Guide Intro Guide Details Guide Conclusion (for* ([book '(Guide Story Reference)] [chapter '(Intro Details Conclusion)]) #:break (and (equal? book Story) (equal? chapter Conclusion)) (printf ~a ~a\n book chapter)) Guide Intro Guide Details Guide Conclusion Story Intro Story Details (for* ([book '(Guide Story Reference)] [chapter '(Intro Details Conclusion)]) #:final (and (equal? book Story) (equal? chapter Conclusion)) (printf ~a ~a\n book chapter)) Guide Intro Guide Details Guide Conclusion Story Intro Story Details Story Conclusion (for ([book '(Guide Story Reference)] #:final (equal? book Story) [chapter '(Intro Details Conclusion)]) (printf ~a ~a\n book chapter)) Guide Intro Guide Details Guide Conclusion Story Intro _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] What are single flonums good for?
TR doesn't support them anyways because there are only typed f64 vectors and not typed f32 vectors. Jay On Fri, Sep 14, 2012 at 11:28 AM, Robby Findler ro...@eecs.northwestern.edu wrote: As far as I can tell, if this pollutes TR programs in any interesting way, then it would be a cause for concern. Robby On Fri, Sep 14, 2012 at 12:21 PM, John Clements cleme...@brinckerhoff.org wrote: On Sep 12, 2012, at 1:03 PM, Jay McCarthy wrote: On Wed, Sep 12, 2012 at 8:31 AM, Neil Toronto neil.toro...@gmail.com wrote: Compatibility with C code? Why not have the FFI convert them? Save space? I can see that. It won't help much if they're sent to math library functions, though. Those will convert them to flonums and usually box the converted values. I think these are big deals with respect to libraries that you deliver large float matrices to where you want to efficiently store a big f32vector rather than an f64vector. Examples of this include OpenGL where vector coordinates, colors, etc are typically floats and not doubles. Jay's concern is the same as mine; there are situations (getting rarer) where a huge c-style array of f32s is the only way to interact with a library. For instance, in the extremely popular JACK library (Golly, I wish it worked on windows…), all audio data is represented as 32-bit floating point values (from their web page). I haven't followed the conversation closely enough to understand the ramifications of the proposed change, though; my guess is that the ffi can still address such arrays, it's just that computing with these values will require coercion. I could be okay with that; based on my understanding of the IEEE floating-point spec, such a translation could be pretty fast; 32bit - 64bit looks like it would just be adding zeros, and 32bit to 64bit would require checking for exponent overflow; either way, this sounds like something that might be done on-chip by modern processors, and in fact might *already* be taking place in floating point 32-bit operations. (Anyone know whether Intel chips internally represent 32-bit floats as 64-bit ones?) John _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Optimization Coach suggestion / question
I used the optimization coach for the first time today. First, a suggestion. I wrestled with it for about five minutes before I realized that it applied only to programs written in TR. An error message here would be *really* useful; I kept mousing over and clicking and unclicking things to get the results of the coach to show up. Second, I'm trying to see what difference inlining makes, using this program that basically just fills a vector with a sine wave. Turning on the coach for the program below suggests to me that either a) no inlining is occurring for the call to supply in the body of the loop, or b) the coach isn't displaying that information in a way I understand. Any hints? John #lang typed/racket (require racket/flonum) (define f (make-flvector (* 10 44100))) (define srinv (/ 1.0 44100.0)) (define k (* srinv 440.0 1/44100 2 pi)) (: supply (Integer Flonum - Void)) (define (supply i t) (flvector-set! f i (sin (* k t (time (for ([i (* 10 44100)]) (define i#i (exact-inexact i)) (supply i i#i))) smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Optimization Coach suggestion / question
On Sep 14, 2012, at 4:50 PM, Vincent St-Amour wrote: At Fri, 14 Sep 2012 15:39:22 -0700, John Clements wrote: I used the optimization coach for the first time today. First, a suggestion. I wrestled with it for about five minutes before I realized that it applied only to programs written in TR. OC works on programs in any language, but in untyped languages it only reports inlining information. An error message here would be *really* useful; I kept mousing over and clicking and unclicking things to get the results of the coach to show up. The issue here is that, if OC doesn't have anything to say, it displays its control panel, but nothing else. It should really at least show a message explaining that it has nothing to report. I'm adding this to my to-do list. Second, I'm trying to see what difference inlining makes, using this program that basically just fills a vector with a sine wave. Turning on the coach for the program below suggests to me that either a) no inlining is occurring for the call to supply in the body of the loop, or b) the coach isn't displaying that information in a way I understand. On git HEAD, OC reports that `supply' is inlined 4 out of 4 times. Inlining reporting was broken earlier this week as a result of changes to the logging system. I pushed a fix on Tuesday. Nice! Thanks. John smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] What are single flonums good for?
The original message in this thread suggests that there is a type Single-Flonum and that it is making Neil wrangle his code to be careful about it. Robby On Fri, Sep 14, 2012 at 3:55 PM, Jay McCarthy jay.mccar...@gmail.com wrote: TR doesn't support them anyways because there are only typed f64 vectors and not typed f32 vectors. Jay On Fri, Sep 14, 2012 at 11:28 AM, Robby Findler ro...@eecs.northwestern.edu wrote: As far as I can tell, if this pollutes TR programs in any interesting way, then it would be a cause for concern. Robby On Fri, Sep 14, 2012 at 12:21 PM, John Clements cleme...@brinckerhoff.org wrote: On Sep 12, 2012, at 1:03 PM, Jay McCarthy wrote: On Wed, Sep 12, 2012 at 8:31 AM, Neil Toronto neil.toro...@gmail.com wrote: Compatibility with C code? Why not have the FFI convert them? Save space? I can see that. It won't help much if they're sent to math library functions, though. Those will convert them to flonums and usually box the converted values. I think these are big deals with respect to libraries that you deliver large float matrices to where you want to efficiently store a big f32vector rather than an f64vector. Examples of this include OpenGL where vector coordinates, colors, etc are typically floats and not doubles. Jay's concern is the same as mine; there are situations (getting rarer) where a huge c-style array of f32s is the only way to interact with a library. For instance, in the extremely popular JACK library (Golly, I wish it worked on windows…), all audio data is represented as 32-bit floating point values (from their web page). I haven't followed the conversation closely enough to understand the ramifications of the proposed change, though; my guess is that the ffi can still address such arrays, it's just that computing with these values will require coercion. I could be okay with that; based on my understanding of the IEEE floating-point spec, such a translation could be pretty fast; 32bit - 64bit looks like it would just be adding zeros, and 32bit to 64bit would require checking for exponent overflow; either way, this sounds like something that might be done on-chip by modern processors, and in fact might *already* be taking place in floating point 32-bit operations. (Anyone know whether Intel chips internally represent 32-bit floats as 64-bit ones?) John _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
