@Michael

@acer was only using posint to refer to the type of the suffix on the variable. For example, in _Z2, the 2 is the suffix, and it happens to be a posint.

I completely rewrote the rest of this Reply to emphasize and elaborate upon the type/property distinction, and it's further down in this subthread now.

@mmcdara You wrote:

• Maybe I made a wrong interpretation of the term "exchange" while considering that if someone, X, recieves the gift that someone else, Y, bought, then Y recieves X's.

I think that you are interpreting that part incorrectly. The desired permutations are not necessarily symmetric (i.e., of order 2), as can be seen from the final output of @Christopher2222 's most-recent Reply.

@Christopher2222 I computed the exact probability of families B and C swapping in one year, and in successive years. The probability is of course very small, but it's not quite as small as I was guessing. Unlike the earlier probability that I computed exactly, there's a relatively simple formula for this one. It can even be done with pen and paper, which I did yesterday while I was at a party without access to Maple.

I start with a formula for the number of fixed-size set partitions using a specified list of family sizes (in this case [3,4,4,4,1]).

(* Formula to count the number of fixed-size set partitions with the
specified block sizes. This returns an inert expression (for educational
purposes) that can be evaluated with the value command.
*)
CountPartitions:= (S::list(posint))->
    %factorial(add(S)) %/ 
    mul(%factorial~(subs(1= (), [S[], rhs~(Statistics:-Tally(S))[]])))
:

So, for the case at hand,
CountPartitions([3,4,4,4,1]);
             16! / (3!^2 * 4!^3)
value(%);
             42042000

Now let's consider all set partitions where families B and C swap (in exactly the way that you described). The setwise image of B under the corresponding permutations is C, and the setwise image of C is B. So from the point of view of fixed-sized set  partitions, the complete count is the same as the count of the partitions of the remaining 8 people into blocks of sizes [3,4,1].

CountPartitions([3,4,1]);  value(%);
             8! / (3! * 4!)
             280

So  the probability of this happening in any given drawing is
280 / 42042000;
             1 / 150150

and the probability of that happening in two specified drawings is
%^2;  evalf[2](%);
             1 / 22545022500
             4.4 * 10^(-11)

To be fair, we should consider the probability of any pair of families swapping and that same pair swapping in the next drawing. In this case, that's only possible for 3 pairs: (B,C), (C,D), and (B,D). No two of these pairs can swap at the same time, so the probabilities are simply 3 times those computed before, with the final number becoming 1.3 * 10^(-10). I still consider that "infinitesimal"! To put that in perspective, you'd be 11566 times more likely to get the highest possible poker hand---a royal flush---in a 5-card deal with no extra cards than to have the same two families paired 2 years in a row.

@Christopher2222 There's also a command combinat:-randperm, which is easier to apply to this problem than randcomb.

@mmcdara 

Here I attempt to describe the problem with a degree of mathematical abstraction and less reliance on social and anthropological constructs that might cause confusion of the math.

We have a set of 16 people partitioned into 5 subsets, here called "families". Using some randomization method (colloquially, traditionally, and metaphorically referred to as "drawing names from a hat") we generate a permutation of the 16 so that each person is assigned another from the group to give a gift to. This is not intended to be a symmetric exchange (a transposition), but that is allowed if that's the way the random assignment turns out.

Of course, there is no fun in this if a person is assigned to themself. So we want the permutation to be a derangement^[*1] in the standard mathematical sense. To further increase the level of fun, social bonding, etc., we impose a stronger restriction that I'll call a generalized derangement: No person should be assigned to someone from their own partition block (i.e., family).

So, the question is What is the probabilty that a random permutation satisfies this restriction?

I've heard of this tradition being called "Secret Santa".

