Le tout debut c'est d'avoir un modele mathematique precis - sans ca, Maple ne peut pas vraiment aider.

You don't need all the calls to assume to generate the same ''problem''. The issue here is that the powering operator (^) is a data-structure constructor which does not automatically "do" anything. Your various calls *return* a call to that constructor.
`sqrt`

on the other hand is a Maple function, which does do computations - and knows that sqrt(4) = 2. The fact that Maple *displays* them the same is certainly a huge source of confusion for many users, including advanced users.
`simplify`

just happens to know that the data-structure constructor (^) corresponds to 'powering', and so can apply various rules of powering. But that is really a sledge-hammer.

`has`

is a purely syntactic check. Its only advantage is that it is very fast.
`depends`

is a partially semantic check, in that it rules out "dummy variables". Many things in Maple act like binders. The obvious ones and `sum, Sum, int, Int`

, but so do the 2-argument versions of `eval`

(and its inert cousin, the rarely used `Eval`

), the integral transforms, `ztrans`

, and so on. Probably some stuff in the new packages are binding operations too, yet depends does not seem to know about all of these (yet).
Of course depends is not fully semantic, since in general 'dependence' is undecidable (it can be reduced to zero equivalence). So depends chooses a useful middle ground.

Have you looked at GF[ConvertIn] ?

First, I would 'float out' the Heaviside/min/max functions out, to completely separate out the geometry and the algebra. Then, one can apply techniques from computational commutative algebra for the intersection of algebraic surfaces, and various other techniques to deal with the geometry.
As others have asked, an actual example would help a lot.

See

this blog post" for a link to how older software often seems to perform better than newer.
Clearly a lot of effort has been put on new innovative features in Maple 11 -- but less on ensuring that the old features work at least as well, if not better, than they used to.

If lb was a local in the computation that generated this result, then it will not be equal to the global 'lb'. Also, if the original lb contained assumptions (but was global), it can be tricky to save it, re-read it in, and then use subs on it.
You might be better off using unapply and saving a procedure rather than an expression.

This case had no nesting, so a pure select with type as Shivnorr points out [and is rightly indignant at seeing 'hastype' recommended]. More generally, this can be done with `indets(k,'sqrt')`

which will "pick out" the sqrt function(s). Try it on
sqrt(1+sqrt(x)) + sin(sqrt(y))-exp(x^2+y^2) to see what I mean.

Appears to be in `int/cook/IIntd1`, which is a pattern-matching routine. Doing
infolevel[int] := 10
clearly shows that this routine notices that there is something fishy going on, but apparently the 'fix' is incomplete. This code appears to be trying too hard to give (finite) answers, and does not detect that this particular integral is definitely divergent.
A quick indefinite integral + limits shows that the ``answer'' is really infinity - a^2, which for all finite a is just infinity.

Try using 'worksheet mode' instead of 'document mode' in the GUI [or use Classic] and &^ will work fine. This is a bug in the GUI, where &^ is not recognized as a token by the equation editor.
Or you can enter it awkwardly as
##### &\^ #### mod ###

Since so many people had such fun with functional solutions to this problems, I figured I would give an imperative version, but based on generators. The version below is nice because it is conceptually easy to understand.

tt := proc(LL) local T, Q, i;
T := combinat[cartprod](LL);
Q := table();
for i from 0 while not T[finished] do Q[i] := `+`(op(T[nextvalue]())) od;
convert(Q,'list');
end proc;

Challenge: can a version using foldl but

not seq be done?

The problem seems related to declaring b and v to be global, and then also assuming and unassigning them, all in the same procedure.
Now, I tried to make your procedure more Maple-like, but eventually gave up since I did not really know exactly what you were trying to achieve. Which brings me to the real question: what are you really trying to do here?

You probably are in the case where a,b and c are positive - so tell Maple! You will find that
`assume(a>0, b>0, c>0); simplify(ln(a*b^c));`` works like a charm. It just happens to be that that ``simplification'' is false in general, so Maple quite rightfully refuses to do it.`

```
```

```
```
Another thing to look into is applying `codegen[prep2trans]`

(ie 'prepare to translate') first. This routine takes care of dealing with many issues that foil codegen (and CodeGeneration).

Robert is correct that this conversion is (still) done by the automatic simplifier, so that it is pretty much impossible to stop that from happening. There are hacks one can use to be able to *display* such a thing, but these are not really viable since the resulting expression no longer 'composes' with anything else.
In this case, `combine`

encounters the same problem. I would not be surprised if some of the combine code actually did try to perform what you want, only to be foiled by the automatic simplifier.
The reasons for this lie in the very distant past, and the reasons had something to do with efficiency (on a Honeywell machine that would probably make your cell phone look like a supercomputer). Some of these issues have been fixed in Maple (Maple V Release 2 and Maple 6 coming to mind), with a few more smaller issues stealthily fixed in Maple 8 (?), but as you can tell, some remain.