This is the problem:
Maple has defines the most common command to be something different and then returns meaningless results. You say that gcd and mod are for polynomials and that for integers, the most common case, we have to prefix i... That is ass-backwards.
gcd and mod should be for integer(of which mod can be generalized to real w.l.o.g.) and pgcd and pmod should then be used for polynomials...
One doesn't make the most common cause use the most uncommon syntax. In all number theory books they will define gcd and mod for integers, not polynomials... not until after the fact.
Also, the definition for the gcd and mod of polynomials extends that over integers, so maple is crapping out and producing invalid results when it is clear that this is an issue with maples design... not mine.
For example, suppose one day that the government decides to redefine red = go and green = stop... and then gives everyone a ticket and blames them for all the crashes.. Is this logical? Why should have have to learn to jump through hoops just because maple got it wrong?
More importantly, if the inputs in to these functions are not defined then how the hell can it make any decisions about anything?
No one has explained to me why gcd(a,b) returns 1 when a and b are not defined! It is immaterial if gcd only accepts polynomials. This would be a programming bug in any normal programming language. It's not correct behavior. The goal of any programming language(including maple) is not to make life for the programmer hell by having obscure side conditions that can be difficult to detect.
How many people do you think that come to maple for the first time and are fully familiar with mod outside of maple will know that it is meant for polynomials? Ok, fine, they will learn that it is for polynomials... but that doesn't then explain why gcd(a,b) = 1 when a and b are undefined.
This is like defining sin(x)/x = 432 when x = 0. It is illogical and counterproductive.
Maple is wrong in this case. Ideally it would be fixed. The fact that mod does work for explicit integers FURTHERS the problem because now mod is overload to work for integers in some cases and not others, but you tell me it only works for polynomials? What precisely is a polynomial to maple? is 3 not a polynomial? is q a polynomial?
These behaviors are wrong. Sure one can work around them, but the mere fact that one has to do so is why they are wrong.
I'm not talking about what maple does, it does what it does, I'm talking about what is logically correct... and in most cases what is logically correct is determined by precedence. If I open up the top 50 programming languages they all use mod in the exact same way and there is no problem. Maple chose to behave different for an arbitrary purpose that seems to only produce extra hoops. The main issue is that it silently gives invalid results rather than an error. That is unacceptable. How hard is it for maple to check if the arugments exist?