[*1] This usage of derangement is strictly a mathematical type of permutation (specifically, it's a permutation with no fixed points); it has no connection to the state of mental illness of the same name.

@Christopher2222 I haven't computed it, but off the top of my head I'd guess that the probabilty that 2 of the same-size families would reciprocally exchange given a random drawing is on the order of 10^(-11), so the probability of that happening 2 years in a row is on the order of 10^(-22). As I mentioned in my exact computation, the number of permutations is very close to 2.1×10^(13), aka 21 trillion.

Ah! This is forensic mathematics! 

Here is a computation of the exact probability. This is a bit messy and takes several minutes of computation. It would be infeasible to check all 16! ~ 21 trillion permutations. But they can be grouped as fixed-size set partitions such that either all the permutations matching a particular partition are valid, or they're all invalid. The number of permutations covered by each partition is exactly (3!)^2 * (4!)^3 = 497,664. Thus the number of cases that need to be checked is reduced to about 42 million, which is feasible.

restart:
FamN:= [3,4,4,4,1]:  #family sizes
PS:= [seq[scan= `+`]](FamN);
                    PS := [3, 7, 11, 15, 16]

FamS:= (`{}`@`$`@`..`)~([1,(PS[..-2]+~1)[]], PS)[];  #the initial set partition
       FamS := {1, 2, 3}, {4, 5, 6, 7}, {8, 9, 10, 11}, {12, 13, 14, 15}, {16}

nf:= nops(FamN):
SPFS:= Iterator:-SetPartitionFixedSize(FamN):
sp:= output(SPFS):

# For efficiency, we divide the output Array from the Iterator into 5 chunks 
# matching the pattern of the partition. There's no mathematical reason to do
# this; it's only done to save about 4 minutes of "real" computation time.

FamA:= seq(ArrayTools:-Alias(sp, [0, PS[..-2][]][i], [FamN[i]]), i= 1..nf):
ValidDraw?:= ()-> local i,x;
    not orseq(orseq(x in FamS[i], x= FamA[i]), i= 1..nf)
:
V:= 0:  #count of valid partitions (no intra-family pairings)
CodeTools:-Usage(in SPFS do if ValidDraw?() then V++ fi od):
memory used=24.64GiB, alloc change=448.64MiB, 
cpu time=15.16m, real time=5.09m, gc time=12.08m

V;
                             751650
prob:= V/Number(SPFS);
                          prob := 5011 / 280280
evalf(prob);
                         0.01787855002

So, the exact value is extremely close to my simulated estimate,

@mmcdara Thank you for your input. Okay, I understand your nuance about the correct usage of p-value. Nonetheless, would you agree with this statement: "This simulation estimates that the probability that a random drawing would have no intra-family pairings is less than 2%"?

I just finished computing the exact value of the probability, and I'm about to post it. The estimate that I made above was very good, with relative error of only 0.006.

@igor.v.proskurin Sorry if I seemed harsh. I think that you've been a great contributor to MaplePrimes considering that you've only been here for two weeks.

@igor.v.proskurin You wrote:

• So when you are doing subs(x = 1, g(x)), it means diff(g(1), 1), (not diff(g(x), x) at x= 1) and that is the problem.

That is 100% incorrect. Like the vast majority of Maple commands, subs evaluates its arguments before using them. Since g(x) evaluates to something that has no diff, there's no difference between subs(x=1, g(x)) and eval(g(x), x=1) in this case. Indeed, the OP said that subs worked.

@mmcdara I have a quibble with your expected value computation. In your procedure, 3 of the throws occur exactly 1 time. It's only the 2nd throw that has a possibility of having 6s discarded. So, the expected value is

3 + 5*sum(n/6^n, n= 1..infinity) = 4.2 (exactly).

I've verified this experimentally by putting a global counter in procedure dice and running SelectCard() 100,000 times. The throw count was 419,922.

@ Please post again in this thread if you continue to have this problem. 

Here are simple arithmetic steps for your son:

To generate a random integer n  from 1 to 120 using a 6-sided die:

1. Roll the die. Let d be the number shown.
2. Let n:= 30 × (d - 1).
3. Roll the die, perhaps repeatedly, until it shows a number less than 6. Call this number d.
4. Let n:= n + 6 × (d - 1).
5. Roll the die until it shows a number less than 5. Call the number d.
6. Let n:= n + d. 
7. n is now your card number. If that card has already been chosen, restart at step 1.

@acer The OP's intent wasn't totally clear to me. I only meant to offset the possibility that the OP mistakenly thought that relational operators (used in the normal way: exactly 2 operands) were contributing to the Boolean evaluation problem.

@digerdiga You asked:

• Is it also possible to use a different symbol (=,<=,>=,...) at each step?

From your example, I think that you're more interested in changing to symbols with different mathematical meaning rather than merely changing the typography. All of the Maple operators {=, <=, >=, etc.} (called relational operators) are inherently inert; they didn't cause your original evaluation problem. It was only the and that forced a Boolean evaluation; so it's the only thing that needs an inertness or unevaluation adjustment. The and arises from using a relational operator with more than 2 operands (in 2-D input). For example, a = b = c is parsed to a = b and b = c.