[Sorry for the wait, I've been crazy-busy; I will be away for most of the next 2 weeks, so expect answers to remain slow]

Your reasoning seems sound, and yet it isn't necessarily useful!  The point is that Maple has no well-integrated facility for integration over arbitrary shapes [although it does have some, but they are well hidden].  In other words, the "most useful" problem to solve is how to take an integral of the form int(int(f(x,y),y=a(x)..b(x)),x=c..d) and turn it into int(int(g(u,v),u=a1(v)...a2(v)),v=c1..d1).  For quadilaterals which are not axis-aligned, your method is no so straightforward to apply.  Working out the details is no hard, but it is nevertheless more subtle than at first appears.

Note that in this way of looking at the problem, the degeneracy conditions are actually a fair bit easier to check!

I have already sent email to the author of that particular piece of code, and he is looking at it.  I think he'll take care of filing a report himself [he usually does].

This bug is surprising - there are few bugs in Maple which are quite so 'basic' [in the mathematics, other areas are newer and buggier].  This is why I investigated it as soon as I saw it, and sent it off to the right developer too. 

I have already sent email to the author of that particular piece of code, and he is looking at it.  I think he'll take care of filing a report himself [he usually does].

This bug is surprising - there are few bugs in Maple which are quite so 'basic' [in the mathematics, other areas are newer and buggier].  This is why I investigated it as soon as I saw it, and sent it off to the right developer too. 

Sorry, Maple-ese: FTOC = Fundamental Theorem of Calculus.

Sorry, Maple-ese: FTOC = Fundamental Theorem of Calculus.

A few comments on the various posts:

• Jakubi's intuition is absolutely right, to find a 'useful' change of coordinates, symmetries are one of the most useful methods.  Unfortunately, that wasn't at all what I was asking for.  I really meant: given a specific transformation of coordinates, how does one rewrite the bounds?
• What Axel did was right, but he hid exactly the hard part: how to go from -infinity..infinity X -infintiy..infintiy to 0..infinity X -Pi..Pi ?  We all know how to do this, but can this be generalized?
• I don't think the problem is quite as hard as generalized visualization
• Robert definitely is thinking along the same lines I was.

Ok, let's be more specific.  Let's consider something simple: a 2D integral over a domain 0..1 X 0..1 and a linear change of coordinates given by a 2x2 matrix A.  We know exactly how to change the integrand f(x,y) into f(u,v) *|det(A)| via A.  But how does the boundary change?  What conditions on A must be imposed for this to make sense?  This should generalize to n-dimensional integrals and a linear change of coordinates over an arbitrary rectangle R fairly easily.  This should be the first case to be worked out in full detail.

The next case to work out is problably the ``rectifying transformation'', that is a 2D integral like

int(int(f(x,y), x=a(y)..b(y)),y=c..d)

where we try to simultaneously 'straighten' a and b [one definitely needs to impose conditions on a and b for this to be possible!].

Another case to work out in detail is how some particular domains transform under rectangular <-> polar coordinate transforms.

I have both those great books too.  And note that there is one thing you are missing (in the n-dimensional case with n>1): How do you write the transformation from domain V to domain W?

In other words, the hard part is to go from a description of a domain V using one set of coordinates and get a description of W in the new coordinates after the change of variables.  In the 1-D case, phi^(-1) works fine; in general, you still have W=(phi@@(-1))(V), but the hard part is to make that explicit.

For some classes of phi, I think I know how to make this work.

See the end of the help page 'coords', they are listed there.  It would be nice if there was a link at the top of that page to get down to the 2D systems faster.

There are other projects out there that we might consider joining and/or talk to.  In particular I am thinking of PlanetMath, MathWeb and The Hyperreal Dictionary of Mathematics,  I have met the people behind PlanetMath and know some of the ones behind MathWeb fairly well.

Would it make sense for me to contact the MathWeb principals and ask them about hosting a community-driven Maple wiki?  I think we might get a freer hand in developing that Wiki into a useful resource than trying to shoehorn ourselves into wikibooks.

In the absence of external specifications, then a design can be (optimistically) called 'right' if:

1. It provides functionality that users deem to be useful
2. It provides functionality that users deem to be intuitive
3. The design ``fits'' with the rest of the system
4. The functionality can be re-used by the system

Note that 1+2 and 4 often clash, and this clash must be resolved somehow.  It is not helpful to tell users

1. That they are wrong [often done when users want something to work over the reals but Maple insists on working over the complex]
2. That this works ``as designed'' -- if the functionality promises to solve a particular problem, but ``as designed'' it does not, then ``as designed'' is not useful now is it?
3. That a new package is the way of the future, even though it doesn't work with anything else [example: old stats package]

In other words, "right" is actually something rarely achieved, but to be strived for.  As you learn, old designs become less and less 'right' and need to be fixed.  Ossification is bad.

In the absence of external specifications, then a design can be (optimistically) called 'right' if:

1. It provides functionality that users deem to be useful
2. It provides functionality that users deem to be intuitive
3. The design ``fits'' with the rest of the system
4. The functionality can be re-used by the system

Note that 1+2 and 4 often clash, and this clash must be resolved somehow.  It is not helpful to tell users

1. That they are wrong [often done when users want something to work over the reals but Maple insists on working over the complex]
2. That this works ``as designed'' -- if the functionality promises to solve a particular problem, but ``as designed'' it does not, then ``as designed'' is not useful now is it?
3. That a new package is the way of the future, even though it doesn't work with anything else [example: old stats package]

In other words, "right" is actually something rarely achieved, but to be strived for.  As you learn, old designs become less and less 'right' and need to be fixed.  Ossification is bad.

That is another weakness in my reasoning.  [I find it fun to make some naive statement like I did above, especially as it is commonly made by others, and then slowly deconstruct it to find its flaws.]

That is another weakness in my reasoning.  [I find it fun to make some naive statement like I did above, especially as it is commonly made by others, and then slowly deconstruct it to find its flaws.]

This has come up a huge number of times now.  Maple's internal representation of many objects was optimized (based on knowledge readily available in 1980) for computational efficiency.  However, that means that some representations (ie syntactic object) are unavailable because some transformations are always applied.  These transformations are usually valid (but not always!) based on most semantic interpretations of the objects.

I have certainly learned that a proper system should separate these issues, and allow users such choices.  The difficulty then shifts to educating the users in how to get efficiency out of such a flexible environment.  LinearAlgebra is one example of this 2-layer design, and also of the difficulties in properly documenting both simple and advanced uses.  An older example of a similar 2-layer design is evalhf (although I believe that CodeGeneration[Compile] is a better way to solve that particular problem). 

This has come up a huge number of times now.  Maple's internal representation of many objects was optimized (based on knowledge readily available in 1980) for computational efficiency.  However, that means that some representations (ie syntactic object) are unavailable because some transformations are always applied.  These transformations are usually valid (but not always!) based on most semantic interpretations of the objects.

I have certainly learned that a proper system should separate these issues, and allow users such choices.  The difficulty then shifts to educating the users in how to get efficiency out of such a flexible environment.  LinearAlgebra is one example of this 2-layer design, and also of the difficulties in properly documenting both simple and advanced uses.  An older example of a similar 2-layer design is evalhf (although I believe that CodeGeneration[Compile] is a better way to solve that particular problem).