The seemingly controversial topic received some interesting comments. Due to certain fallacies introduced by a commenter, I thought I should clarify those points for the benefit of any reader who might become confused after reading his comments. My reply got a little too long, so I am posting it here.

Permutations
pantelis wrote:
“if you have 2 objects there are 2 possible arrangements of them. If you have 3 there are 6 and if you have 52 there are 52! (1*2*3*…*52). So, the probability of a particular hand (consisting of 52 cards) is 1/52! According to your math the probability of a given sequence is (1/52)^52 which means that there are 52^52 possible arrangements. and that is simply wrong.”

pantelis wrote:
“your math is wrong. i already gave you a counter proof of that: 52 items can be arranged in 52! ways. this is a fact of life, ever since pascal, bernoulli, and poisson (and their gambling habits) have founded statistics. therefore, the probability of one particular hand (it doesn’t matter which) is 1/52! your math results in (1/52)^52.”

Actually, my math results in 51!.

I never quite understood how pantelis arrived at the 52^52 permutations (he was reminded about “remaining cards” and he seems to understand the concept of “drawing without replacement”).

When you shuffle an array of 52 items, the number of ways they can be arranged is 52!.

When you randomly select and remove one item from an array until all items have been removed, the number of ways that the items can be arranged is still 52!.

When you randomly select an item from an array without removing it for the next selection, then for a sequence of 52 picks, there are 52^52 permutations.

In any case, for our discussion on “shuffle and draw from top” vs “random pick on demand”, the number of permutations does not really matter. It is the distribution of probabilities for each card that matters.

Probabilities
pantelis wrote:
“we agree that the probability of a particular card be drawn first is 1/52. after the first card is drawn, there is no such thing as “for a card to be drawn as the second card, it must not be drawn as the first card – got that? The chance of that happening is 98.08% (51/52)”. pardon me, but, i haven’t got that.”

pantelis wrote:
“the probability of a particular card to be drawn second is equal to 1/51, because there is only one favorable outcome (that particular card) and 51 possible outcomes, to be drawn third is 1/50 and so on.”

That is where pantelis went wrong. That is exactly the misconception I highlighted in the original post. It is wrong to think that if you randomly pick and remove a card from a deck of 52 cards, the distribution of probabilities will be skewed.

Consider an example.

The probability of a certain card, say Ace of Spades, being drawn as the third card is the compounded probability of three events that MUST occur:
(i) Aces of Spades NOT being drawn as first card (51/52 chance); and
(i) Aces of Spades NOT being drawn as second card (50/51 chance); and
(ii) Aces of Spades bring drawn as third card (1/50 chance).

Therefore, the chance of a particular card (eg. Ace of Spades) being drawn as the third card is
51/52 x 50/51 x 1/50 = 1/52.

pantelis wrote:
“after the first card is drawn the probability of the second card not been drawn as the first card is 1 (because we are certain that the second card was not drawn first).”

That is a bad twist of words resulting in the wrong framing of the problem at hand, which led to the wrong math. We are interested in the probability of “a particular card not being drawn as the first card”, not “the second card not being drawn as the first card”.

pantelis wrote:
“according to your logic the probability of a particular card been drawn first, second, or last is 1/52… “

Yes, that is exactly what I am saying.

The distribution of probabilities for each card must be statistically fair, and it is. Whether you shuffle the deck and draw the cards sequentially, or you pick a card at random each time, the distribution of the probabilities remain the same.

Consider the following scenarios:
(i) You take a fresh deck of 52 cards, shuffle it, draw 2 cards from the top of the deck and discard them. What is the chance of the next card drawn (ie 3rd card) from the top of the deck to be Ace of Spades?

(ii) You take a fresh deck of 52 cards, shuffle it, draw 1 card from the top of the deck and discard it. Shuffle the deck again, draw another card from the top of the deck and discard it. Shuffle the deck again. What is the chance of the next card drawn from the top of the deck to be Ace of Spades?

