It depends on what you're trying to do with gamma. You could make it an ordinary variable if you remove it from "constants" and unprotect it. Thus:

> constants:= op(subs(gamma=NULL,[constants])):
  unprotect(gamma);

Of course this would not be a good idea if you're doing calculations where the Euler constant gamma is likely to come up.

It depends on what you're trying to do with gamma. You could make it an ordinary variable if you remove it from "constants" and unprotect it. Thus:

> constants:= op(subs(gamma=NULL,[constants])):
  unprotect(gamma);

Of course this would not be a good idea if you're doing calculations where the Euler constant gamma is likely to come up.

Try this:

> temp := [[a = 3, b = 23, c = 34, d = 1], 
         [a = 3, b = -3, c = 3, d = 2], 
         [a = 3, b = 32, c = 4, d = -5], 
         [a = 2, b = -3, c = -3, d = -4]]: 
  select(subs, temp, b > 0 and d > 0);

Try this:

> temp := [[a = 3, b = 23, c = 34, d = 1], 
         [a = 3, b = -3, c = 3, d = 2], 
         [a = 3, b = 32, c = 4, d = -5], 
         [a = 2, b = -3, c = -3, d = -4]]: 
  select(subs, temp, b > 0 and d > 0);

It's not a question of simplification. The definition of a module can contain all sorts of statements, which are executed when the module is defined. The result of that (the evaluation of the module definition) is the module itself, whose body will contain only the assignment statements giving the values of the module variables. For example:

> a:= 1: 
> M:= module() export A,B; A:= a+1; B:= a+2; end module:
> convert(eval(M),string);

"module () export A, B; A := 2; B := 3; end module"

I guess you're referring to this? Of course I don't know how this could be implemented in Maple.

OK, (y')^2 + y^3 = x is an ODE. Maple can find series solutions like this:

> de:= D(y)(x)^2 + y(x)^3 = x:
  dsolve({de,y(0)=a},y(x),series);

y(x) = a+RootOf(_Z^2+a,label = _L10)*a*x+(-1/4*(RootOf(_Z^2+a,label = _L10)+3*a^4)/a^2)*x^2+(-1/24*(RootOf(_Z^2+a,label = _L10)+12*RootOf(_Z^2+a,label = _L10)*a^7+3*a^4)/a^5)*x^3+1/64*(6*RootOf(_Z^2+a,label = _L10)*a^7-RootOf(_Z^2+a,label = _L10)-5*a^4+20*a^11)/a^8*x^4+1/640*(-5*RootOf(_Z^2+a,label = _L10)+120*a^14*RootOf(_Z^2+a,label = _L10)+58*RootOf(_Z^2+a,label = _L10)*a^7-10*a^11-35*a^4)/a^11*x^5+O(x^6) It looks a bit nicer if you substitute a symbol for the RootOf:

> eval(%,RootOf(_Z^2+a,label = _L10)=b);

y(x) = a+b*a*x+(-1/4*(b+3*a^4)/a^2)*x^2+(-1/24*(b+12*b*a^7+3*a^4)/a^5)*x^3 +1/64*(6*b*a^7-b-5*a^4+20*a^11)/a^8*x^4+1/640*(-5*b+120*a^14*b+58*b*a^7-10 *a^11-35*a^4)/a^11*x^5+O(x^6) where b = `±`*sqrt(-a)

OK, (y')^2 + y^3 = x is an ODE. Maple can find series solutions like this:

> de:= D(y)(x)^2 + y(x)^3 = x:
  dsolve({de,y(0)=a},y(x),series);

y(x) = a+RootOf(_Z^2+a,label = _L10)*a*x+(-1/4*(RootOf(_Z^2+a,label = _L10)+3*a^4)/a^2)*x^2+(-1/24*(RootOf(_Z^2+a,label = _L10)+12*RootOf(_Z^2+a,label = _L10)*a^7+3*a^4)/a^5)*x^3+1/64*(6*RootOf(_Z^2+a,label = _L10)*a^7-RootOf(_Z^2+a,label = _L10)-5*a^4+20*a^11)/a^8*x^4+1/640*(-5*RootOf(_Z^2+a,label = _L10)+120*a^14*RootOf(_Z^2+a,label = _L10)+58*RootOf(_Z^2+a,label = _L10)*a^7-10*a^11-35*a^4)/a^11*x^5+O(x^6) It looks a bit nicer if you substitute a symbol for the RootOf:

> eval(%,RootOf(_Z^2+a,label = _L10)=b);

y(x) = a+b*a*x+(-1/4*(b+3*a^4)/a^2)*x^2+(-1/24*(b+12*b*a^7+3*a^4)/a^5)*x^3 +1/64*(6*b*a^7-b-5*a^4+20*a^11)/a^8*x^4+1/640*(-5*b+120*a^14*b+58*b*a^7-10 *a^11-35*a^4)/a^11*x^5+O(x^6) where b = `±`*sqrt(-a)

Jacques, you seem to have a typo here: it should have been

> eq3 := eval(eq, y=( z-> a0+a1*z+a2*z^2 + O(z^3))): 

And then MultiSeries:-series returns O(x^0), which I think is pretty much to be expected: knowing y(x) to O(x^3) tells you nothing much about D(y)(6*x+4).

Jacques, you seem to have a typo here: it should have been

> eq3 := eval(eq, y=( z-> a0+a1*z+a2*z^2 + O(z^3))): 

And then MultiSeries:-series returns O(x^0), which I think is pretty much to be expected: knowing y(x) to O(x^3) tells you nothing much about D(y)(6*x+4).

Most of the time, when an expression has a free variable Maple produces results that are valid for "generic" values of that variable, disregarding specific values that may be problematic. So it will happily simplify (x^2+2*x+1)/(x+1) to x+1, disregarding the possibility that x=-1. It will do that even if you tell it to assume x=-1. Getting Maple to produce results that take into account special values of the variable for which the expression may be undefined, or may have a different value, is not simple. In general I'd advise against assuming x = something: you might get a good result in some cases, but not in others. It can be hard to predict where or how Maple will use this assumption. "abs" seems rather atypical here, because abs(x) assuming x = 0 returns 0, while for most functions f (e.g. sin) f(x) assuming x = 0 just returns f(x), even if f(0) has a special value.

I'm confused. Can you tell us the actual function you're trying to maximize, and on what domain?

I'm confused. Can you tell us the actual function you're trying to maximize, and on what domain?

Do you mean like this?

> G:= n -> add(convert(convert([97+i],bytes),name)*x^i,i=0..n);

It's not just a question of the ordering of phi and theta, but which angle is called phi and which is called theta. Physicists almost always (I think) use phi for the longitude and theta for colatitude, mathematicians do it the other way around. There is no agreement among math textbooks on the ordering of phi and theta.