I realized that I had a little bit of conditional probability in the code, according to how one looks at it. It hinges on the if..then..else..end if clause in the proc body. "if nops(montys_choices) = 1 then" means that Monty had no choice in how to show inside a losing door. That's because the player picked a loser. Monty can't show the winning door, and he can't show inside the player's picked door. So he has only one choice. This can be rephrased as, "Given that the user selects a losing door, then Monty will show the remaining losing door and the final unshown door will always be the winning door." That has just the sort of phrasing that conditional probabilities do, when spoken, I think. It says, "Given that the user selects a losing door, then switching will always win." Similarly, one can analyze the code fragment that occurs in the `else` portion. Given that the player picked the winning door then Monty has a choice of two doors. Hence, given that the player picked the winning door then switching will always lose. These are both conditional probability statements. The probability of the first parts ("that the user selects a losing door" and "that the player picked the winning door") are 2/3 and 1/3 respectively. What makes it a somewhat unusual conditional probability is that the other parts (subsequent chances of winning, upon switching) have probabilities of 1 and 0 respectively. ps. I initially responded that the coding would be straightforward. There is one place where I made it not so, very much on purpose. It's where the set montys_choices is converted to a list and sorted, prior to one entry of it being selected at random. I just wanted to be sure that I'd avoided any pitfall of the consequences of how maple might order sets (now, or in future). acer

I realized that I had a little bit of conditional probability in the code, according to how one looks at it. It hinges on the if..then..else..end if clause in the proc body. "if nops(montys_choices) = 1 then" means that Monty had no choice in how to show inside a losing door. That's because the player picked a loser. Monty can't show the winning door, and he can't show inside the player's picked door. So he has only one choice. This can be rephrased as, "Given that the user selects a losing door, then Monty will show the remaining losing door and the final unshown door will always be the winning door." That has just the sort of phrasing that conditional probabilities do, when spoken, I think. It says, "Given that the user selects a losing door, then switching will always win." Similarly, one can analyze the code fragment that occurs in the `else` portion. Given that the player picked the winning door then Monty has a choice of two doors. Hence, given that the player picked the winning door then switching will always lose. These are both conditional probability statements. The probability of the first parts ("that the user selects a losing door" and "that the player picked the winning door") are 2/3 and 1/3 respectively. What makes it a somewhat unusual conditional probability is that the other parts (subsequent chances of winning, upon switching) have probabilities of 1 and 0 respectively. ps. I initially responded that the coding would be straightforward. There is one place where I made it not so, very much on purpose. It's where the set montys_choices is converted to a list and sorted, prior to one entry of it being selected at random. I just wanted to be sure that I'd avoided any pitfall of the consequences of how maple might order sets (now, or in future). acer

It should be straightforward to write a program in maple that simulates the game. That would let you confirm whether it is better to always switch, or not. acer

It should be straightforward to write a program in maple that simulates the game. That would let you confirm whether it is better to always switch, or not. acer

Robert's suggestion to simply remove the square [] list brackets from equ1 and equ2 is better than my suggestion to do equ11:=w_1=op(rhs(...)). But you might still want to use the ideas about reducing the number of equations. Multivariable Newton's method has an easier time of it and a better chance for convergence, for smaller systems of fewer variables and equations. It might then make it faster a more likely to get a result, if you decide to go with a variety of values for delta, p, and T say. acer

Robert's suggestion to simply remove the square [] list brackets from equ1 and equ2 is better than my suggestion to do equ11:=w_1=op(rhs(...)). But you might still want to use the ideas about reducing the number of equations. Multivariable Newton's method has an easier time of it and a better chance for convergence, for smaller systems of fewer variables and equations. It might then make it faster a more likely to get a result, if you decide to go with a variety of values for delta, p, and T say. acer

