On Mon, Aug 23, 2010 at 12:26 AM, Will M. Farr <wmf...@gmail.com> wrote: > Thanks for sharing your code, and for the comments. Let me see if I > understand this correctly: the following code should produce a total, a > vector whose elements are the partial sums of elements at lower indices than > the corresponding element of the input vector, and a vector whose elements > are partial sums of elements at the index and lower indices of the input > vector, right?
Yes, that's correct. > 1. In my forms, the length is optional, and distinguished (when provided) > from the for-clauses by a keyword argument. In yours, it must be provided as > the first for-clause (thus requiring that the index be named). Yes. Note that my for/vector form will iterate over the indices even if no other sequence is provided. Thus you can write stuff like this (taken from some code of mine): (for/vector ([i n]) (create-row (+ i l))) You can ignore the name if you want: (for/vector ([_ n-pts]) ...) > 2. In my forms, the final body expression must produce exactly one value, > which becomes the vector element. In yours, the final body expression must > produce exactly as many values as the third argument to the length clause (if > provided) or 1 (if no third argument is present). Yes. > As for difference 1, I think it's nice to be able to avoid providing a length > if I don't want to. Sometimes I may not really care about the efficiency of > the loop, but will later need a vector, in which case it's a lot less effort > to use (for/vector ((i (in-range 3))) ...) than to have to provide a length. > I also prefer the "distinguished" #:length keyword instead of shoehorning the > length argument into a not-really-for-clause. I'm curious what others think, > however. I like having the index bound to a name if I want it. Otherwise I'm fine with specifying it in an alternate way. > Difference #2 seems more significant to me. I really like the idea of being > able to produce multiple vectors simultaneously---as you say, it can have > efficiency benefits and also be really convenient. However, note that the > for/list form does not allow multiple values from the last body expression, > so there is an argument from consistency to prohibit it in for/vector as well. We don't have to repeat the mistakes of the past :) > I'd be open to adding another keyword argument, however, to designate some >number of vectors (independently of the presence or absence of the #:length >keyword) for the output. I'll put that in the next version, and we can see >what other people think. As with the #:length argument, I would prefer this >to be a separate keyword---maybe #:num-vecs, maybe something else---rather >than trying to fit it into a special for-clause. Alternatively, it could be a for/vectors / for/fold/vectors form. I'm neutral. N. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
