Player is not evolvable. Use a subclass of EvolvablePlayer.

[erenarkangil]

Hi,

I would like to see how non-evolvable strategies behave in moran process compared to evolvable ones, however when i try to give players array in a mixed way i got this error. Is there a way to create such an environment?

many thanks

[marcharper]

Can you paste your code here? My guess is that you need to use the right type of mutation, only the "atomic" type should require an EvolveablePlayer.

[erenarkangil]

Of course, i'm adding it with the error as screenshot

[marcharper]

A few issues:

• axl.Cooperator and axl.Defector need to be initialized axl.Cooperator() and axl.Defector()
• the mutation type has to be set to atomic. See the docs here
• EvolvablePlayer is a generic abstract base class with no real functionality. You'll need to choose a specific one like the EvolvableFSMPlayer
• I'm actually not sure that the code supports mixing of evolvable and non-evolvable players. It's not an unreasonable thing to want to do but the necessary no-op functions on the non-evolvable players may not be present.

[erenarkangil]

Hi Marc,

Now i am getting ''TypeError: Player is not evolvable. Use a subclass of EvolvablePlayer.''.

code:

C = axl.Action.C #player1=axl.Defector i cant give a player as argument below :( ev1=axl.EvolvableFSMPlayer(num_states=1,initial_state=0, initial_action=C) playerswithevolable=[] playerswithevolable.append(ev1) playerswithevolable.append(axl.Defector()) playerswithevolable.append(axl.Cooperator())

mpE = axl.MoranProcess(playerswithevolable,mutation_method="atomic") populations = mpE.play() populations

---

error:

[marcharper]

That's what I expected. @drvinceknight any thoughts? Maybe we could have some kind of wrapper / transformer that makes any player generically evolvable in a trivial way for cases like this.

[drvinceknight]

Sorry for taking so long to get back to you on this.

I like your suggestion @marcharper, a wrapper that allows player to evolve in a trivial sounds good. Would another approach be to add an evolve method to the base player class that does not do anything?

[marcharper]

I like your suggestion @marcharper, a wrapper that allows player to evolve in a trivial sounds good. Would another approach be to add an evolve method to the base player class that does not do anything?

Yes we could also do that, but then it removes the distinction between Player and EvolvablePlayer. Maybe that's a good idea but I'm not sure (for testing purposes at least).

[drvinceknight]

I'm not sure (for testing purposes at least).

I hear you. It's two options, whatever your hunch tells you is fine by me.

[marcharper]

Post #1288 I'm thinking that it's better to make all Players evolvable, if only to remove multiple inheritance from the Player classes hierarchy. I'm not sure we actually gain much by having both Players and EvolvablePlayers other than the bit that a Player is evolvable, which could more easily handled by a classifier instead.