A few examples,

Download basic_assumptions.mw

It's difficult to know what exactly you are now doing. I could make a wild guess, and so maybe it's something like the following (ie. maybe you're no longer using such an F). Guessing isn't a productive way to proceed here.

S4_Generate_Systmes_ac.mw

Your evalf calls don't use enough working precision, and the floating-point evaluation is inaccurate.

It's faster and easier (and more accurate at default working precision) to do purely floating-point integration here. (Note the use of inert Int, where evalf(Int(...)) does purely floating-point integration.)

Or you could call evalf[n], to use higher working precision when evalf'ing your large exact expression. (But you have to find n large enough...)

Is there some special reason that you need that large and unwieldy exact symbolic integration result?

Download StdE_ac.mw

NB. Using default Digits=10 or evalf[10] is not a guarantee of getting 10 correct digits in a float result, when obtaining a float approximation of a compound exact symbolic expression. It's not a specification of requested final accuracy. Rather, it makes Maple use 10 digits of working precision for individual floating-point operations. For a compound symbolic expression, numeric error (round-off, loss of precision) can accrue.

ps. The construction,
   evalf[10](evalf[40]( ... ))
does the inner computation with Digits=40, and then applies Digits=10 to the inner result. So that initially uses Digits=40, and then rounds a float result to 10 places.

And the forget(evalf) is to clear evalf's remember table, so that my explanation is not muddied if you try and repeat the coarser computation after having computed the more accurate one.

You can get decent instruction from Student:-Calculus1:-ShowSolution, example at the end of attachment. That is, you might not want to reinvent that functionality from scratch...

But, for fun, here are also a few variants on your requestion (some along the lines of ftoc),

Download 5.3-Definite-Integral_ac.mw

It seems that a nice compact answer can be had for your Case (i).

Download simplify_Ahmed1_ac1.mw

There are shorter codes which produce results not so terse. (Yet, even above, it'd be nicer to factor the I in the exp call's argument.)

You can, naturally, also turn that simplified result's solitary exp call into trigh form. But that just doubles its size...

For the other cases it may require more effort to find a near-optimally-compacted form.

The equivalence of entries is -- as far as the union command goes -- by memory address. That is to say, it's a Maple structural comparison rather than a purely mathematical comparison. This is mentioned in a note on the Help-page of the union command.

In practice that is mostly quite useful, since stored numbers and general algebraic expressions share both equivalences.

But for some objects they are not the same. That goes for mutable data structures such as Vectors/Matrices/Arrays. Two Matrices which have the very same entries may appear the same, but they are distinct objects.

Let's suppose that the Matrices are returned to you by some commands or program.

One way to deal with this is the use a facility like the EqualEntries command, to test equivalence and remove "duplicates" manually. That can get awkward if there are many elements in the collections, or if you have to do it repeatedly.  You might prefer not to have to fix up (after the fact) the set that results from any usual `union` attempt involving Matrices/Vectors.

On the other hand, both lists and lists-of-lists that have identical entries are uniquified and stored just once in memory. (The apparent mutability of short lists is merely a convenient veil.) A pair of lists with identical entries always both point at the same uniquified list stored in memory. 

So another way to approach this is to work with sets of lists-of-lists rather than Matrices. You can programmatically add them to a look-up table, to help with repeated access.

You could simply do the relevant work by then working with lists only. Or you could switch back and forth in a more programmatic manner -- an example of which I outline below.

In the following, the Matrices are "registered" via conversion to listlist. Naturally, if you change the values of any entries in the Matrices after registering them then the comparison becomes invalid.

Download set_listlist_Matrix.mw

There are other ways to program all that. I'd often rather a little more code at the start, if it makes the subsequent operations easier. I didn't put in guards to ensure that &Union were called ony with registered items, etc. I don't know whether this route is appealing for you.

Here are two ways.

There are more possible ways, but I don't know what set-up you want to hide, or whether you'd prefer right-click & context-menu versus more programmatic ways.

Download ts_multi_sum_1.mw

nb. I originally had,
   f := i -> `%^`(i, 2)
for the inert powering. That's not too difficult, for this simple example. But I've now changed my worksheet to that the inert expression and the operator f are constructed in a more general purpose manner -- using MakeInert. That would be easier than having to type out all the prefix inert function calls, in a more involved example.

For the algebra (not the geometry),

Download jalal_cplx.mw

Perhaps you could simplify at each step, to reduce the burden.

(I wonder also whether there is a pattern; perhaps iteration is not necessary?)

Download b1_ac.mw

Your attempt,

   pointplot3d(eval(polygon[[0, 0, 0], [x3e, y3e, z3e], [1, 0, 0]], t = 1/100*tt), color = pink)

is not valid syntax.

1) You've used square brackets, but polygon needs round brackets in the usual way for a function call.
2) The pointplot3d bit is wrong. (what did you expect it to do here?)
3) The eval usage is out of place.

It's not helpful to provide only a portion of your code. You could at least provide the obvious missing bits, such as x3e, y3e, z3e, tt, whether you loaded packages, etc. There's no reason not to upload and (at least) attach (insert link) your actual worksheet here.

Here's an example that might help. I've had to make some guesses.

Download polygon_ex.mw

Here's one way to get that.

nb. The outer (mapped) sort is to turn terms like z*y and y*x into y*z and x*y, etc.

Download sort_lex_fun.mw

ps. You seemed to have an extra "x*x" term in your expected output. Perhaps it is a typo, since you had x^2 only once in both input and output. However, if you do indeed have the possibility of repeated terms then please let me know (as the addition trick wouldn't work directly; though it could be amended by removing/reinstating multiplicity fore&aft, or just by using the coefficient.)

I don't think that I'd do it all this way, but is the following the kind of thing that you're trying to do?

(I put in some redundancy, so you can check and compare. And I couldn't tell whether you wanted the mixed conjugate products to be turned into abs form.)

Download solving_ac.mw

ps. Where did you get that code? If it's not originally your own then you'd benefit from picking it apart so that you understood what the various parts do. Otherwise, it's going to be hard to fix/adjust/extend it in future.

The result from a direct solve call is not so nice in your Maple 2019.

But a little preliminary adjustment can help it.

Download Q_isolate_acc.mw

There are pieces of information missing wrt whether all entries of any given (after the first outer list) are of the same type. Eg., what would be the classification number, if not all entries were of the same type?

But here is something that covers your sole, lonely example. How it extends will depend on your as-yet-unspecified other examples; your choices could make or break it.

Download some_list_stuff.mw

It is not necessary to make a separate ZeroMatrix call, or (in general) to simplify all of M+M^%T.

That is, forming mtest:=simplify(M+M^%T) is itself not very efficient, in general. The simplicification action can instead be part of the andmap predicate (with possible early bailout), and there's no need to test both triangles.

Also, the user-defined operator X->evalb(X) is an unnecessary layer; one could just map evalb.

Download Download_ac.mw