The first problem is that some of the "equations" you were passing in the first set argument to fsolve were of the form, name = list It looks a lot like what you wanted instead was the inside of that right-hand-side list (rhs). So, you could get it like so, equ11 := w_1 = op(rhs(eval(equ1, [p = .3, T = .1, delta = .9]))) and, equ22 := w_2 = op(rhs(eval(equ2, [p = .3, T = .1, delta = .9]))) Now, moving on. You can re-substitute quite a few of the later equations back into the earlier ones, to get down to a 2- or 3-variable system that fsolve handles OK. Here's what I added, at the end of your document, mw1w2 := isolate(equ44, m); A1 := eval(eval(equ11, [equ66, equ77, equ55]), mw1w2); A2 := eval(eval(equ22, [equ66, equ77, equ55]), mw1w2); A3 := eval(eval(equ33, equ55), mw1w2); Note that now, I could isolate w_1 from equation A1, and re-substitute that into A2 and A3 to get a 2-variable system of 2 equations. I didn't bother. solution := fsolve({A1, A2, A3}, {l, w[1], w[2]}, w[1] = -10000 .. 10, w[2] = -10000 .. 10, l = 0.1e-3 .. 1.999); That gave the result, {l = 0.4787635963e-2, w[1] = -1.900353594, w[2] = -1.901837431} The equations equ66 and equ77 give q and o directly. eval(mw1w2,solution); # gives value for m eval(eval(equ55, mw1w2), solution); # gives j I can re-substitute that solution into the equations, and check that doing so produces a very small float. Eg, eval(A2,solution); # gives close to 0.0, same for A1,A3 acer

The first problem is that some of the "equations" you were passing in the first set argument to fsolve were of the form, name = list It looks a lot like what you wanted instead was the inside of that right-hand-side list (rhs). So, you could get it like so, equ11 := w_1 = op(rhs(eval(equ1, [p = .3, T = .1, delta = .9]))) and, equ22 := w_2 = op(rhs(eval(equ2, [p = .3, T = .1, delta = .9]))) Now, moving on. You can re-substitute quite a few of the later equations back into the earlier ones, to get down to a 2- or 3-variable system that fsolve handles OK. Here's what I added, at the end of your document, mw1w2 := isolate(equ44, m); A1 := eval(eval(equ11, [equ66, equ77, equ55]), mw1w2); A2 := eval(eval(equ22, [equ66, equ77, equ55]), mw1w2); A3 := eval(eval(equ33, equ55), mw1w2); Note that now, I could isolate w_1 from equation A1, and re-substitute that into A2 and A3 to get a 2-variable system of 2 equations. I didn't bother. solution := fsolve({A1, A2, A3}, {l, w[1], w[2]}, w[1] = -10000 .. 10, w[2] = -10000 .. 10, l = 0.1e-3 .. 1.999); That gave the result, {l = 0.4787635963e-2, w[1] = -1.900353594, w[2] = -1.901837431} The equations equ66 and equ77 give q and o directly. eval(mw1w2,solution); # gives value for m eval(eval(equ55, mw1w2), solution); # gives j I can re-substitute that solution into the equations, and check that doing so produces a very small float. Eg, eval(A2,solution); # gives close to 0.0, same for A1,A3 acer

Since the evalf[..](...) action is only an approximate floating-point computation then the results would likely never be identically equal. If you increase the working precision during the floating-point evaluation in Idea 3 (or 2) then you might see those scalar floating-point numbers get closer to each other. If they don't get closer, as the precision is increased, then they are likely not equal. The precision in the incantations that I gave is specified by the number in the indexing [..] brackets of the evalf call. So, evalf[50](...) uses a working precision of 50 decimal base-ten digits, while evalf[100](..) would use a working precision of 100 digits. Calling evalf in this indexed way is an alternative to setting the Maple environment variable Digits. If, as you raise the precision, the results for sol1 and either sol2 or sol3 keeps getting closer then it may be that the obtained formula which you are instantiating at specific a,b, and c does actually work. During the (Gaussian) elimination steps that happen while Maple computes the so-called LU decomposition of a Matrix, a "pivot" is found for each row reduction. The pivot is chosen as a leading non-zero entry in the current column. Sometimes a complicated expression in an entry might appear as a huge involved formula while in truth it is identically zero (upon simplification, or conversion to so-called "normal" form). The candidates for pivot selection are hit with the Normalizer function, in order to attempt to always recognize elements as being invalid on account of their being actually zero. One can override the Normalizer. The function x->x is a "no operation" action, which while fast won't do any simplification and is thus not a good zero-recognizer. The danger, then, is that a hidden zero might get used as a pivot. The default Normalizer, when not overridden, may have to work very hard, which is why there is such a performance speed difference. I ought to read Jacques' paper(s) on these subjects. In one (other?) thread he talked about doing the Gaussian elimination step by step, and taking account of the pivots one by one. I'm wondering now whether fraction-free elimination would be a more useful approach. After all, determinant calculation doesn't necessitate divisions... Now, back to your problem. If you evaluate the original Matrix at given numerical points for a and b, then the determinant will be a univariate expression in c, yes? You could solve or fsolve that expr=zero for c. So, if it was fast enough to compute the determinant of that univariate Matrix (after instantiating a and b) then you might be able to repeat this many times. If you were lucky, you might be able to repeat it enough times so as to get a mesh of values for c, based on all the different particular a and b pairs that you used. You could then plot those. You might even be able to get a smooth interpolating approximation function, if you had enough numeric sets. acer