(iii) You take a fresh deck of 52 cards. Now, don’t shuffle it. Let’s ask Paul the Octopus, who is completely innocent and ignorant of the way a fresh deck of cards is prearranged, to truly randomly pick one card from the deck and discard it. Ask him/it to do it again a second time, also completely randomly without bias. What is the chance of the third card Paul picks, truly randomly without bias, from the deck of remaining cards to be Ace of Spades?

The answer: 1/52. Same for (i), (ii) and (iii).

Now, do the above again, this time revealing the cards as they are drawn. Assuming that neither the first nor second card is Ace of Spades, what is the chance that the third card would be Ace of Spades?

The answer: 1/50. Unlike in (i), (ii) and (iii), there is a stipulated condition here that Ace of Spades is not picked as the 1st or 2nd card.

As the above shows, whether you shuffle a deck and then draw from the top, or pick cards at random, or shuffle and reshuffle multiple times, the probability of a particular card being drawn at a particular position remains the same.

I hope that clears things up about permutations and probabilities.

Psychology
jason wrote:
“When shuffling a deck (or multiple decks) of cards in the “real” world (ok, so we don’t live in the Matrix), once the cards are shuffled they stay in that order until they’re dealt (or reshuffled). So randomly picking a card at deal-time does not actually maintain the “reality” of shuffling prior to dealing any cards, though it nets a similar result. Ultimately, I’d agree there’s no serious issue with this, but…it feels “righter” to me to go the pre-shuffle route.”

jason brought up a completely valid point – one of psychological barrier. People get so caught up with “shuffling”, that they forgot the real purpose behind it. It “feels” right to go the shuffle route only because that is what we do in the non-digital world.

The reason behind the “shuffle” in non-digital games is to introduce randomness. There was no other way. Computers can implement their own randomizers, thus my question for the need for a shuffle. I will also debate that the way computer shuffles an array of cards typically does not maintain the “reality” too, because the algorithm will not accurately simulate shuffling by hand.

Does it really matter for cards to stay in a predefined order? It only serves to give players a false sense of fairness where distribution of “luck” is concerned. It only matters to players who superstitiously believes that shuffling the deck changes the distribution of luck for a given round of game. When a deck is shuffled, players believe that their “luck” is fixed for that round of game. However, where probabilities are concerned, they remain the same.

The order of the cards will matter to players who can somehow see the sequence of the cards. But that is akin to hackers who employ memory inspection to see the sequence of a shuffled deck (another reason for not doing shuffles in software).

The only time having cards stay in a predefined order will be for situations where the sequence of the cards is revealed. But that is also equivalent to picking one card randomly until all cards are drawn and revealed.

I agree that the psychological barrier can be tough to crack. After all, most people do not define “luck” as “the probability of achieving a favorable outcome”.

However, the mental beast is one that can be tamed and re-programmed. In the past, dealers in casinos used to shuffle by hand. Nowadays, (continuous) shuffling machines are used. The human touch is missing (where is the “cut” which some gamblers believe affects the distribution of luck?), but it has not affected the traffic. Patrons have been re-programmed to accept the new system. Likewise for slot machines, the game has been digitized and degenerated to simple presses of a button rather than the pulling of levers. These changes have warped “reality” and have actually made games run faster (and casinos make more money running more games per minute).

The “reality” has changed, only because mindsets have.

The purpose of this post, however, is not to discuss “how” to shuffle arrays. Rather, I would like to bring up the question of “why” (do it) in the first place.

In the non-digital world, the shuffling of a deck of cards is mostly necessary given the circumstances – ie, for convenience. In a card game, you shuffle the deck of cards to randomize the order of the cards, and players draw from the top (or bottom) of the deck in sequence. Why do players draw from the top (or bottom) of the deck? For practical reasons, of course. Convenience.

Imagine a card game where the game designer decides that players must pick a card randomly from the deck each time they need to draw a card – the game will end up taking too long to play, drawing cards become tedious, and the game won’t be very popular.

