Here is the worksheet with strange result (where I got totalPDF= PDF_Y2+PDF_Y1 = wrong result, while totalPDF=PDF_Y2-PDF_Y1 = correct result)

example2.mw

I put an image from the book here (we need to double click to download it and zoom-in to view) .

I switched to Maple13 to check  int(total_PDF, y=-infinity..infinity)  (where I put theta=0, _Z1=0) and get int() = 1.

But for the other problem with 2 roots:  "fX(x)= 2x/Pi^2, 0<x<Pi .  and y=sin(x).  Determine fY(y)"

  If use total_PDF= PDF1+PDF2 then I got wrong result but if I used total_PDF= PDF1-PDF2 then I got correct result .  So still confusing right now about what is going on with code. (in theory , I think it should be total_PDF= PDF1+PDF2)

That 's the key I want to know  :  if  I used DBG>where;  without calling  stoperror(traperror);  then I wouldn't see the trace of internal functions calls (I only saw the top-level calls such as RandomVariable(),  Distribution(),...), and can't detect the source of errors. 

This will save me whole bunch of time in the future  but I wonder why some good trick like this weren't included in the manuals

(but maybe I am missing...)

But thank you very much  anyway !

Thank for your response. But if we click "step"/"into" or "next" many times to reach the error , then the Debugger GUI will automatically Quit and return to Worksheet Interface, so we have to do "step"/"into"/"next" multiple times again to get close to the error region. So I think it 's better if we have something such as "unstep" so that we could go backward from the error after doing such as stoperror(all); + continue +..to reach the error and then go backward...