Bug - Fixed Wasteful suggestions from maximizer?

D

DaveK

New member
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:

kolmax1.png

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

kolmax2.png

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 said:
I'd imagine that's due to the tiebreaker favoring the staph of homophones. Use -tie to stop that.
Click to expand...
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.)
 
-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"
 
Darzil said:
-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.
Click to expand...

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.

Darzil said:
If you want to really make sure you don't get the staph, do "adv -equip staph of homophones"
Click to expand...

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:
Code: 
### 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?
 
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?
 
DaveK said:
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?
Click to expand...

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.
 
DaveK said:
That way of expressing the xor condition is a bit obfuscated for an actual submission
Click to expand...
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!
 
You must log in or register to reply here.
Back
Top