I just found my new favorite MtG ruling, on Lore Seeker

> If you use Agent of Acquisitions to draft a booster pack containing Lore Seeker, and you wish to add a booster pack to the draft, first draft each remaining card from the Lore Seeker booster pack. Then open the new booster pack. You may look at the cards in that pack, but you can’t draft any cards from it. You’ll pass the new booster pack as normal. That was very generous of you.

@murgatroid99 hmm... Agent of Acquisitions

@murgatroid99 Wow. XD

That was good.

@codebreaker @murgatroid99 I sandboxed a challenge on Programming Puzzles and Code Golf that you might be interested in participating in. The sandbox is where challenges gather feedback before being posted. It gives them a sort of polish and hopefully closes any loopholes that might be abused.

I'll let you know when it hits the main site, where you can actually post an answer if you want to. In the meantime, feel free to provide feedback via comments. It could probably use feedback from someone who knows about MTG as much as someone who doesn't.

That does look interesting, but I'll have to actually figure out the algorithm before I have a hope of golfing it

Actually, without all of the other complexity of real mana costs (snow lands, phyrexian mana, etc), it shouldn't be as complicated

still, there are some tricky cases

You'd be surprised by how much your mind opens up when you start to golf. A normal programmer looks at the problem and says "wow, that needs a complicated algorithm". A code golfer looks at it and says "Try all possible combinations and we're done."

That's the beauty of code golf. You can stop worrying about efficiency

the colorless hybrid symbols make that a little tricky

Especially because your description allows for arbitrary colorless numbers on the hybrid, not just 2

Hopefully I limited it to positive integers

Yup, I think that's good

I'm a little disappointing by the look of the challenge. Lot of single liner's separated by bulleted lists

Even with that, it can be tricky to determine that {5/W}{W/B}{B/R} can be paid by {W}{U}{U}{B}{G}{G}{G}

Or figuring out what mana pools can pay {W/U}{U/B}{B/R}{R/G}{G/W}{W/B}{B/G}{G/U}{U/R}{R/W}

Actually, with a brute-force, try-all-combinations approach, that's easy

Hybrid symbols are probably the only really tricky part

   sort such that colorless is last

   method:

   For each symbol:
       If hybrid, choose one, then recurse
       else if not hybrid, fulfill the requirement, then recurse

Oh, I meant colorless hybrid symbols

Like {2/U}

Choose one, then choose the other

So choose 2, then if it doesn't work out, choose U

@Rainbolt I mean that choosing the colorless side means iterating over all unique n-tuples of available mana

If you choose the colorless one, then you have to resort such that colorless is last

Well no, you sort it so that you satisfy the colored requirements first

The colorless just becomes what is left

Oh, I see what you're saying

resort => re-sort

My pseudocode is bad because I ran out of time to edit

I've convinced myself that it would work, but sorting and re-sorting is expensive

(in terms of characters)

because mana doesn't have a defined natural order, so you'd have to define it

You don't have to sort. You can just make colorless an additional recursive parameter

Ah true

if you have no more symbols to check, you just check whether you have enough mana for the colorless

If symbols.empty() return mana.size() >= colorless

exactly

what about colorless mana in your mana pool?

Doesn't exist in this challenge

Even if it did, it can only be used to pay for colorless costs, so handling it would be really simple

Neither does phyrexian mana. But are you asking how this method could be extended to real Magic?

phyrexian mana can always be ignored if you're willing to assume your life total is high enough

Phyrexian blue becomes hybrid mana {2 life/U}. And your life total becomes mana.

Hmmm... I just realized that this is extensible to tricolor mana.

@Rainbolt Phyrexian mana isn't as much of a problem as snow mana, myr superion, and imperiosaur

A tricolor is actually just a hybrid hybrid. {U/{R/G}}

The location of the inner curly braces is kind of arbitrary

I think it's unlikely they'll ever do that

It would probably be hard to read

yeah

Well, they may print a negative symbol like "not red" and have reminder text like "not red" can be paid with anything that is not red. I can see them doing that.

it's like, if they reprinted Transguild Courier, how would they make the color indicator?

@Rainbolt At that point, they'll probably just have text that says "You can't use red mana to pay for X"

@codebreaker At least that is just colors, without symbols

@murgatroid99 yeah, true.

@Rainbolt @murgatroid99 I've been thinking more about how to represent mana costs, and I've decided I don't like the idea of having a COLORLESS value in the symbol enum that I can put in the multiset.

For two reasons. The first is, I want to represent the multiplicity of each mana symbol, and colorless symbols are only either absent or present. I don't think the value of the colorless symbol should be represented as its multiplicity, it seems inconsistent.

And second, if I want to redesign hybrid symbols as a pair of other symbols, there would be no way to represent {2} as one symbol.

So I'm thinking I could make Symbol an interface, which would have two implementations: the enum of symbols like I have now, and a Colorless class that would basically be an int wrapper. What do you think?