In both methods of card drawing, the outcome is really the same – whether you (i) shuffle a deck of cards and then draw from the top of the deck sequentially, or (ii) leave a deck as it is and then randomly pick a card from the deck each time you need to draw a card, the probability of a particular card being drawn by a player is exactly the same. Let’s take a look at a deck of 52 cards. If you shuffle the deck rigorously, the chance of a card being positioned at the location it is shuffled into, and therefore being drawn at that particular position, is 1.92% (1/52).

Now, look at the other scenario. Leave the deck as it is without shuffling. When a player randomly picks a card from the deck, the probability of picking a particular card as the first card remains at 1.92% (1/52). What is the probability of a particular card to be drawn as the second card? A common misconception is that with less cards left, the probability for subsequent cards are now skewed. Not really. Let’s look at the calculations. First, for a card to be drawn as the second card, it must not be drawn as the first card – got that? The chance of that happening is 98.08% (51/52). Next, the chance of the card being drawn as the second card in the reduced deck of 51 cards is 1.96% (1/51). The composite probability is… 51/52 x 1/51 = 1/52, which is still 1.92%! You can go on to compute for the third card, which is 51/52 x 50/51 x 1/50 = 1/52, and so on.

Okay, we have established that the probability remains the same for both methods of card drawing. So what?

Well, when it comes to programming, I would debate that it is unnecessary to shuffle a deck of cards. Players no longer need the convenience here, so why not pick a card at random each time you need to draw a card? This approach has a couple of advantages:

(i) Preempt cheating by memory peeking. If you use a shuffled deck, you naturally store the sequence in memory, which means hackers can potentially look at the sequence. If you generate a random number on demand, picking a card at random each time a card is to be drawn, nobody can have fore-knowledge of what is to come.

(ii) Fast. You can jump right into a game session without expensive CPU overhead for shuffling arrays. If you have a large deck, shuffling can be inefficient no matter which algorithm you use. Instead of shuffling the deck, you just write the code to pick a card randomly from the remaining deck. Hassle in the non-digital world, fast in the digital version.

// ActionScript 3.0
function drawNext(deck:Array):*
{
	var j:uint = deck.length;
	var r:uint = Math.random() * j;
	var c:* = deck[r];
	deck.splice(r, 1); // removes item from array
	return c;
}

Therefore, when translating a non-digital game into a digital one, take a step back and ponder over whether it is really necessary to implement the rules literally. As long as the intended outcome (in this case the intended probability of each card being drawn at a certain position) is the same, it would probably be worthwhile exploring more efficient implementations.

To get the tracer to work:

1) Go to Tools -> Program Settings (F10).

2) In the Plugins list on the left of the dialog box, look for FlashLogViewer and click on it.

3) On the right panel, look for the “Start Tracking” property, click on the drop down box and select “OnBuildComplete” (it is set to “Manually” by default).

The output of your trace statements are now shown in the Output Panel after you build your project.

On the Mac, I have lost much work and time due to the Mac OSX intrusively restarting on its own. Drafts not saved? Say farewell – lost forever. Downloads disrupted – start over (unless resume miraculously works). This is especially exasperating, considering that Apple requires you to update the iPhone SDK/Xcode by re-downloading the whole package. Not patching, but re-downloading a 2GB+ file.

So, why exactly is the Mac restarting on its own, even when it is not idle such as having a download-in-progress?

Turns out that this is due to a rather useless Security feature. Ridiculously, the “Log out after 30 minutes of inactivity” setting is the culprit. So, to save yourself some agony, make sure you turn it off:

If your Mac has been suffering from this problem, hope the above helps!

Seriously, I have no idea what purpose this Security feature serves, other than to make you lose progress in your work. By comparison, on Windows, if the OS logs you out due to inactivity, it actually restores your session with your work-in-progress intact the next time you log in. You can even safely switch between user accounts on Windows, and log back into an account with its last session intact.

P/S: As far as security goes, you should just check the “Require password” option.

In order to load images from a different domain, the Flash Player will need to read a crossdomain.xml file from the foreign domain (and this file must grant permission to your domain to access the required resources). Typically, you would expect to need to specify a checkPolicyFile property somewhere. In the case of the uiImage component, there is no checkPolicyFile property to set because this would be unnecessary.

