Bug - Fixed Wasteful suggestions from maximizer?

[DaveK]

Hi all,

I've noticed some peculiar and seemingly suboptimal suggestions from max lately. Here's one I can reproduce any time: when I ask it to optimize "adv" using just what's "on hand", I get the following suggestions:



As soon as I enable checking "createable"s, however, it tells me to make a Staph of Homophones:



It seems wasteful to create an item that doesn't give me any more +adv than one I already have. Is this a bug? If so, does anyone have any advice on how to debug the maximizer?

 

[Cool12309]

I'd imagine that's due to the tiebreaker favoring the staph of homophones. Use -tie to stop that.

 

[DaveK]

I'd imagine that's due to the tiebreaker favoring the staph of homophones. Use -tie to stop that.

I had forgotten about the tiebreaker, I admit, but no; maximising "adv, -tie" produces the exact same result.

(Even if this turns out to be nothing, I'd still be glad of any maximiser-debugging tips, btw.)

 

[heeheehee]

Maybe Maximizer prefers staph of homophones because it has a higher item ID? (I really have no idea)

 

[Darzil]

-Tiebreaker just won't change existing equipment. As they are the same, both will be considered, and the evaluation process isn't considering the cost of making items, as it doesn't know where mafia intends to get them from. It is just trying to work out the best combo for your maximization string.

If you want to really make sure you don't get the staph, do "adv -equip staph of homophones"

 

[DaveK]

-Tiebreaker just won't change existing equipment. As they are the same, both will be considered, and the evaluation process isn't considering the cost of making items, as it doesn't know where mafia intends to get them from. It is just trying to work out the best combo for your maximization string.

Is that by design, or just a limitation of the architecture? It seems like an undesirable result to me, and after all, the information is at least theoretically available, since mafia definitely has it by the time it's deciding whether to add the "make [n] & " prefix or not.

If you want to really make sure you don't get the staph, do "adv -equip staph of homophones"

Well, it's not just the staph; I don't want to get /anything/ that needs to be created when I already have an existing item that scores equally hghly on the value beng maximised. I did this, and it solves my test case:

### Eclipse Workspace Patch 1.0
#P kolmafia
Index: src/net/sourceforge/kolmafia/maximizer/MaximizerSpeculation.java
===================================================================
--- src/net/sourceforge/kolmafia/maximizer/MaximizerSpeculation.java	(revision 16170)
+++ src/net/sourceforge/kolmafia/maximizer/MaximizerSpeculation.java	(working copy)
@@ -159,6 +159,14 @@
 		if ( rv != 0 ) return rv;
 		if ( this.attachment != null && other.attachment != null )
 		{
+			// If we have one item but not the other, that one wins.
+			if ( this.attachment.initial * other.attachment.initial == 0 )	// true if either zero
+			{
+				if (( this.attachment.initial | other.attachment.initial ) != 0 )	// true if either non-zero
+				{
+					return this.attachment.initial != 0 ? +1 : -1;
+				}
+			}
 			// prefer items that you don't have to buy
 			if ( this.attachment.buyableFlag != other.attachment.buyableFlag )
 			{

That way of expressing the xor condition is a bit obfuscated for an actual submission, but what do you think about the general idea of breaking an otherwise-tie at that point and in that way?

 

[Theraze]

What happens if you run your initial maximization with it set to only use owned equipment, and then run "maximize current, adv, -tie" after you tell it to add creatable items?

 

[Darzil]

That way of expressing the xor condition is a bit obfuscated for an actual submission, but what do you think about the general idea of breaking an otherwise-tie at that point and in that way?

Seems a good approach, will investigate something similar.

It's one of the bits of maximizer I haven't played with, but given we have buyable in there, it's worth a shot. I might replicate the acquire hierarchy, so that it does as expected.

 

[Crowther]

That way of expressing the xor condition is a bit obfuscated for an actual submission

As are a couple of your other constructs. Reminds me of someone who started programming before optimizing compilers become common place. Over two decades ago!

 

[Darzil]

r16188