@codebreaker The thing with this is that "A cost of 3 colorless" isn't substantially different from "A cost of 3 green"

I think you have to really consider what "symbol" means in the context of your program and how you use it

@murgatroid99 But the way it's represented is substantially different. I think the way I'm conceptualizing symbol is "a circle with something in it," which means ManaCost would simply be a collection of those, rather than an unordered blob of mana amounts. I'm trying to balance the mechanical aspect of it with the representative aspect.

You are confusing how it is displayed with how the rest of your program uses it

I personally think that UI considerations should come last

The only guy that needs to be worried about how colorless mana gets displayed is a function called getForDisplay()

Let me put it this way: the algorithms for determining if a pool satisfies a cost is a ton more complicated than making a circle with a number in it.

My goal is to represent reality as faithfully as possible. Is that not the right goal?

@codebreaker Take a look at this diagram: codeproject.com/KB/cs/Three_Layer_Architecture/3lyrs2.jpg

In your data layer (not shown), you have the mana costs of every card known to the program

In the data access layer, you get that cost out of the database

The concern here at this layer is not how to make it look like real life. It's to store it in a way that makes sense

Once you get it out of the database, you put it into an object. That object is manipulated by your business logic layer

Those manipulated objects then get displayed in the UI

Does it make a difference that this is supposed to be library code, not application code?

You can faithfully represent a circle with a 3 in it without storing it like that. Let your business logic layer turn what you have {1}{1}{1} into what you need for display {3}

@codebreaker Isn't someone eventually going to use your library code in an application?

@Rainbolt Well sure, my thought is at the library level you don't want too much information hiding

when the information that you're hiding is actually important

What information is being hidden?

the fact that {3} is an indivisible symbol

conceptually, the symbol enum is indivisible symbols

Indivisible on the UI you mean?

But totally and completely divisible everywhere else?

What I mean is, each symbol has, for example, a converted value and a string representation

This is your library, and you've obviously thought about this specific aspect enough, so just do it your way and run with it

no, I want my opinions to be challenged

thats why I brought it here

I've already told you how I would do it, and your primary objection seems to be that it doesn't look that way in real life

it's also inconsistent with the other symbols

Really? {1}{1}{1} represents three colorless. {R}{R}{R} represents three red. That seems consistent to me

It's like a bonus that the CMC is now symbols.size() instead of symbols.size() plus some integer.

@codebreaker I know the conversation drifted away from this, but your goal should be to represent it as usefully as possible

@Rainbolt colorless hybrid symbols still complicate that a little

Yea, that's true

@murgatroid99 yeah, I liked the idea of hybrid symbols containing other symbols

But you can still do sum(symbol.cmc * symbol.count for symbol in cost) (or equivalent), where the cmc of a hybrid symbol is variable

@Rainbolt also remember {2/G} has converted value 2, so the symbols.size() trick still doesnt work

yeah

Well, you didn't say what the size of {2/G} was, so it doesn't "not work"

@Rainbolt It doesn't really make sense for {2/G} to count as exactly 2 elements in a symbol list

If {W/G} also counts as a single element

If that's what the rules say, then why can't we define it that way?

@Rainbolt I don't understand what you're saying

@Rainbolt OK, I'm confused now. What representation are you suggesting where the size property of a collection is equal to the mana cost?

if the symbol is a collection of other symbols, then size is just the max of all the choices

So {2/G} is max of 2 and 1

but you don't want {2} to be a symbol

Correct

{2} is {1}{1} which has a size of 2

G has a size of 1

max of 2 and 1 is 2

@Rainbolt So is {1}{1} a symbol?

{1}{1} is two symbols

@Rainbolt so what data type are you suggesting to represent this?

a symbol is a Collection<Pair<Collection<Symbol>>>?

tr.... a 2d list?

I'm sure there's a simpler data structure

Yeah, that actually seems like more of a pain than what he currently has

what's wrong with making a Symbol object for {0}..{16}?

I kind of like that

@codebreaker Why predefine the range?

@murgatroid99 it doesn't have to be

@Rainbolt and how would you represent that?

inb4 tree

A tree would actually be the simplest way to represent a structure like that

What's a good data structure for boolean logic that only has ands and ors?

wait, we still need to represent {2/X}

X is zero in all zones except on the stack, where it's value is known

@codebreaker that's ({1} AND {1}) OR {C}

sorry, bad placeholder

X meaning any color

like {2/G}

({1} AND {1}) OR {G}

