Bug New maximizer apparently doesn't always force requirements

[Theraze]

> mymax 100 items, stench res, 1 min, 1 max

Maximizing...
24 combinations checked, best score 16,558.50 (FAIL)
Putting on miner's helmet...
Equipment changed.

> mymax 100 items, stench res, 1 min, 1 max, equip harem veil

Maximizing...
24 combinations checked, best score 16,059.50
Putting on Knob Goblin harem veil...
Equipment changed.

Mymax is my normal maximization alias, but some part of it is breaking the maximizer. When I manually force an item part, it stays successful... when I forced the harem veil there, for example, it stayed worn. Here's the full string that's failing:

> maximize 0 beeosity, 4 item, 3 meat, 2 mainstat, .05 familiar weight, ranged damage, weapon damage, .1 initiative, -melee, 100 items, stench res, 1 min, 1 max

Maximizing...
24 combinations checked, best score 16,558.50 (FAIL)
Putting on miner's helmet...
Equipment changed.
Unable to meet all requirements via equipment changes.
See the Modifier Maximizer for further suggestions.

and being dumped:

> maximize 0 beeosity, 4 item, 3 meat, 2 mainstat, .05 familiar weight, ranged damage, weapon damage, .1 initiative, -melee, 100 items, stench res, 1 min, 1 max, dump

Maximizing...
SLOT 0
[miner's helmet]
SLOT 1
[Shagadelic Disco Banjo]
SLOT 2
[loadstone]
SLOT 3
[Misty Cape]
SLOT 4
[]
SLOT 5
[Boss Bat britches]
SLOT 6
[Baron von Ratsworth's monocle, Nickel Gamma of Frugality, observational glasses]
SLOT 7
[]
SLOT 8
[ultimate ultimate frisbee]
SLOT 9
[]
SLOT 10
[]
SLOT 11
[]
SLOT 12
[rave whistle]
16 combinations checked, best score 16,558.50 (FAIL)

Why does it not even offer a single equipment variance besides the 1/2 hand bit? No clue.

 

[jasonharper]

With item drop being given 100 times the weight of stench resistance, there is basically no chance for anything that gives stench resistance alone to make it into any of the shortlists.

The only way to make this work correctly would be to generate separate shortlists for each individual requirement, then merge them. In the worst case (no overlap between the shortlists), the number of items being considered in each slot would double, leading to a 100X or worse slowdown in examining all the combinations (and that's with just two requirements).

 

[Theraze]

So does this fall into "Bug - won't fix" or is there some other solution allowing for providing my own tiebreaker when item requirements come up?

 

[roippi]

To be clear, old maximizer used to work?

 

[Theraze]

Yes, because requirements were forced. If any location COULD provide a stench res, it would have been in the short list and mafia/the maximizer would always have found something that worked.

So this is caused by 11690, which is otherwise awesome.

 

[roippi]

So yeah for one, there's no need to weight items that highly in your example. They are already about an order of magnitude more plentiful than stench res (+~20vs +2-3 per item, roughly) and you're putting two more orders on top of that.


But obviously that's not a solution. Maybe we can fall back to old behavior if no solution is found first pass? Meh, that's a pretty terrible hack. I'll think more on it. (Or, more likely, Jason will)

 

[xKiv]

After creating shortlists, check if minimums/maximums can be satisfied at all (each min/max separately, simply by finding max/min for that modifier for each slot and summing), and if not, expand shortlists (with only items that promise to get closer to the min/max requirement [1]), one by one, until satisfying (each requirement separately) is possible at all?

[1] if minimum in X wasn't reached, find the highest scoring item with X > max(X of $item's slot) and add to $item's slot's shortlist
vice versa for maximum

 

[Theraze]

Guessing that the eventual goal will be something like jason said, if you ask for a requirement, have both a "best score" and a "best score considering requirement" item added to each slot's shortlist. For most slots with one requirement, this would increase their consideration by 50% (current, best, +requirement). If you have 3 failable requirements, that would obviously add 150% instead.

Basically, your execution would slow as you add requirements. No change for normal weighted entries, but clownosity and raveosity would see a speed hit. And improved (from 11690) wearing when mixing that with +item drop or other, more complicated weightings.

 

[xKiv]

Basically, your execution would slow as you add requirements.

That's true no matter how you choose to solve the optimalization (unless you use idiotsort - go through *all* possible permutations of everything, every time).
The interesting question is, how to solve it so that 1) it finds a correct (feasible, optimal) solution, or an acceptably close approximation and 2) is reasonably fast even with moderately complex constraints.