For a project that is not an externally imposed assignment you should work on whichever aspect holds your interest, provided that you do not advertise a project with outstanding issues as bug free to others.
I'm very interested in doing the right thing if I can, and I'm certainly not interested in wasting such a valuable chance to improve my self as the one you've presented with your criticism. I think I'll throw on some music, grab some caffeine and make a bit of a programming day out of starting through the backlog today.
If one class of operations loses a small constant factor while another class of operations gains an order of growth improvement, the change is probably worth it.
As a matter of principle, replacing an abstraction layer and inlining a particular implementation is indeed a bad choice. You might do that in a C accelerator module only after profiling shows that your abstraction layer specifically constitutes a performance bottleneck.
I think I knew both of these things but I needed someone else to tell them to me so that I stop being lazy (that weird kind of lazy which is more work in the end) and just do them.
Having said that, you have an outstanding double lookup issue in the append operation since >>16 so performance issues seem to receive a rather mercurial weight.
I naively thought this issue as well as a number of issues with the final few functions would simply go away with the rewrite. When the tree is insufficiently balanced I'm of course going to be doing all the same operations though.
I could only allocate a portion of my leisure time to this, which is why it took 13 days. It was still fast enough that there are several explained but still unresolved organisation, efficiency and correctness issues.
I certainly could've done better with keeping up with your suggestions I'll try to resolve that a bit today. Even with it being a little bit spread over 13 days time is so valuable and you're beautiful anon.
>>31
While I won't be touching the political stuff on a programming board, here are some programming observations
I probably should've simply removed the original blurb for the sake of posting here, sorry about that.
Both the 'down' and 'incomp' functions contain lambdas that repeat the same (vector-ref ballot party) lookup on each round. For the purposes of the lambdas this is a constant computation and should be done once, before the ballot-filter-sum invocations.
Your *-sum function increments a 0-based accumulator by either 0 or 1 based on the suitability of each item. This is called a *-count.
Both 'ballot-max' and 'ballot-filter-sum' are vector folds. Writing them in terms of a vector-fold would be cleaner.
The 'tally' function contains an inlined vector-inc!, which could be made explicit.
I finished all but correcting ballot-max and tally this morning, these I still need to consider. I can't find documentation on vector-inc! & I'm trying to figure out how to get a index out of vector-fold nicely, or otherwise a different procedure to do it. I've also started adding back the abstractions and thought of a new weight function that I think might give more desirable results, I haven't added it yet however. Anyway on to the radix library for the rest of the day. http://ix.io/1xzN Thanks as always anon.