Like murg said (I'm slow to read)

Oh okay, I see

@codebreaker but what I would suggest is a mana cost primitive that's not a symbol. Basically, something that can have a color (or colorless) and a count. Then a hybrid symbol is just a pair of such things

So the cost of Primalcrux is ({G}, 6)

That is the other solution that I think is clean

And the cost of Reaper King is [(({1}, 2), ({W}, 1)), (({1}, 2), ({U}, 1)), etc.]

Commas represent ORs?

Inner-most pairs are the primitive I just described

Next level out is hybrid symbols

Then the whole thing is a list

so a symbol would just be a wrapper for one of these primitives?

or it could contain a pair of them?

@codebreaker No, I'm suggesting that you forget about symbols

I don't even know what symbol means anymore

haha

Can we talk mana and costs?

but symbols exist

they are things

they matter for devotion, for example

Are you gonna model cardboard in your program?

@codebreaker but that doesn't have to be how you represent mana costs

The problem is that we are having different discussion because you are stuck on talking about circles with art inside of them.

what if I want to create a database, and the user wants to search for cards having 3 blue symbols?

@codebreaker Primalcrux's contribution to green devotion is 6. I can figure that out with my representation as easily as with yours

@codebreaker Then you match against ({U}, 3)

I actually like this way better than my idea

Hmmm, does that mean that Nightveil Spectre doesn't count as having 3 blue symbols?

@Rainbolt yeah, that's the problem

those do count as blue symbols

That lack of clarity means that you have to phrase the question more clearly

Ninjad

If you meant "3 blue symbols" as "the cost contains {U}{U}{U}", then what I said was that

Otherwise, you search for "devotion to blue >=3"

{U/B} is a blue symbol though

Basically, you have a ManaCostElement interface with methods like devotionToColor(color) and cmc() and such

Again, you two are having two different discussions

One implementor is the primitive, which contains a color (nullable) and a number

The other is hybrid, which contains a pair of such primitives

{U/B} is a blue symbol if you define blue symbol to include hybrids. It's not if you don't define it that way

Then a total mana cost is a list of ManaCostElement

Then ManaCost can have its own devotion method, which takes the sum of the devotion of all of its elements

Same with cmc

And whatever other methods you need for mana costs

colorIdentity perhaps, which would be the union of color identities of its elements

What purpose does that serve? Color identity of blue is blue. Not sure what we save by stating that

Color identity of blue plus black is blue plus black

Yeah, I realized that after I said it. That's just color

yeah, they're the same thing

The point I'm making is that the representation I'm suggesting is relatively simple (2 classes and an enum), and does everything you need for mana cost

okay, so the only thing I don't like about this setup is, what if we want to search for a specific mana symbol?

like {X} or {R/P}?

we want to find all cards containing that symbol

Oh, right, {X} should probably be another implementor of that interface

Wouldn't X just return zero until it gets replaced by an actual number?

It may as well not even exist except as decoration on the card

I would just make X have converted value 0, yeah

but we still want to mark it, I think

@Rainbolt you might want to find {X} spells

it's just just a UI thing

@murgatroid99 right

@codebreaker you should be able to search for any hybrid ManaCostElement with color={R,G} or whatever

If a cost contains a HybridManaCostElement that is both Red and Green, then the mana cost contains a {R/G} symbol

so what does a hybrid ManaCostElement have internally? a Map<ManaCostElement, Integer>?

@codebreaker No, just ManaCostPrimitive left, right; (private variables)

and a primitive is basically a ManaCostElement with an int?

@codebreaker A primitive is a Color and an int

@murgatroid99 okay

that makes sense

Probably nullable Color to allow for colorless costs

yeah

In the future, you can have another implementor of ManaCostElement for snow mana, if you decide to represent the costs of abilities

Okay, well I'll think about this. I'm not trying to be frustrating, but I'm still trying to figure out why using the Symbol idea, with ColorlessSymbols, is a bad idea

it seems simpler to me

I'm trying not to be biased

The biggest issue is that nobody is documenting the upsides and downsides of everyone's methods, which makes this a not so fruitful brainstorming exercise.

@codebreaker Try implementing whatever methods you need with the class structure I described. Compare the length to the current length of your mana cost code

@Rainbolt @murgatroid99 okay, I'll make a branch or two on my repo and see what it looks like

also, length isn't the only thing that's important, though it's a good indicator

Length here is a proxy for implementation complexity

Actually, now that I think about it, hybrid mana costs should probably also have a count, to deal with multiples of the same symbol

You could always just get a free cyclomatic complexity checker like this one: eclipse-metrics.sourceforge.net

Scott Hanselman says to keep the complexity under 10, with exceptions where appropriate

@Rainbolt yeah, that's what I'm used to

He also says to avoid switch statements, which we will almost certainly fail if we use enumerated types. Every single place that relies on those types will require another switch statement. And when you make a change to the enum? That's a lot of switches you have to fix.

@Rainbolt well my IDE produces a warning if you don't account for all types or don't have a default

I dont think switch is evil

It's not evil. There are maybe one or two occasions a year where it definitely makes sense to use one

I do probably use it too much

There are also more than that many occasions where an interface or base class would have been more appropriate. The most obvious offender is
switch(myObj.myEnumVar) {
    case ONE:
        doOne();
   case TWO:
      doTWO();
etc....
}

An abstract base class with a function do() and a bunch of children that implement it would turn that entire switch into do()