jasonharper
Developer
Because people were screaming bloody murder about the Maximizer making useless changes in equipment, for slots where you had no truly useful items.
Feature - Implemented Let maximizer stop when it is not finding a better score
- Thread starter Veracity
- Start date
Because people were screaming bloody murder about the Maximizer making useless changes in equipment, for slots where you had no truly useful items.
xKiv
Active member
I presume this includes synergies too?
What about brimstone, cloathing, ...? That's not just outfit, but a *variable* synergy. Does that fall under this change, or too complicated?
Wouldn't the proper "fix" there be to, after maximizing, notice that leaving in the previous item would get the same score, and quietly forgetting about any found replacement? (optimally also accounting for entire synergetic groups of equipment, as discussed in at least one earlier thread) That has to be faster anyway.
Bale
Minion
That does seem appropriate, but it might be more confusing to people who don't get why maximize behavior changes.
fractalnavel
Member
Add those defaults, and expose them as preferences in the Automation section?
It doesn't currently. There aren't many synergies, and whilst they add most of the impact, they would be much harder to account for simply, as sometimes you get the best benefit from including only some of them. Outfits you wear as a whole, so are easy to compare. Brimstone and Clothing would be considered as outfits by this, but may well be included as synergies also.
I suggest we see how it comes out. In practice many items are separated by the tiebreaker unless they have identical bonuses. Synergies and outfits make accounting for score changes harder, as single pieces can have zero or even negative scores, but the whole have positive. We may find this is less of an issue in practice.
r14517, lets see what people think !
Theraze
Active member
The one issue here is that it makes it much harder to meet requirements. Now, to meet requirements, you not only have to do 2 maximizations, but you need to remember that the second maximization is +current.
Details:
http://kolmafia.us/showthread.php?11555-New-maximizer-apparently-doesn-t-always-force-requirements
http://kolmafia.us/showthread.php?1...-consider-requirement-failures-(which-are-a-g
If I remember properly, mafia had been eliminating any item that did not help to meet requirements from the maximizer until it was met. So you needed to maximize twice to actually get the best maximization, BUT it would always meet requirements. Revision 11690 removed requirement failures as a reason to remove possible items, so you could still get awesome items even if they don't meet the requirement you noted. However, since it just takes the single best, if you don't end up with an item that meets requirements also being the best for whatever weighting you're doing, mafia will fail maximization - even if you really CAN meet the requirement.
The suggestion I made 2 years ago was, when requirements were made, to include both a 'best overall' and 'best helping to meet requirements' item into the calculation, if requirements are given. This would not slow normal maximizations down, since it would only add if requirements are added, but would mean that a single maximization should be accurate as to whether or not mafia can meet your request.
Obviously, this is not a new problem... this change just exacerbates it, making it harder to work around.
Details:
http://kolmafia.us/showthread.php?11555-New-maximizer-apparently-doesn-t-always-force-requirements
http://kolmafia.us/showthread.php?1...-consider-requirement-failures-(which-are-a-g
If I remember properly, mafia had been eliminating any item that did not help to meet requirements from the maximizer until it was met. So you needed to maximize twice to actually get the best maximization, BUT it would always meet requirements. Revision 11690 removed requirement failures as a reason to remove possible items, so you could still get awesome items even if they don't meet the requirement you noted. However, since it just takes the single best, if you don't end up with an item that meets requirements also being the best for whatever weighting you're doing, mafia will fail maximization - even if you really CAN meet the requirement.
The suggestion I made 2 years ago was, when requirements were made, to include both a 'best overall' and 'best helping to meet requirements' item into the calculation, if requirements are given. This would not slow normal maximizations down, since it would only add if requirements are added, but would mean that a single maximization should be accurate as to whether or not mafia can meet your request.
Obviously, this is not a new problem... this change just exacerbates it, making it harder to work around.
I'd suggest raising a feature request showing what you'd like to see, and getting others to support it.
Having to add +current to one of 2 complex maximization strings does not qualify as "much harder" to me, but then I've never tried such complex maximizations, and maybe that makes me unusual. Certainly these changes are making maximize run 20-50 times faster for me.
I've not mucked around with requirements, but I guess on a quick thought that you'd need to split the initial requirements into multiple sections, run through evaluator.enumerateEquipment once for each set, adding all equipment, then consider all that equipment in all combinations. It'd work, but I'd guess it'd run 1000 or more times slower, as MaximizerSpeculation is massively sensitive to the number of items provided (which is why my changes made so much difference). Personally if I'm trying to maximize two things I tend to maximize the requirement first, equip the items, then maximize excluding those slots. That's faster anyway. I imagine you aren't talking about a script situation, as clearly adding "+current" to a script isn't "much harder".
If it was set not to force consideration of current items, then I'd agree it'd be a bug with this change. As that option has been left open, and this change will help the large majority of users in the majority of cases, I believe, then I do not consider that a bug with this change.
Having to add +current to one of 2 complex maximization strings does not qualify as "much harder" to me, but then I've never tried such complex maximizations, and maybe that makes me unusual. Certainly these changes are making maximize run 20-50 times faster for me.
I've not mucked around with requirements, but I guess on a quick thought that you'd need to split the initial requirements into multiple sections, run through evaluator.enumerateEquipment once for each set, adding all equipment, then consider all that equipment in all combinations. It'd work, but I'd guess it'd run 1000 or more times slower, as MaximizerSpeculation is massively sensitive to the number of items provided (which is why my changes made so much difference). Personally if I'm trying to maximize two things I tend to maximize the requirement first, equip the items, then maximize excluding those slots. That's faster anyway. I imagine you aren't talking about a script situation, as clearly adding "+current" to a script isn't "much harder".
If it was set not to force consideration of current items, then I'd agree it'd be a bug with this change. As that option has been left open, and this change will help the large majority of users in the majority of cases, I believe, then I do not consider that a bug with this change.
I had a long think about this overnight, trying to work out how I'd handle requirements ideally.
Unfortunately if you wanted to do something simple, like say I want to maximize item drop and have at least 1 stench resist (farming for baseball/sonar perhaps), in order to get the ideal item drop you'd have to include the best items for item drop, and also the best items for item drop that also have 1 or more stench resist. This is quite a large increase in the number that MaximizerSpeculation has to deal with.
But it gets worse. If you wanted to have say, maximize spell damage and have at least 3 all resist (Lord Spookyraven), you'd want to include the best items for spell damage, and the best items for spell damage that also have 1 of cold resist, and the best items for spell damage that have 2 of cold resist, and the best items for spell damage that have 3 or more of cold resist, and the best items for spell damage that also have 1 of hot resist . . . and so on. Without a complete rewrite of MaximizerSpeculation to use a much cleverer mathematics that can handle this, I suspect this maximization might take years to run with aftercore levels of equipment.
The two pass system is probably the best for now, although it is an approximation, and won't give ideal values. For example, say you had three items, one gives 10% item drop, one gives 5% item drop and 1 stench resist, the other gives 2 stench resist. Maximizing for stench resist first uses item 3. Maximizing for item drop plus stench resist 1 using +current will, depending on other items, use either item 1 or item 3, but never item 2 which is probably the best, as +items with stench resist is rare.
I fear this sort of optimization problem is better for a Phd than for a quick improvement to Mafia code.
Unfortunately if you wanted to do something simple, like say I want to maximize item drop and have at least 1 stench resist (farming for baseball/sonar perhaps), in order to get the ideal item drop you'd have to include the best items for item drop, and also the best items for item drop that also have 1 or more stench resist. This is quite a large increase in the number that MaximizerSpeculation has to deal with.
But it gets worse. If you wanted to have say, maximize spell damage and have at least 3 all resist (Lord Spookyraven), you'd want to include the best items for spell damage, and the best items for spell damage that also have 1 of cold resist, and the best items for spell damage that have 2 of cold resist, and the best items for spell damage that have 3 or more of cold resist, and the best items for spell damage that also have 1 of hot resist . . . and so on. Without a complete rewrite of MaximizerSpeculation to use a much cleverer mathematics that can handle this, I suspect this maximization might take years to run with aftercore levels of equipment.
The two pass system is probably the best for now, although it is an approximation, and won't give ideal values. For example, say you had three items, one gives 10% item drop, one gives 5% item drop and 1 stench resist, the other gives 2 stench resist. Maximizing for stench resist first uses item 3. Maximizing for item drop plus stench resist 1 using +current will, depending on other items, use either item 1 or item 3, but never item 2 which is probably the best, as +items with stench resist is rare.
I fear this sort of optimization problem is better for a Phd than for a quick improvement to Mafia code.
Theraze
Active member
The way I think it worked before 11690 was that it would include only items that helped to meet the requirement. So in your stench res example, with even weighting, it would have done the better of those that gives benefits at least until the requirements were met... from birthday suit, your items are:
1) +10, no benefit to resistance, eliminated.
2) +6, benefits resistance, kept.
3) +2, benefits resistance, dropped as not as good as item 2.
Where it gets really messy is when people have multiple sets of maximization strings trying to make sure that they can meet requirements. In TheSea, I just maximize for the right combat stat, check to see if we can safely fight with those stats, and start applying buffs if not. In scripts like autoBasement, we have requirements which means that the string can fail and equip... who knows what? When requirements are given to the string and aren't met, mafia doesn't necessarily follow the rest of your maximization request in a logical way...
But yeah. It's not a new problem, it's just something where, anytime someone asks about why their "maximize item drop 3 min stench res" doesn't work to give them 3 stench res, and we explain that they need to put it after the item they want (maximize item drop, stench res, 3 min"), we also need to explain that they'll need to maximize twice to get what they want reliably... maximize stench res; maximize item drop, stench res, 3 min, +current.
1) +10, no benefit to resistance, eliminated.
2) +6, benefits resistance, kept.
3) +2, benefits resistance, dropped as not as good as item 2.
Where it gets really messy is when people have multiple sets of maximization strings trying to make sure that they can meet requirements. In TheSea, I just maximize for the right combat stat, check to see if we can safely fight with those stats, and start applying buffs if not. In scripts like autoBasement, we have requirements which means that the string can fail and equip... who knows what? When requirements are given to the string and aren't met, mafia doesn't necessarily follow the rest of your maximization request in a logical way...
But yeah. It's not a new problem, it's just something where, anytime someone asks about why their "maximize item drop 3 min stench res" doesn't work to give them 3 stench res, and we explain that they need to put it after the item they want (maximize item drop, stench res, 3 min"), we also need to explain that they'll need to maximize twice to get what they want reliably... maximize stench res; maximize item drop, stench res, 3 min, +current.
If the feature can't work better than that (which it sounds like Darzil is saying), at least with any remotely reasonable performance, then the status quo is better than not having the feature at all because it doesn't work ideally, right?
Theraze
Active member
Well, optimally, the script would keep both items 1 and 2 in the list. That would add an item per slot per requirement, if one is available. Which would slow things down, but only when requirements were requested. When no requirements were listed, no additional items need to be added to the considerations.
Nope, that's how long it'd take with one requirement that could only have one value (eg stench res min 1). With higher values (eg stench res min 4) there would be up to 4 best items per slot to additionally consider.
r15342: Got an error likely related to the pruning of +equip items.
Code:
> outfit birthday suit
Taking off everything...
Everything removed.
> maximize adv +equip Sasq™ watch
Maximizing (1st time may take a while)...
150 combinations checked, best score 58.00
Putting on leather aviator's cap...
Equipment changed.
Wielding time sword...
Equipment changed.
Holding Loathing Legion moondial...
Equipment changed.
Putting on Drunkula's cape...
Equipment changed.
Putting on Sneaky Pete's leather jacket...
Equipment changed.
Putting on Pantaloons of Hatred...
Equipment changed.
Putting on Sasq™ watch...
Equipment changed.
Putting on fudgecycle...
Equipment changed.
Putting on grandfather watch...
You can't equip a grandfather watch because you're already wearing a Sasq™ watch.
Unable to meet all requirements via equipment changes.
See the Modifier Maximizer for further suggestions.