In order to load an image from a foreign domain, you would specify the source with a “url:http://” prefix. This prefix is sufficient to let the component know that you are loading from a foreign domain (you would omit the http:// otherwise).

Internally, the uiImage component sets the checkPolicyFile property automatically, as necessary. The rationale here is that, since the flag must always be TRUE for Flash applications deployed over the web (sandboxType is Security.REMOTE) whenever the Flash Player attempts to load resources from foreign domains, we might as well have the component set this automatically rather than having to expose a superfluous API. To be very clear, the checkPolicyFile flag is FALSE by default – the policy file is checked only if the application is deployed over the web (ie application’s sandboxType is Security.REMOTE), because checking the policy file is unnecessary when deployed on the desktop.

I have finally disabled Spaces on Mac OSX. It’s a little painful to disable it, because I had considered it a very crucial feature, considering that without it the desktop gets cluttered quickly with the way the Mac OS presents applications and their respective windows (all mixed together in one very confusing bucket). However, the slide animation that occurs every time Spaces switches from one space to another has become really nauseating.

It was cool at first, but now it is painful to watch.

So much for Apple’s acclaimed emphasis on the “user experience”. Does nobody in the UX team ever stop to think that not everyone likes gimmicky animation stuff for frequent tasks, and there should be an easy way to disable such animations? Unfortunately, there is just no way to disable the animations – I hope to be proven wrong, but my searches have come up fruitless. A quick google visit shows there are other users who wish to get rid of the animation too (and apparently I am not the only one suffering from motion sickness, although most simply want to get rid of the animation just to save time, keeping multitasking slick and snappy).

So, now that I have disabled Spaces, what do I do now with the cluttered desktop? I am currently solving the issue with a little AppleScript and implementation of keyboard shortcuts via Spark – a free utility to create Hot Keys to launch applications and documents, execute AppleScript, etc.

First, you can use simple AppleScript to hide all other applications except the one you are working on:

tell application "Finder"
	set visible of every process whose visible is true and frontmost is not true to false
end tell

If you are already using a Hot Key utility to execute other AppleScript, you already know the routine. If not, you can download Spark, launch it, and then assign the above AppleScript to a keyboard shortcut.

(click on the Shortcut input field and then type the keyboard shortcut to assign the Hot Key)

With the above, F1 has been assigned as the Hot Key – pressing F1 when any application has focus will hide all other windows except the currently active application (or in AppleScript’s terminology, “frontmost” application).

But that only got rid of the clutter, albeit momentarily (as the clutter builds up, I hit F1 again).

What about jumping around applications? That was what Spaces allowed me to do, and now I need to replicate that functionality. Luckily, it is easy enough to do that with Spark. You can once again write AppleScript, such as the following:

tell application "Finder"
	set visible of every process to false
end tell
 
tell application "Xcode"
	activate
	set visible to true
end tell

However, you don’t even need to do that – Spark allows you to assign Hot Keys to Applications, so let’s do that:

As you can see, the above assigns Command-F1 to Xcode, and Command-F2 to Firefox. With that set up, when you are in another application, hitting Command-F1 will jump to Xcode immediately. If Xcode is not yet launched, it will automatically launch first. Spark also provides the options for hiding all applications when your desired program is launched:

So, that is that. A little manual work to assign frequently used applications to Hot Keys. But at least it no longer gets dizzy working on Mac OSX now.

A GroupBox displays a border/frame around a group of controls, with or without a caption/title. This is typically done to provide visual feedback to end-users that a collection of controls on a form is logically grouped.

When using the Aspire UI toolkit in ActionScript 3.0 projects, you can use the uiFrame component for the same results.

// ActionScript 3.0
var fruit0:uiCheckBox = new uiCheckBox("Apple");
var fruit1:uiCheckBox = new uiCheckBox("Banana");
var fruit2:uiCheckBox = new uiCheckBox("Orange");
 
var fruitsBox:uiBox    = new uiBox();
fruitsBox.vertical    = true;
fruitsBox.spacing    = 4;
 
