Thanks Neil,
Each vector is in the order of about a thousand cells and there are
about a thousand of these vectors that are processed at one time. So
as long as I can do that in 10 or 20 seconds thats fine. So as long
as its "relatively efficient" I think I'm OK. Whats just as important
to me, is "clarity of the code", so that when I go back and look at
this and other code six months from now I can still figure out what I
did.
Harry
On Sun, May 13, 2012 at 5:28 PM, Neil Van Dyke <n...@neilvandyke.org> wrote:
> Harry Spier wrote at 05/13/2012 04:47 PM:
>
>> Is there a better way to do this iin Racket (shorter, clearer, more
>> readable)?
>>
>
>
> If this you are doing large numbers of this operation, and you are
> performance-sensitive, I suggest that one of your top criteria for
> ``better'' should be *efficiency*.
>
> From a glance, I think you could do this more efficiently, even if you don't
> use bit-banging tricks. For doing this efficiently without bit-banging, I
> suggest keeping this mantra in mind: "minimize consing". That's far from
> the only advice or even best advice, but I think it's a good place to start
> in this case. I mention it because you are doing some good things in your
> code, and I think now is the time to be thinking more about consing.
> ("Consing" is when a pair is allocated by Racket, and is an old, simplified
> model for reasoning about allocation and performance in Lisps. "cons"
> allocates one pair; "list", "reverse", "append", etc. allocate many pairs.)
>
> After you change the code for reduced consing, you can look at smaller
> things in that code, like whether you're doing any tests or other
> computation redundantly, whether "vector-ref" is faster than some
> stream/iterator abstraction, Boolean algebra reduction, etc.
>
> If you don't care about optimizing this, then I suspect people will push you
> in different directions than I would.
>
> Neil V.
>
____________________
Racket Users list:
http://lists.racket-lang.org/users
