After the Planeswalker deck exclusive cards, Gatherer lists the remaining 8 enters-the-battlefield-tapped common dual lands as cards 280-287. Presumably this was to keep them in standard with the original rotation plan. Do we know if these cards will be in the Amonkhet Bundle (fat pack) or somewhere else? Or is their appearance in the set an error on WotC's part? They are not listed in the number crunch and I haven't seen any other discussion of this.
Logically, the deck is likely shuffled and kept in that order until it is reshuffled. Consider that in Magic it is common to put cards back on top of library, to reorder top cards and to put cards on the bottom. It makes little sense to implement on-demand randomness for the unknown part of the deck while tracking the positions of known cards in the deck throughout the game. It is highly likely that the order is decided by every shuffle action.
When you search your library, it is probably just providing you a conveniently sorted view (since it is about to reshuffle the library anyway).
This approach is hinted to in an early post about the MTGO shuffler from Chris Green of Leaping Lizard Software (the original MTGO developers):
MTGO's Shuffle Algorithm...get the technical low down...
March 15, 2002
by Chris Green
A technical description of Magic Online's shuffler and random number generator.
The core random number generator used is "Algorithm A", from Knuth's "Art of Computer Programming", sec 3.2.2. This is a fast, easy to implement random number generator. Knuth states that it has "consistently produced reliable results, in extensive tests since its invention in 1958."
I first implemented this generator in 6502 assembly code in 1981 or so, and it has never failed me.
The implementation of this generator used in our libraries uses the standard constants (24,55). Because this is somewhat fewer than the number of bits required to produce all possible hands, it was augmented with another generator using the constants (33,68). This yields a total state size of 3936 bits. Both generators were combined so that the random number calls used in our library could still return the same sequence of numbers when initiated by our old programs (never know when we might have to rebuild a new version of Centipede3D for the Dreamcast ).
In MTGO, random numbers are initialized by the game servers. When a new game is started, the random number state is seeded via /dev/random, which uses hardware delays for a source of true random data. In addition, whenever a packet is received from a user by the game server, the lower order bits of the system CPU's clock cycle counter are added into the random state.
Shuffling is performed by swapping every card in the deck with a random other card in the deck. This is algorithm "P" for shuffling from Knuth. The book contains a formal analysis of its randomness. The 32 bit random values returned by the basic random number function are mapped into the appropriate range by fixed point multiplication.
One of our programmers, Sergey, was not satisfied that the random number generator wasn't mana-screwing him, and so performed the following test:
The shuffler has no idea what is a land and is not a land, so if there is any unnatural clumping of lands, it must be based upon the initial ordering of the deck. So he performed the following test:
Create in memory a virtual deck of 20 "1"s, representing lands, and 40 "0"s representing non-lands. Put all the "lands" first and then all the "nonlands". Apply the shuffler.
Perform the same test, except with lands and nonlands interleaved before shuffling.
Perform each test multiple millions of times. After each test, count the sizes of land/non-land clusters and keep a running total of each.
Compare the results from the millions of runs with the deck ordered with all lands together versus the interleaved one. The results were the same to within a minuscule fraction of a percent.
In addition, he wished to verify that shuffling extra times would have no effect. If it did have an effect that would mean that the shuffle was insufficiently random. He performed this test and got the same statistics from one shuffle as from many.
I have been experimenting with this as part of something I am creating and it works very well - thanks! One thing I was wondering is what is the proper way to search by name (either in PTK or C13)
I also fixed a multiverseid lookup issue for 'planes' and 'schemes'. Those now work correctly.
Thanks Sembiance, awesome work!
The only other multiverseId lookup issue is that with some split cards (from Invasion and Apocalypse) on Gatherer have the halves listed with separate multiverseIds, i.e., Wax is 20581 and Wane is 20582. The lower multiverseId for each card currently fails to return a card image on mtgimage.com. It would be great if you could have the missing IDs below act as aliases for the existing multiverseId you are using for each of these ten cards:
20579 Assault / Battery (Invasion)
27165 Fire / Ice (Apocalypse)
27163 Illusion / Reality (Apocalypse)
27161 Life / Death (Apocalypse)
26276 Night / Day (Apocalypse)
27167 Order / Chaos (Apocalypse)
20577 Pain / Suffering (Invasion)
20575 Spite / Malice (Invasion)
20573 Stand / Deliver (Invasion)
20581 Wax / Wane (Invasion)
My MTG Trades app does exactly what you ask, at least for iOS.
It has an offline database, that can be updated weekly, e.g., before FNM, and then you can use it offline.
You can also evaluate trades (current value and value at time of trade) and track want lists and loaned cards. These all get updated prices once you update the database or view once you are back with a connection.
How did you find out these differences? Can you somehow compare the old and new versions of the database? We haven't already received the Rules & Oracle Update Bulletin, in which these things are officially announced, have we?
280 - Cinder Barrens
281 - Forsaken Sanctuary
282 - Highland Lake
283 - Meandering River
284 - Submerged Boneyard
285 - Timber Gorge
286 - Tranquil Expanse
287 - Woodland Stream
When you search your library, it is probably just providing you a conveniently sorted view (since it is about to reshuffle the library anyway).
This approach is hinted to in an early post about the MTGO shuffler from Chris Green of Leaping Lizard Software (the original MTGO developers):
http://mtgimage.com/set/PTK/Kongming,%20%22Sleeping%20Dragon%22.jpg
Thank you, sir!
Thanks Sembiance, awesome work!
The only other multiverseId lookup issue is that with some split cards (from Invasion and Apocalypse) on Gatherer have the halves listed with separate multiverseIds, i.e., Wax is 20581 and Wane is 20582. The lower multiverseId for each card currently fails to return a card image on mtgimage.com. It would be great if you could have the missing IDs below act as aliases for the existing multiverseId you are using for each of these ten cards:
20579 Assault / Battery (Invasion)
27165 Fire / Ice (Apocalypse)
27163 Illusion / Reality (Apocalypse)
27161 Life / Death (Apocalypse)
26276 Night / Day (Apocalypse)
27167 Order / Chaos (Apocalypse)
20577 Pain / Suffering (Invasion)
20575 Spite / Malice (Invasion)
20573 Stand / Deliver (Invasion)
20581 Wax / Wane (Invasion)
My MTG Trades app does exactly what you ask, at least for iOS.
It has an offline database, that can be updated weekly, e.g., before FNM, and then you can use it offline.
You can also evaluate trades (current value and value at time of trade) and track want lists and loaned cards. These all get updated prices once you update the database or view once you are back with a connection.
PM if you have any questions about the app.
Michael
You can find a list of all the errors here:
http://www.mtgapps.com/2013/01/possible-errors-in-gatecrash-oracle-update/
I let the rules manager, Matt Tabak, know yesterday via twitter. He responded with:
He also replied to my tweet an said: "Indeed. We'll investigate later today."
Hasn't been fixed yet.