@tomleslie As types, radical and anything^fraction are equivalent, and radical is more to the point; so, vote up.

Here are a few corrections, including returning 1 if the probability of the condition is 0 and returning FAIL if the unsimplified results from Probability give FAIL/FAIL.

Conditioned:= proc(
   event::{relation, set(relation)},
   cond::{relation, set(relation)}, 
   rv::
      {name= RandomVariable &under Statistics:-RandomVariable,
       {set,list}(name= RandomVariable &under Statistics:-RandomVariable)
      }
) 
uses St= Statistics;
local 
   Event:= `if`(not event::set, {event}, event),
   Cond:= `if`(not cond::set, {cond}, cond),
   RV:= `if`(not rv::{set,list}, [rv], [rv[]]),
   d 
;
   if nargs=3 then 
      (Event,Cond):= 
         subs(lhs~(RV)=~ St:-RandomVariable~(rhs~(RV)), [Event, Cond])[]
   fi;
   d:= St:-Probability(Cond);
   if d = 0 then 1
   elif d = FAIL then FAIL
   #union used rather than intersection because Probability considers a set
   #of relations to represent the intersection of the corresponding events. 
   else St:-Probability(Event union Cond) / d
   fi
end proc:

Probability cannot handle the multivariable situations that you want to consider. If you're only interested in spaces that are the product independent uniform distributions, I may be able to code something from scratch.

@BigBugBuzz I haven't seen any mention of an actual bug in Probability in this thread, just limitations. If presented with a problem too complex, it may return the symbol FAIL. Some of the more-complex problems may be easily done by numeric integration if an exact answer is not required. Do you require exact solutions?

@inteli 

You can select columns 3 and 6, for example, by M1B[.., [3,6]]. You can select rows 5 and 1, with 5 being on top, by M1B[[5,1], ..].

@Markiyan Hirnyk 

I am in Amsterdam, many thousands of kilometers from my home. I will fix the FAIL issues when I have access to a computer, which is likely Friday. I need a different power adapter for my computer due to the different electricity here, I've ordered it, and it's coming Friday.

I already said that FAIL/FAIL incorrectly simplifies to 1 and that I'd fix it when I had access to a computer. That you would mention it again in just a few hours is what we call "flogging a dead horse."

@Markiyan Hirnyk The error comes from Probability, not from my procedure. Would you expect me to rewrite that also? The Mathematica conditioning operator is just an add-on to its probability command. Likewise, my procedure is an add-on to Probability. It does correctly handle whatever multivariable cases Probability handles.

The situation is far from ideal, but you can't blame me for the longstanding deficiencies of Probability.

When I have access to a computer, rather than my phone, I will correct the case where FAIL/FAIL simplifies to 1.

@Markiyan Hirnyk 

I don't have Mathematica, so I can't check which cases it handles; so, I made it at least robust enough to handle the single example given in the Question.

My procedure (as originally posted) handles the multivariable case when the random variables have already been declared. To handle the other case---that the variables are being declared directly in the third argument (similar to an assuming clause), requires only a trivial modification:

Conditioned:= proc(
   event::{relation, set(relation)},
   cond::{relation, set(relation)}, 
   rv::
      {name= RandomVariable &under Statistics:-RandomVariable,
       {set,list}(name= RandomVariable &under Statistics:-RandomVariable)
      }
) 
uses St= Statistics;
local 
   Event:= `if`(not event::set, {event}, event),
   Cond:= `if`(not cond::set, {cond}, event),
   RV:= `if`(not rv::{set,list}, [rv], [rv[]]) 
;
   if nargs=3 then 
      (Event,Cond):= 
         subs(lhs~(RV)=~ St:-RandomVariable~(rhs~(RV)), [Event, Cond])[]
   fi;
   #union used rather than intersection because Probability considers a set
   #of relations the represent the intersection of the corresponding events. 
   St:-Probability(Event union Cond)/St:-Probability(Cond)
end proc:

@BigBugBuzz I think that it'd be best to avoid applying evalf to expressions containing RootOf because it'll generally only give you one result when there are many. Rather, you need to isolate roots to intervals, possibly complex intervals.
            

@tomleslie I think that you intended to include an argument w = 0..1 to your fsolve, but that you forgot it.

@ibndirac Sorry, I misterpretted something---not something that you wrote but some Maple output. My Dirac comment was totally irrelevant.

I suppose that you think of diff(g(x,t), x) as some sort of Dirac-like function, right?

@Annonymouse The dimension of a solution returned by solve is the number of its vacuous equations.

@brian bovril Change the declaration for Games in procedure Update to

Games::list({
      [{name,string}, {name,string}],
      [{name,string}, {name,string}, anything]
   }),

And change the updating line to

(R[G[1]], R[G[2]]):= ELO(R[G[1]], R[G[2]], G[3..][])

By the way, Elo is not an initialism or acronym. It's named after the person who invented it, Arpad Elo. So it'd be more proper to spell it Elo rather than ELO.

@maple2015 You said that the Z values were experimentally determined, yet when the fitted model function deviates from those Z values, you call it an "error". Those two things are not consistent with each other. If you're going to use regression, then you must accept that the Z values themselves have error and that the best model function may not pass through any of them. To do otherwise is bad science and often a morally corrupt business / engineering practice (part of "lying with statistics").

The difference between the z-value obtained from the model function and the corresponding experimental z is called a residual.

The difference between an experimental z-value and its true (but unknown) value is called an error. By true value, I mean the mean of all possible experimental values at the given x and y.

If you want to give more weight to certain z-values, it can be done with the weights option to LinearFit. I wouldn't consider it corrupt if certain values were given more weight because they had been experimentally verified more times. Indeed, if W were the weights vector, you could just let W[i] be the number of times that Z[i] had been verified.

By the way, I'm not trying to argue that any of the models that I've proposed are correct. I wouldn't claim that any model is correct without there being some scientific basis for the inclusion of each of its terms. Rather, I'm arguing that your reason for rejecting models is wrong.

@maple2015 Ah, now that you've said that X and Y are both ratios, and, even better, that they have a common factor (the amount of cement), it's clear to me that a good model to try is multiplicative rather than additive: Z = C*X^p*Y^q, where C, p, and q are values to be determined. It's done with logarithms like this:

lnZ:= Statistics:-LinearFit([1, ln(x), ln(y)], < X | Y | ln~(Z) >, [x,y], summarize);
Summary:
----------------
Model: -12.751403+5.0633641*ln(x)-8.0127107*ln(y)
----------------
Coefficients:
              Estimate   Std. Error  t-value   P(>|t|)
Parameter 1   -12.7514    1.6204     -7.8693    0.0000
Parameter 2    5.0634     1.3071      3.8739    0.0017
Parameter 3   -8.0127     0.7647     -10.4783   0.0000
----------------
R-squared: 0.8927, Adjusted R-squared: 0.8774

Model:= simplify(exp(lnZ));
     Model := 0.289825157651345e-5*x^5.063364078/y^8.012710653