@Harry Garst By Maple's full evaluation rule, if A and B are already matrices, then after

expr := Determinant(KroneckerProduct(A,B));

expr is a number with the Determinant of the Kronecker product already done, i.e., it is too late to process it.

So the processing routine has to use ZehfussReplace := proc(expr::uneval)

With that modification your ZehfussReplace routine works at least for the simple case of providing

ZehfussReplace(Determinant(KroneckerProduct(A, B)))

It could be made more robust, e.g. checking for square matrices etc, only two matrices, allowing for symbolic A,B etc. Not sure what your precise requirements are.

If I convert the first line to 1D math you see it is

dim := 1;
A := Matrix(dim, dim, symbol = a);
evalb(factor(Determinant(`⨂`(A, A))) - abs(A)^(2*RowDimension(A)) = 0);

so I think the |A| in the 2D math is being interpreted as abs and not Determinant the first time. Somehow if you leave it as 2D, it interprets as abs the first time and then if you reexecute the same line it "has now figured out" that A is a Matrix and you get the determinant. Very mysterious. The solution is to write out Determinant(A).

for dim = 4, the Kronecker product is 16x16 and the determinant has 16! = 20922789888000 terms, and then you are trying ro factor the result so it isn't unexpected that it takes too long.

I'm not clear about what you mean by "detect whether there is a determinant of a Kronecker product present in an expression."

@Paras31 The Maple values are not what I am getting; I am using default epsilon. 

wval = 0.0008418042;

dwval = -0.062794051; (same as MMa)

theata := 0.2715071460;

FokasTests.mw

Perhaps I am not understanding the fourier plot, which looks like the MMa plot. It has a point at x = 0.0786577523618090, theta = 0.241280506060024 on the 1 min curve. This seems closer to the Maple result theta = 0.2715071460 than the MMa result 0.355. Are you sure the MMa number is correct?

The estimated error suggests that 0.0008418042 should have most of its digits correct. It is possible because of inaccurate evaluation of the integrand, that the estimated error is not correct, which might happen because of the very complicated expression. But I get the same result after normal(V) or collect(V,exp) which are quite different. I also tried getting rid of all preprocessing by making a procedure that does the Re directly in a numerical procedure; presumably what MMa does, and got the same result.

I also tried splitting the two integrals differently (different s ranges, and other corresponding changes in the lambda procedures), but also got exactly the same result for wval in each case.

Notice that the two integrals have similar magnitudes but opposite signs, which leads to larger errors in their difference wval. Then in the ratio dwval/wval you are dividing a large number by an error-prone much smaller value, which is why the error in theta is amplified.

Yes, I miss those indicators, too. My solution is to move to the edit tab and watch the "mode" when I am using mixed text/non-executable math. Then when I am entering text I see "text"; I use F5 to change to non-executable math and I see the change to "non-executable"; two times F5 goes back to text and I see "text" again. Edit: here's what I mean:

Edit: I just noticed the small icon on the drop-down box on the right of the top "line" of the screen also changes as you "toggle" F5.

I hadn't noticed differences in the cursor.

@Ronan It's a while since I used them; I can't remember :-(

@Paras31 Those seem to have good agreement, enough that you wouldn't see the differences on a plot. Your plots are different orientations and scales so hard for me to see where you think there is a difference, aside from the points at x=8 cm, which being on the boundary are exceptional. 

Are there places where the MMa and Maple results are very different but not on the boundary? Perhaps x=7.9 and t= 1min?

@Paras31 The approx_w(0.01,0.1) agrees to 3 decimal places with MMa, so is not a good sample point for further tests. Just let me know a point where there is poor agreement between MMa and Maple, and I'll take a closer look.

@Paras31 Your routine gets 0.3752737697 instead of 0.375077. Your s range is different so this is not an exact comparison, but in any case are you saying you are sure MMa is more accurate?

@Paras31 It is hard to say since I haven't followed in detail the two methods. I assume they are both approximations, so do you have some reason to think one is closer to the real solution? Have you benchmarked for a system for which you know the real solution? Can you improve the approximation, e.g., why is one integral from -5..5? is that adjustable?

First of all, I think you need to do an exact comparison (overlaid plots) or accurate comparisons at selcted points. Is there good accuracy for some x/t regimes?

@Paras31 In the first plot, where I think all the numbers are supposed to be 1 you have the worst point at 1.00000025, so the error is actually better that 0.001 (which I assume is worst case). For a plot with numbers of the order of one, I doubt whether you could visually tell 1.001 from 1. To me all the plots look essentially the same, so who could tell? Of course you may want to use epsilon = 1e-3 to speed things up and then use more accuracy in a final publication/presentation/etc.

For other than plots you might want more accuracy if you are going to use the results in further calculations. But even then you can do some faster, less accurate calculations in the preliminary stages and then require more accuracy for the final values of interest.

@wingho This is giving a 404 file not found error. Please try again - use the green up arrow; select the file; choose file upload and then choose insert link.

@acer Yes, for epsilon = 1e-3 it is about a factor of 2 speedup (on the slowest final calculation).

third_try.mw

@Paras31 Your plot was missing adaptive=false. The double seq did 6*10 calculations, each 9 s, for a total expected time of 9 minutes and it took 7 min, so you just had to wait longer.

third_try.mw

@Alfred_F Thanks. Changed to maximize.

@Rouben Rostamian  Yes, my plot (and calculation) are wrong. If I change the plot range to 0..40 rather than 0..x__max, I see the plot doesn't come down to the axis; Maple seemed to add a phantom point  in the 0..x__max case. So I see my mistake, and with a recalculated mu to make the plot to come to the axis I get the same value as you did. I've updated my answer and left the other one there for the record.

Thanks!