fruitsBox.addChild(new uiText("You can choose one or more fruits!"));
fruitsBox.addChild(fruit0);
fruitsBox.addChild(fruit1);
fruitsBox.addChild(fruit2);
 
var frm:uiFrame = new uiFrame();
frm.content = fruitsBox;
frm.x = 10;
frm.y = 10;
 
frm.title = new uiText("Fruits");
 
addChild(frm);

Using the “graylic” theme, the result would be as follows:

Notice that the caption (title) is left aligned by default. You can adjust the alignment by specifying the alignX property:

frm.title = new uiText("Fruits");
frm.title.alignX = ALIGN.CENTER;

Using the “classic” theme with background set to gray, the result would be as follows:

Aspire UI Components
Aspire UI is a library of Actionscript 3.0 (AS3) classes for building flexible and lightweight UI elements in Adobe Flash applications. Key features of the components include easy skinning using PNG image files, automatic tab focus ordering, CSS text styles, and layout management.

This is a pure AS3 library with no dependency on the Flex framework.

For more information, please click here.

You may experiment with the various features by downloading the trial version.

By default, the component uses the following set of colors:

We can define an alternative colors array for the popup palette:

private static const COLORS_CONTINUOUS_TONE:Array = [
0xCCFFFF, 0xCCCCFF, 0xCC99FF, 0xCC66FF, 0xCC33FF, 0xCC00FF, 0xFF00FF, 0xFF33FF, 0xFF66FF, 0xFF99FF, 0xFFCCFF, 0xFFFFFF,
0xCCFFCC, 0xCCCCCC, 0xCC99CC, 0xCC66CC, 0xCC33CC, 0xCC00CC, 0xFF00CC, 0xFF33CC, 0xFF66CC, 0xFF99CC, 0xFFCCCC, 0xFFFFCC,
0xCCFF99, 0xCCCC99, 0xCC9999, 0xCC6699, 0xCC3399, 0xCC0099, 0xFF0099, 0xFF3399, 0xFF6699, 0xFF9999, 0xFFCC99, 0xFFFF99,
0xCCFF66, 0xCCCC66, 0xCC9966, 0xCC6666, 0xCC3366, 0xCC0066, 0xFF0066, 0xFF3366, 0xFF6666, 0xFF9966, 0xFFCC66, 0xFFFF66,
0xCCFF33, 0xCCCC33, 0xCC9933, 0xCC6633, 0xCC3333, 0xCC0033, 0xFF0033, 0xFF3333, 0xFF6633, 0xFF9933, 0xFFCC33, 0xFFFF33,
0xCCFF00, 0xCCCC00, 0xCC9900, 0xCC6600, 0xCC3300, 0xCC0000, 0xFF0000, 0xFF3300, 0xFF6600, 0xFF9900, 0xFFCC00, 0xFFFF00,
0x66FF00, 0x66CC00, 0x669900, 0x666600, 0x663300, 0x660000, 0x990000, 0x993300, 0x996600, 0x999900, 0x99CC00, 0x99FF00,
0x66FF33, 0x66CC33, 0x669933, 0x666633, 0x663333, 0x660033, 0x990033, 0x993333, 0x996633, 0x999933, 0x99CC33, 0x99FF33,
0x66FF66, 0x66CC66, 0x669966, 0x666666, 0x663366, 0x660066, 0x990066, 0x993366, 0x996666, 0x999966, 0x99CC66, 0x99FF66,
0x66FF99, 0x66CC99, 0x669999, 0x666699, 0x663399, 0x660099, 0x990099, 0x993399, 0x996699, 0x999999, 0x99CC99, 0x99FF99,
0x66FFCC, 0x66CCCC, 0x6699CC, 0x6666CC, 0x6633CC, 0x6600CC, 0x9900CC, 0x9933CC, 0x9966CC, 0x9999CC, 0x99CCCC, 0x99FFCC,
0x66FFFF, 0x66CCFF, 0x6699FF, 0x6666FF, 0x6633FF, 0x6600FF, 0x9900FF, 0x9933FF, 0x9966FF, 0x9999FF, 0x99CCFF, 0x99FFFF,
0x00FFFF, 0x00CCFF, 0x0099FF, 0x0066FF, 0x0033FF, 0x0000FF, 0x3300FF, 0x3333FF, 0x3366FF, 0x3399FF, 0x33CCFF, 0x33FFFF,
0x00FFCC, 0x00CCCC, 0x0099CC, 0x0066CC, 0x0033CC, 0x0000CC, 0x3300CC, 0x3333CC, 0x3366CC, 0x3399CC, 0x33CCCC, 0x33FFCC,
0x00FF99, 0x00CC99, 0x009999, 0x006699, 0x003399, 0x000099, 0x330099, 0x333399, 0x336699, 0x339999, 0x33CC99, 0x33FF99,
0x00FF33, 0x00CC33, 0x009933, 0x006633, 0x003333, 0x000033, 0x330033, 0x333333, 0x336633, 0x339933, 0x33CC33, 0x33FF33,
0x00FF00, 0x00CC00, 0x009900, 0x006600, 0x003300, 0x000000, 0x330000, 0x333300, 0x336600, 0x339900, 0x33CC00, 0x33FF00,
];

