VirtualBox does support using hardware gpu. It requires installing some drivers into the guest os and flicking a switch in the virtual machine options. This should allow for cuda in the guest os. Installing linux to a usb stick, either as a live usb or a real install, is another option.
I was not aware of this, having tried very hard to set it up a few years ago and failing miserably. Can you provide a link to some instructions?
@hardcast_sixdrop, it looks like you are just doing string manipulation with your encoder/decoder. Have you thought about using a dict or object as an intermediary format? It would open up converting the output to all sorts of formats (forums, json, yaml, html, heaven forbid even xml). Could even set it up to recognize and properly handle old nn card formats. I have selfish reasons to request this too
Currently the unscrambler is a total hack and about to be replaced. The encoder (and the future unscrambler) is intended to take either json or any of my encoded formats and produce an internal Card python object that knows everything about the card, and can be used for data analysis or smart reencoding. There is a lot of code hiding in lib/. It mostly works, but everything is still in active development. I'm planning to convert the unscrambler over tonight so there's a more or less fully featured toolchain. Adding the ability to output xml / whatever would be straightforward.
I'm planning to support a few human readable formats for copying onto the forum. If anybody has a recommendation for something more formal (like MSE formats or MTGCardSmith) that would be really cool too. Then we just need to link up another NN to do the art and we can make full visual spoilers automatically.
Ahh I see. Does the dataset duplication have any advantages over just one set?
Well, this is interesting. Let me give a quick explanation of how it works.
When the NN training code reads the data set, before doing anything else, it first partitions it a training set and a validation set. These are totally separate: if you have data in the validation set, you'll never train on it. Ever. Because otherwise it wouldn't be validation data.
The idea behind duplicating the data is that we might want to teach the NN that things are allowed to vary: for example, when randomizing the mana costs we want it to learn that {^RR} and {RR^} are the same thing. So we put in multiple cards that are otherwise identical, but have randomized mana costs. Then it can learn to associate whatever other pattern is in each of those cards with each variation of the mana cost, and hopefully make the connection that the mana costs are equivalent despite the order.
The same idea applies much more to the new format, which allows any ordering of the fields but distinguishes them with label characters. There are about 40k possible orderings for 8 fields, but that's to much data, so I choose 100 at random and call that good enough. The NN will see many cards with the order mixed up but the fields the same, and hopefully learn that the order doesn't matter while the labels do.
But, but, but, this wreaks havoc on the validation process. Since we duplicated the data, the validation set (5% of the data by default) is actually (well, probably, it's random so it could be anything) 5 field-randomized versions of the base dataset, not a subset of the base dataset that we avoided training on. So the validation loss is going to be really low, as observed. I believe it's lower than the training loss because of dropout - I have fairly large dropout, but it doesn't do that for validation. Someone tell me what's actually going on if you know.
There are tradeoffs. On the one hand, we don't really care about validation numbers as long as we get good cards, so this approach is essentially the same as setting the validation set to nothing and just training on as much data as possible. The validation loss is still measuring something though - it tells us how good the network is at figuring out that the order doesn't matter. If it's a perfect student, the validation loss should go to 0. We just have to be careful not to use it as a measure of overfitting - in fact, low validation loss is a pretty good indicator of overfitting.
What exactly defines a batch and sequence length, too? I haven't been able to find good definitions of those. I assume sequence length should be roughly the average character count of a card?
seq_length is how many characters are in a 'batch,' and batch_size is how many batches it trains on in parallel. I don't know if batch_size effects the results of the training or just the speed. Basically what it does is chop the data up into batches of size batch_size * seq_length, and then use those as the units it reports per batch stats like training loss for. I try to use a long seq length to prevent cards from being chopped up, but it doesn't make as big a difference as you might think.
Understanding exactly what the batching code does is probably a valuable endeavor, as it would make the whole data duplication issue go away. What we want is for the batcher to understand that cards are delimited objects, break the data into cards after reading it, partition the card set to get a validation set, then do the duplication and randomization of costs / field orders dynamically as it creates batches of whole cards. I mean to look at this at some point, but I'm not a lua expert so it will take some time. And I really have no idea how the batching code works - it could require the batches to be precisely aligned to make the matrix math it's doing work, which would complicate things.
Why only 2 epochs for the entire training? And why those particular values for batch size and sequence length?
I'm only doing two epochs because the dataset has every card duplicated 100 times in random orders and with randomized field orders. So, it's actually more similar to doing 200 epochs.
Those particular batch and sequence lengths just barely fit in the Titan's RAM. In fact it looks system variation caused it to run out of RAM and crash... Continuing from last checkpoint, hopefully it doesn't happen again.
EDIT: oh, and with that chromebook you'll probably be most limited by the RAM... You could probably fit a size 128 network on there but not a whole lot larger.
Intel i7-3770K @ 4.4GHz
32 GB RAM @ 1866
GeForce GTX Titan, 6GB RAM, EVGA Superclocked Signature edition (it's the very original)
SSD and some 2TB drives in RAID 1 (don't do this on Ubuntu...)
Gigabyte Micro ATX mobo
The Most Hilariously Tiny Case You Ever Saw a Noctua NH-D14 in.
Dual boot Windows 8.1 / Ubuntu 14.04 LTS.
Alright, it's training. Estimated completion time in 23 hours.
I have no idea at all what will happen. The format looks pretty gnarly and isn't very human readable:
|4|7|1energy tap|3{UU}|6|5sorcery|9tap target untapped creature you control. if you do, add {XX} to your mana pool, where X is that creature's converted mana cost.|8
|5creature|3{RR}|9@ attacks each turn if able.\at the beginning of your upkeep, put a +&^/+&^ counter on @. then you may pay {XX}, where X is the number of +&^/+&^ counters on it. if you don't, tap @ and it deals X damage to you.|4|1primordial ooze|8&^/&^|6ooze|7
|3{^^WW}|6human wizard|5creature|9kicker {GG^} and/or {^^UU} \when @ enters the battlefield, if it was kicked with its {^GG} kicker, destroy target creature with flying.\when @ enters the battlefield, if it was kicked with its {^^UU} kicker, draw two cards.|1sunscape battlemage|8&^^/&^^|7|4
|6|1pyroblast|4|9[&^ = uncast target spell if it's blue. = destroy target permanent if it's blue.]|8|5instant|3{RR}|7
I could get rid of the leading '|' characters since the field separators indicate where fields start (I did get rid of the closing one), but this gives the structure a bit more consistency.
My scripts for encoding have gotten much, much better - you should be able to generate this format using the code in my github by tweaking a few command line arguments, no manual hacking of the code necessary. I still have to work on the decoding side, and the documentation. All in good time.
EDIT:
Oh, a thought about Ubuntu. You could try making a live CD / live USB stick, picking the 'try ubuntu' option, installing CUDA and Torch, and training from there. I don't know if that would work or not. I've seen some options for live USBs to keep files / installed software on them, and you should have enough space on like an 8GB usb thumb drive. Of course the disk will be very slow, and I have no idea what Cuda would do if you tried to install it on a live USB... but it could be worth a try.
What new format are you using, and will it be even more awesome?
I have two ideas. The easy one is to use field labels instead of a fixed ordering, then scramble up the fields to get more different cards. Currently I'm making python do the right thing, but once all of the little issues are hammered out it should be as simple as passing a few arguments to my new encoding script and bam, NN input.
The hard idea is to label every line of card text with what it is. Most lines of text on spells are effects like '@ deals 3 damange to target creature or player,' while permanents tend to have passive, active, or triggered abilities. Of course there are also a lot of edge cases like creature keywords: 'flying, trample, deathtouch' is a perfectly valid line, and there's stupid things like convoke and kicker and 'if @ was kicked' and levelers and so on. And even if you know what you want, you still have to write a python script that can figure it out for every card. So, that's a more long-term goal.
The computer's performance only affects how fast it can generate cards, not which ones it generates.
Make sure you haven't set the temperature too low (I almost always use 0.8.). Other than that, the only thing I can say is that usually when we post cards, they've been hand selected from a large batch of mostly uninteresting things. Not every card is exciting. In fact, the cards from the more recent networks might be less exciting in general because the network is better at creating realistic cards, which tend not to be the exciting ones.
Yes, the networks have a very hard time with rare, long distance patterns like kicker, and X. We're working on that. Hopefully I'll be able to kick off some training with a new format tonight so I can provide results from it tomorrow night.
planeswalker's phantasm X
creature ~ elemental
@ enters the battlefield with X +1/+1 counters on it. 3, T, remove a % counter from @: put a 1/1 green saproling creature token onto the battlefield.
10/10
Seems fair... "Hmm, maybe I should wait until turn 2 to play him so I can make more saprolings... Oh wait he needs some other unspecified counter to do that.. eh I'll just cast him now."
@um0123, be careful when seeding my checkpoints that you don't use illegal characters. My networks use all lowercase letters, so if you give it 'Enchantment' it will blow up as soon as it tries to use the capital 'E.'
Do th sample.lua (with no other arguments) to see what arguments the sampling script can take. The important ones are the checkpoint to use (obviously, that's what it samples from) and the temperature and the seed. If you want crazy cards, keep the temperature in the range of 0.7-1.0 or so. The seed is straightforward, if you give it the same seed it will always produce the same output, so you'll want to change it up. The default is not a random seed, but 123, so you actually do have to specify this.
Talcos (the founder of this thread) has an improved sampling script that allows you to insert certain values into the text as it's being generated. It works with my input format / checkpoints. Info on that is scattered over previous pages; here's one reference.
EDIT: Oh, and you can usually get coherent English after at most 10 epochs or so... wait for the losses to come down below about 0.6 or 0.5 and that should be good enough. Training loss should be spewing out in your terminal, and validation loss is part of the name of the checkpoints it saves: lm_lstm_epochxx.xx_0.yyyy.t7, where the ys are the validation loss (hopefully it's less than 1 ).
for the first issue, why did it not output anything? What was I doing wrong?
What maplesmall said is correct. The neural net framework works in two phases: first you have to train the network using train.lua, and this will produce checkpoint files every so often that store the network's parameters. These are saved by default in the folder called cv. Once you've successfully trained and saved a checkpoint, then you can use sample.lua to sample from it, which is what produces that actual output cards that people have been posting.
With only 4GB ram you're going to have a hard time training anything large, but don't worry. As maplesmall suggested, try with rnn_size 128 and see how much memory that's using. If you have some to spare, you might be able to do 256. Small networks can still be interesting.
If you don't want to do your own training (which admittedly is half of the fun anyway) you can also download checkpoints from networks that I've trained here (the things that don't end in .txt). You can also click the 'neural nets' link in my signature to look at other checkpoints and raw output files I've uploaded.
EDIT: Oh, and in totally unrelated news, I've posted the first part of the next major revision of my formatting code on my github. Now that it mostly works, I can start doing some cool stuff with it like randomizing the order of the fields in each card and doing some data analytics on the output.
The NNs definitely have some issues with color. We've actually been experimenting with this a lot lately, by randomizing the order of symbols in the costs and by duplicating the cost before and after the text and seeing if the network can learn that it should be correctly duplicated. I'd recommend the checkpoints in here to take advantage of this; these ones do pretty well at the 'can you remember the cost' test while previous attempts were hilariously bad at it. There's a bunch of discussion of this in previous pages, I'd link you to it but I'm lazy and it's getting late.
And yes, I know my mana format is a little weird, but there are reasons for it. I couldn't think of a better way to do the encoding for annoying multi-part mana symbols without adding lots of additional characters to the language, and that has the issue that it makes the relationship between colored and hybrid symbols more opaque. So each actual mana glyph is a 2-letter object, with a single unary counter character marking each colorless mana. So, indeed, {^^^^UUR} is NOT a valid mana cost (though {^} is, and means 1). I've never seen the network produce a single invalid one, except for the cases where it got carried away with the unary counter and forgot to add the closing '}' on the end...
Speaking of that, you should be warned that low temperatures don't seem to interact well with my checkpoints. I do most of my sampling at 0.8. As with most things there isn't a lot of science behind this, just anecdotal experience, so if you try lots of other things and share the results we'd be grateful.
Yep, it seems to start over. It's not really inefficient, because it is still using all of the parameters as learned for the checkpoint you initialized from. So the effective epoch is whatever it says plus what you started from.
This can cause all kinds of issues, because if you don't lower the number of epochs it'll train more than you initially intended, and as far as I know it resets stuff like the learning rate, which is supposed to decay over time. You can use inspect_checkpoint.lua (I think that's what it's called) to look at all of the saved checkpoint's parameters. In principle you can make it all work by changing other command line options to compensate, but it's more trouble than I'm usually willing to put up with.
I was not aware of this, having tried very hard to set it up a few years ago and failing miserably. Can you provide a link to some instructions?
Currently the unscrambler is a total hack and about to be replaced. The encoder (and the future unscrambler) is intended to take either json or any of my encoded formats and produce an internal Card python object that knows everything about the card, and can be used for data analysis or smart reencoding. There is a lot of code hiding in lib/. It mostly works, but everything is still in active development. I'm planning to convert the unscrambler over tonight so there's a more or less fully featured toolchain. Adding the ability to output xml / whatever would be straightforward.
I'm planning to support a few human readable formats for copying onto the forum. If anybody has a recommendation for something more formal (like MSE formats or MTGCardSmith) that would be really cool too. Then we just need to link up another NN to do the art and we can make full visual spoilers automatically.
Well, this is interesting. Let me give a quick explanation of how it works.
When the NN training code reads the data set, before doing anything else, it first partitions it a training set and a validation set. These are totally separate: if you have data in the validation set, you'll never train on it. Ever. Because otherwise it wouldn't be validation data.
The idea behind duplicating the data is that we might want to teach the NN that things are allowed to vary: for example, when randomizing the mana costs we want it to learn that {^RR} and {RR^} are the same thing. So we put in multiple cards that are otherwise identical, but have randomized mana costs. Then it can learn to associate whatever other pattern is in each of those cards with each variation of the mana cost, and hopefully make the connection that the mana costs are equivalent despite the order.
The same idea applies much more to the new format, which allows any ordering of the fields but distinguishes them with label characters. There are about 40k possible orderings for 8 fields, but that's to much data, so I choose 100 at random and call that good enough. The NN will see many cards with the order mixed up but the fields the same, and hopefully learn that the order doesn't matter while the labels do.
But, but, but, this wreaks havoc on the validation process. Since we duplicated the data, the validation set (5% of the data by default) is actually (well, probably, it's random so it could be anything) 5 field-randomized versions of the base dataset, not a subset of the base dataset that we avoided training on. So the validation loss is going to be really low, as observed. I believe it's lower than the training loss because of dropout - I have fairly large dropout, but it doesn't do that for validation. Someone tell me what's actually going on if you know.
There are tradeoffs. On the one hand, we don't really care about validation numbers as long as we get good cards, so this approach is essentially the same as setting the validation set to nothing and just training on as much data as possible. The validation loss is still measuring something though - it tells us how good the network is at figuring out that the order doesn't matter. If it's a perfect student, the validation loss should go to 0. We just have to be careful not to use it as a measure of overfitting - in fact, low validation loss is a pretty good indicator of overfitting.
seq_length is how many characters are in a 'batch,' and batch_size is how many batches it trains on in parallel. I don't know if batch_size effects the results of the training or just the speed. Basically what it does is chop the data up into batches of size batch_size * seq_length, and then use those as the units it reports per batch stats like training loss for. I try to use a long seq length to prevent cards from being chopped up, but it doesn't make as big a difference as you might think.
Understanding exactly what the batching code does is probably a valuable endeavor, as it would make the whole data duplication issue go away. What we want is for the batcher to understand that cards are delimited objects, break the data into cards after reading it, partition the card set to get a validation set, then do the duplication and randomization of costs / field orders dynamically as it creates batches of whole cards. I mean to look at this at some point, but I'm not a lua expert so it will take some time. And I really have no idea how the batching code works - it could require the batches to be precisely aligned to make the matrix math it's doing work, which would complicate things.
I'm only doing two epochs because the dataset has every card duplicated 100 times in random orders and with randomized field orders. So, it's actually more similar to doing 200 epochs.
Those particular batch and sequence lengths just barely fit in the Titan's RAM. In fact it looks system variation caused it to run out of RAM and crash... Continuing from last checkpoint, hopefully it doesn't happen again.
EDIT: oh, and with that chromebook you'll probably be most limited by the RAM... You could probably fit a size 128 network on there but not a whole lot larger.
32 GB RAM @ 1866
GeForce GTX Titan, 6GB RAM, EVGA Superclocked Signature edition (it's the very original)
SSD and some 2TB drives in RAID 1 (don't do this on Ubuntu...)
Gigabyte Micro ATX mobo
The Most Hilariously Tiny Case You Ever Saw a Noctua NH-D14 in.
Dual boot Windows 8.1 / Ubuntu 14.04 LTS.
I have no idea at all what will happen. The format looks pretty gnarly and isn't very human readable:
|4|7|1energy tap|3{UU}|6|5sorcery|9tap target untapped creature you control. if you do, add {XX} to your mana pool, where X is that creature's converted mana cost.|8 |5creature|3{RR}|9@ attacks each turn if able.\at the beginning of your upkeep, put a +&^/+&^ counter on @. then you may pay {XX}, where X is the number of +&^/+&^ counters on it. if you don't, tap @ and it deals X damage to you.|4|1primordial ooze|8&^/&^|6ooze|7 |3{^^WW}|6human wizard|5creature|9kicker {GG^} and/or {^^UU} \when @ enters the battlefield, if it was kicked with its {^GG} kicker, destroy target creature with flying.\when @ enters the battlefield, if it was kicked with its {^^UU} kicker, draw two cards.|1sunscape battlemage|8&^^/&^^|7|4 |6|1pyroblast|4|9[&^ = uncast target spell if it's blue. = destroy target permanent if it's blue.]|8|5instant|3{RR}|7I could get rid of the leading '|' characters since the field separators indicate where fields start (I did get rid of the closing one), but this gives the structure a bit more consistency.
My scripts for encoding have gotten much, much better - you should be able to generate this format using the code in my github by tweaking a few command line arguments, no manual hacking of the code necessary. I still have to work on the decoding side, and the documentation. All in good time.
EDIT:
Oh, a thought about Ubuntu. You could try making a live CD / live USB stick, picking the 'try ubuntu' option, installing CUDA and Torch, and training from there. I don't know if that would work or not. I've seen some options for live USBs to keep files / installed software on them, and you should have enough space on like an 8GB usb thumb drive. Of course the disk will be very slow, and I have no idea what Cuda would do if you tried to install it on a live USB... but it could be worth a try.
I have two ideas. The easy one is to use field labels instead of a fixed ordering, then scramble up the fields to get more different cards. Currently I'm making python do the right thing, but once all of the little issues are hammered out it should be as simple as passing a few arguments to my new encoding script and bam, NN input.
The hard idea is to label every line of card text with what it is. Most lines of text on spells are effects like '@ deals 3 damange to target creature or player,' while permanents tend to have passive, active, or triggered abilities. Of course there are also a lot of edge cases like creature keywords: 'flying, trample, deathtouch' is a perfectly valid line, and there's stupid things like convoke and kicker and 'if @ was kicked' and levelers and so on. And even if you know what you want, you still have to write a python script that can figure it out for every card. So, that's a more long-term goal.
very untrained mostly trained fully trained
Make sure you haven't set the temperature too low (I almost always use 0.8.). Other than that, the only thing I can say is that usually when we post cards, they've been hand selected from a large batch of mostly uninteresting things. Not every card is exciting. In fact, the cards from the more recent networks might be less exciting in general because the network is better at creating realistic cards, which tend not to be the exciting ones.
Yes, the networks have a very hard time with rare, long distance patterns like kicker, and X. We're working on that. Hopefully I'll be able to kick off some training with a new format tonight so I can provide results from it tomorrow night.
Seems fair... "Hmm, maybe I should wait until turn 2 to play him so I can make more saprolings... Oh wait he needs some other unspecified counter to do that.. eh I'll just cast him now."
@um0123, be careful when seeding my checkpoints that you don't use illegal characters. My networks use all lowercase letters, so if you give it 'Enchantment' it will blow up as soon as it tries to use the capital 'E.'
Talcos (the founder of this thread) has an improved sampling script that allows you to insert certain values into the text as it's being generated. It works with my input format / checkpoints. Info on that is scattered over previous pages; here's one reference.
EDIT: Oh, and you can usually get coherent English after at most 10 epochs or so... wait for the losses to come down below about 0.6 or 0.5 and that should be good enough. Training loss should be spewing out in your terminal, and validation loss is part of the name of the checkpoints it saves: lm_lstm_epochxx.xx_0.yyyy.t7, where the ys are the validation loss (hopefully it's less than 1
What maplesmall said is correct. The neural net framework works in two phases: first you have to train the network using train.lua, and this will produce checkpoint files every so often that store the network's parameters. These are saved by default in the folder called cv. Once you've successfully trained and saved a checkpoint, then you can use sample.lua to sample from it, which is what produces that actual output cards that people have been posting.
With only 4GB ram you're going to have a hard time training anything large, but don't worry. As maplesmall suggested, try with rnn_size 128 and see how much memory that's using. If you have some to spare, you might be able to do 256. Small networks can still be interesting.
If you don't want to do your own training (which admittedly is half of the fun anyway) you can also download checkpoints from networks that I've trained here (the things that don't end in .txt). You can also click the 'neural nets' link in my signature to look at other checkpoints and raw output files I've uploaded.
EDIT: Oh, and in totally unrelated news, I've posted the first part of the next major revision of my formatting code on my github. Now that it mostly works, I can start doing some cool stuff with it like randomizing the order of the fields in each card and doing some data analytics on the output.
And yes, I know my mana format is a little weird, but there are reasons for it. I couldn't think of a better way to do the encoding for annoying multi-part mana symbols without adding lots of additional characters to the language, and that has the issue that it makes the relationship between colored and hybrid symbols more opaque. So each actual mana glyph is a 2-letter object, with a single unary counter character marking each colorless mana. So, indeed, {^^^^UUR} is NOT a valid mana cost (though {^} is, and means 1). I've never seen the network produce a single invalid one, except for the cases where it got carried away with the unary counter and forgot to add the closing '}' on the end...
Speaking of that, you should be warned that low temperatures don't seem to interact well with my checkpoints. I do most of my sampling at 0.8. As with most things there isn't a lot of science behind this, just anecdotal experience, so if you try lots of other things and share the results we'd be grateful.
This can cause all kinds of issues, because if you don't lower the number of epochs it'll train more than you initially intended, and as far as I know it resets stuff like the learning rate, which is supposed to decay over time. You can use inspect_checkpoint.lua (I think that's what it's called) to look at all of the saved checkpoint's parameters. In principle you can make it all work by changing other command line options to compensate, but it's more trouble than I'm usually willing to put up with.