Sounds like you might be able to model it as a knapsack problem with budgets as weights and scores as values.
For a little intuition into what will happen, consider a greedy algorithm to solve the knapsack. Assuming that the individual budgets are relatively small compared to the total budget the real solution should be close to the greedy solutiuon, which is sorting all items by value over weight and taking all the items with the highest ratio first. Cheers, Jordan On Wed, Mar 5, 2014 at 2:36 PM, Laurens Van Houtven <_...@lvh.cc> wrote: > Hi David and Alex, > > > Thanks for your replies! I'm having trouble communicating it, and the > underspecifiedness doesn't help. Perhaps that just means I don't > really understand the problem. Please let me know if any particular > parts are hazy. > > What we *really* care about is getting people to the conference that > otherwise wouldn't. If we have to pick between people with a high > score (say, a speaker who is also a student) and someone with a low > score (someone who doesn't really appear to be very serious about > attending let alone contributing), we'd pick the high scoring person. > > When I say score, it's one of the functions in the source file I > linked. Think scalar product; it's a weight vector times ((apply comp > fs) person). I'm flexible as to what that score looks like, but it'd > be nice if there are tweakable values that map directly to real-life > concepts; e.g. I can tell that we're valuing open source contributions > twice as heavily as studenthood. > > I'm having trouble conveying more details without having to explain it > in terms of one particular model. Since I've done integer programming > and constraint programming before, I'll do that. Please don't > interpret that as a bias against core.logic and its ilk :-) > > Since we're optimizing for attendance weighted by score, we're > minimizing the sum of (* -1 score) of all the people not attending, > subject to the sum of scores of all the people that *are* attending > being less than or equal to the budget. > > That actually sounds like something that shouldn't be too hard to dump > into a constraint solver. Perhaps I'll play with Loco tomorrow (it's > late here) and compare the results. > > David: does the above clarify somewhat? Would sample data help? > > Thanks again! > lvh > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