And then assign the colors array as follows:

var myColorPicker:uiColorPicker = new uiColorPicker();
 
myColorPicker.colors = COLORS_CONTINUOUS_TONE;

Aspire UI Components
Aspire UI is a library of Actionscript 3.0 (AS3) classes for building flexible and lightweight UI elements in Adobe Flash applications. Key features of the components include easy skinning using PNG image files, automatic tab focus ordering, CSS text styles, and layout management.

This is a pure AS3 library with no dependency on the Flex framework.

For more information, please click here.

You may experiment with the various features by downloading the trial version.

In this post, we look at how to get the popup to cast a drop shadow, by simply adding some directives in the “rules.xml” of the theme you are using.

The uiColorPicker component uses three skin assets:
ColorPicker.png
ColorPickerFrame.png
ColorPickerInput.png

The ColorPicker.png is the image that will be used to render the rectangular button. This skin asset is mandatory. If it is missing, the component will not show.

The ColorPickerInput.png is optional, affecting the look of the text input field in the popup palette. This skin is usually pointed to the same skin asset used by the uiTextInput component:

<ColorPickerInput clone="TextInput" prefs="width|74|focusPadding|1|padding|0" />

The ColorPickerFrame.png is the image that will be used to render the background of the popup palette. You can specify styling directives for the popup, such as padding, in the “rules.xml”:

<ColorPickerFrame edge="2" prefs="padding|3" />

Therefore, to get the popup to cast a drop shadow, all you need to do is to add the directive as such:

<ColorPickerFrame edge="2" prefs="padding|3|background|shadow,0x000000" />

The result will be as shown below:

Aspire UI Components
Aspire UI is a library of Actionscript 3.0 (AS3) classes for building flexible and lightweight UI elements in Adobe Flash applications. Key features of the components include easy skinning using PNG image files, automatic tab focus ordering, CSS text styles, and layout management.

This is a pure AS3 library with no dependency on the Flex framework.

For more information, please click here.

You may experiment with the various features by downloading the trial version.

With this update, the uiColorPicker component has been added to the Standard Edition.

In addition, we have streamlined component instance alignment with the following:

(i) new childAlignX and childAlignY properties help to define a default alignment for child objects contained within the same container.

(ii) a new qualified value for alignX and alignY properties – setting the property to ALIGN.FILL will indicate that the object is expected to fill its whole allocated space (horizontally for alignX or vertically for alignY), and therefore alignment does not apply.

(iii) as a result of (ii), it is no longer necessary to define fillX and fillY properties (since ALIGN.FILL and other alignment values should be mutually exclusive).

Aspire UI Components
Aspire UI is a library of Actionscript 3.0 (AS3) classes for building flexible and lightweight UI elements in Adobe Flash applications. Key features of the components include easy skinning using PNG image files, automatic tab focus ordering, CSS text styles, and layout management.

This is a pure AS3 library with no dependency on the Flex framework.

For more information, please click here.

You may experiment with the various features by downloading the trial version.