@digerdiga Could you provide an example or what else you might want?

@Christian Wolinski It's not clear why you mention an "exact match".  It gives the same results as,

   A::'Matrix(4,4)' and LinearAlgebra:-Norm(A)=0;

with both methods accepting Matrices containing either exact or float zeroes.

ps. I like to do the dimension check first, so as (potentially) to fail out there before having to check all entries.

But reversing the order of the tests in just one of these approaches would make the approaches match (both throwing an error, or both not) in the case that A is not actually a Matrix. Alas, the OP did not really answer my query about whether the input would always be an actual Matrix.

@Jamie128 I'll mention that code would also produce A if used on a Matrix that contained floating-point zero, ie. 0.0 .  Reply if you'd want that not to happen.

Please put followup queries on this example (and related simplification or verification) as Replies/Comments here, instead of starting wholly separate new Question threads for such.

@mmcdara I wholeheartedly agree with the idea that it's often very beneficial to extend a solution and answer, past what a poster has written.

It was your sentence, "The key is to define the rewritting rules rel that will lead you to the desire result." that I found confusing.

The form that your rel rules reveal was not mentioned by the OP, and it's also not hands-down obviously superior, so why do you say that it's "the desire result" [emphasis mine]?

I didn't intend offence. It's the use of the definite article that surprised me. This might be just a translation thing.

@mmcdara I know how the Statistics package works, but thanks for your comment. I used rand and code in the OP's general form, only to try and keep it more consistent with his earlier style.

I already thought that it was clear (and obvious) that one could use a larger number of dice, to get the uniform distribution over the fixed (original) range. I used the same number n (20) in both spots only because the OP had.

The OP sometimes takes several messages before the true goal appears.

I often regret guessing, on this forum. I'll leave this thread now.

@mmcdara In the OP's original Question the stated target expressions appear (modulo rational coefficient rearrangements) as they do in your computed trigsol results.

The reformulation formed by your use of your rel equations is interesting, but not actually requested in the original Question. I'll note that one can also get it without having to write out those rel equations manually, ie.

   simplify(expand(trigsol),size)

@Gabriel Barcellos As you mention, this only affects the latter part, whose only purpose was to reformat the rational coefficients just as you wanted. The answer in the first part is already correct, and in trigh rather than exp calls.

I had shown 1D Maple Notation code. Not all such code can be simply copy&pasted in as 2D Input.

In particular I had used the infix form of an inert operator call, eg.
    foo %* bar

That infix syntax is not supported at present in 2D Input mode. But you can instead use the prefix form call in 2D Input mode, eg.
    `%*`(foo,bar)

Download solve_trigh_2Dmath.mw

@Thomas Dean I'd prefer my second way, which works even in old Maple 16,

Download ut_M16.mw

@srwarner 

You should provide at least one complete example, showing all all its programmatic input, and describing clearly all that you want to be able to accomplish programmatically. If it's only a toy example then you should describe the broader class you want to handle.

This is a long Question thread, but I haven't seen any such clear and comprehensive description here.

@srwarner 

Download inequality_basic.mw

@Rotcev Each of us was a novice user at some time. Your questions are welcome. This is a good question.

But I'm not sure that I've properly conveyed the difficulty to you.

The central issue here is that the following Maple expression will not persist, using the ususal multiplication and power calls:

     (2*a*Pi)^(1/4)

As soon as that is entered or arises during a computation the factor of 2^(1/4) is separated from the rest.

That is a kind of canonicalization that assists Maple's performance. It happens automatically. It cannot be prevented by using uneval-quotes.

You can, however, constructs something else (an inert form, say) that happens to render as you want. But it would not be the same object as your original expression, and you could only interact and further compute with it if you first turned it back into the form that you don't like. It would only be useful for display purposes. Is that what you would like?

@rzarouf You can simply use strings for the legend items, and avoid any clash with the command names.

The following attachment also does the "x" and "y" axis labels.

[edit] I also changed the return value of your P0 procedure, so that the order of the plots and legend items is consistent, by using a list rather than a set. Adjust the list, to force the order of your choice.

rzarouf_03_ac.mw

ps. I only used eps=1e-5 before because all these hold:
   1) Your question didn't show us what value you intended for it.
   2) The value of eps (and the appearance of the curves) is not
       relevant to your whole size/scale/ranges question.
   3) It runs faster.

By the way, I suspect that the execution speed of your code can be improved. Unfortunately I don't have much spare time to do that right now.

When I introduced units-handling into my phasor stuff I got a little over-enthusiastic with some (perhaps dubious) idea of temporarily converting floats to exact rationals.

Your example shows a case where it incorrectly handles that: ie. failing to turn such rationals back into floats.

The whole phasor-as-object thing was mostly my investigating whether objects as algebraic expressions (in the Maple type sense) was generally workable. So I got a little "creative" in spots.

I can try and fix up my phasor code, especially with respect to units & floats, and get back to you here about it. Unfortunately it won't be this week, and it'll take some time that I don't have available right now.

As far as initialization goes, would you rather,
1) put a call to read this (from a source file) in an initialization file
2) Save it into its own .mla archive and,
  2a) adjust libname to see that, in an initialization file
  2b) place that .mla in a special location that gets added to libname automagically
?

Thanks for your example.

@Christian Wolinski I don't agree with this claim, and I don't think that the reasoning portion is correct.