Thanks, Paulina. The method of converting to Atomic Identifier we figured out, for non-1D-parsable 2D objects. But ?plots,typesetting also mentions using left-name-quotes to do this (in the same paragraph that it mentions atomic identifiers, for such problematic 2D objects). I couldn't get the left-quotes to do it. Could you give an example? acer

Thanks, Paulina. The method of converting to Atomic Identifier we figured out, for non-1D-parsable 2D objects. But ?plots,typesetting also mentions using left-name-quotes to do this (in the same paragraph that it mentions atomic identifiers, for such problematic 2D objects). I couldn't get the left-quotes to do it. Could you give an example? acer

From the Maple program's top menubar, choose, View -> Palettes -> Arrange Palettes That should pop up a new window, which lets you configure which palettes will show in the side pane. Remember, after you create the 2D object, toggle it as Atomic Identifier before you Convert it to 1D notation. acer

From the Maple program's top menubar, choose, View -> Palettes -> Arrange Palettes That should pop up a new window, which lets you configure which palettes will show in the side pane. Remember, after you create the 2D object, toggle it as Atomic Identifier before you Convert it to 1D notation. acer

I also tried to enter the 2D Math expression directly into the session, surround it with left- name-quotes, and use that directly within the textplot() call much as the help-page suggests. At first I used 2D Math left-quotes, ie, inside the object. That ended up producing something with Typesetting errors embedded within it. Which is weird. When trying to use the left-quotes, I also produced a plot whose structure was, PLOT(TEXT([3., 4.], _TYPESET())) desite there being some nice 2D typeset input thing in the actual call. Then I tried with 1D notation left-quotes, just outside but around the 2D Math input object. That is, the quotes were red instead of black. That resulted in a textplot which contained, literally, `LinearAlgebra:-HermitianTranspose(p[gt]);` The thing inside the textplot call was all nicely typeset, though. This was the weirdest. I think that precise instructions would help the user most here. Precise sets of key-strokes, named in the help-pages, seem almost necessary to provide satisfaction. Also, (and this may not be true of this situation; I don't know yet, about the left-quotes) anything which can only be done by using the mouse is not best implemented. acer

I also tried to enter the 2D Math expression directly into the session, surround it with left- name-quotes, and use that directly within the textplot() call much as the help-page suggests. At first I used 2D Math left-quotes, ie, inside the object. That ended up producing something with Typesetting errors embedded within it. Which is weird. When trying to use the left-quotes, I also produced a plot whose structure was, PLOT(TEXT([3., 4.], _TYPESET())) desite there being some nice 2D typeset input thing in the actual call. Then I tried with 1D notation left-quotes, just outside but around the 2D Math input object. That is, the quotes were red instead of black. That resulted in a textplot which contained, literally, `LinearAlgebra:-HermitianTranspose(p[gt]);` The thing inside the textplot call was all nicely typeset, though. This was the weirdest. I think that precise instructions would help the user most here. Precise sets of key-strokes, named in the help-pages, seem almost necessary to provide satisfaction. Also, (and this may not be true of this situation; I don't know yet, about the left-quotes) anything which can only be done by using the mouse is not best implemented. acer