30172 Reputation

29 Badges

18 years, 233 days
Ontario, Canada

Social Networks and Content at

MaplePrimes Activity

These are answers submitted by acer

If you mean an object in Maple's own technical use of the term, then yes.

The object module can have its own ModulePrint command. (Unfortunately there's only one example on the ModulePrint Help page, and it's not a very interesting example.)

Here are a couple of examples from the GroupTheory package.



G := CyclicGroup( 14 );



ModulePrint := proc(self)
local C;
   1   if IsWorksheetInterface("Standard") then
   2       Typesetting:-msub(Typesetting:-mi("C"),Typesetting:-mn(convert(self
   3       C := `tools/gensym`("C");
   4       C[self:-n]
       end if
end proc

g1 := Group({[[1,2]], [[1,2,3],[4,5]]});



ModulePrint := proc(self, $)
local gen, cyc;
   1   if self:-generator_list = undefined then
   2       nprintf("Ca permutation group on %d letter%sD",self:-n,ifelse(
             self:-n = 1,"","s"))
       elif GroupTheory:-PermutationGroupImplementation:-`small?`(`+`(op(
         map(function:-perm_supplen,self:-generator_list)))) then
   3       if IsWorksheetInterface("Standard") then
   4           Typesetting:-mfenced(op(map(proc( gen )
                   local cyc;
                   if gen = [] or gen = Perm([]) then
                   elif type(gen,'Perm') then
                         Typesetting:-mn@convert,cyc,':-string'))),cyc = gen))
                   end if;
               end proc,self:-generator_list)),':-open' = "⟨",':-close' =
   5           `tools/gensym`("<,>")(op(map(g -> `if`(type(g,'Perm'),:-
           end if
   6       nprintf(
             "Ca permutation group on %d letter%s with %d generator%sD",
             self:-n,ifelse(self:-n = 1,"","s"),:-numelems(self:-
             generator_list),ifelse(:-numelems(self:-generator_list) = 1,"",
       end if
end proc




The lack of automatic combining/simplification of units in the resulting Vector seems related to using elementwise +~ . If I instead use good ol' map then it automatically combines. I'll submit a report about that aspect.

I'd have expected to see a result where the Res2 entries were in terms of Unit(s) the default unit for dimension length in the default SI system.

If I set the default unit for dimension length to minutes (instead of seconds in the default SI system) then the top-level arithmetic automatically gets to Unit(min) here.

I don't know how that'd pan out for more involved examples that you might have.

The following attachment contains as much as I was able to recover.

Your original was last saved with Maple 2023. I suggest you upgrade to Maple 2024, if possible, as it seems to have less instances of this kind of problem.

Up until Maple 2022.2 simplify would apply the custom routine separately to any non-numeric side of an equation.

Hence, even when the extension mechanism was previously working, your example's (rhs-lhs) is misplaced since the custom procedure doesn't receive a whole equation.

Here I use M2022.2,


eq := (a*x + b)/(c*x + d) = 1:

`simplify/nodenom`:= x -> (numer@(lhs - rhs) = 0)(x):

simplify(eq, nodenom);

{--> enter \`simplify/nodenom\`, args = (a*x+b)/(c*x+d)

<-- ERROR in \`simplify/nodenom\` (now in \`simplify/do\`) = invalid input: %1 received %2, which is not valid for its %-3 argument, %4, lhs, (a*x+b)/(c*x+d), 1, expr}

Error, (in evalapply) invalid input: lhs received (a*x+b)/(c*x+d), which is not valid for its 1st argument, expr


`simplify/F` := u->G(u):

eq := (a*x + b)/(c*x + d) = 11/3:
simplify(eq, F);

G((a*x+b)/(c*x+d)) = 11/3

eq := (a*x + b)/(c*x + d) = sqrt(2):
simplify(eq, F);

G((a*x+b)/(c*x+d)) = G(2^(1/2))

eq := (a*x + b)/(c*x + d) = y:
simplify(eq, F);

G((a*x+b)/(c*x+d)) = G(y)


So even where that classic extension mechanism for simplify was functioning it seems like not what you're after, because of this mapping to both sides of equations rather than treating them whole.

In Maple 2023.2 and 2024.0 those examples are not invoking the custom routine at all. (I haven't tracked down the precise reason, perhaps in `simplify/do`. It does check that `simplify/denom` is the name of a procedure, rather than throw an error about an unexpected argument to simplify. I will submit a bug report against that regression, but as explained a fix for that wouldn't help your example.)

The mechanism (when previously not busted) does operate on unevaluated function calls to But that just makes more acute the following query, which could be asked regardless: What would be the benefit to you of calling simplify(eq, nodenom) when you could just as easily name the custom proc something shorter and apply it directly?

Are these the kinds of things you're trying to accomplish?


f := -4*sin(x) + 2*exp(y^2) + 5 - 5*cos(x^3)*sin(y^2) + 5*sinh(x^2);


p := proc(e)
end proc:








p(sinh(x^3)); # NULL


q := proc(e)
end proc:


{-5*cos(x^3)*sin(y^2), -4*sin(x)}


{-5*cos(x^3)*sin(y^2), 2*exp(y^2), -4*sin(x), 5*sinh(x^2)}


[{-5*cos(x^3)*sin(y^2), -4*sin(x)}, {-5*cos(x^3)*sin(y^2)}, {5*sinh(x^2)}, {2*exp(y^2)}]


If your Matrix M is datatype=float[8] then you could accelerate using either evalhf or Compile.

I use one of dharr's quicker procedures for the evalhf variant, but now faster.

The Compiled version is about 30 times faster than the "original"; it varies by run, and version.

I keep the original non-hardware-datatype constructions only for comparison.



`Maple 2015.2, X86 64 LINUX, Dec 20 2015, Build ID 1097895`

N := 10^5:
L := 5:
M := LinearAlgebra:-RandomMatrix(N, L, generator=0..1):

P := [1,0,1]:
nC := numelems(P):


[2, 4, 5]


pattern := proc(n) local k;
  `if`(evalb(`and`(seq(M[n, C[k]]=P[k], k=1..nC))), 1, 0);
end proc:
t0 := time[real]():
add(pattern(n), n=1..N);



Suppose we had instead constructed the data this way.


  local k;
  for k to nC do
    if M[n,C[k]]<>P[k] then return 0 end if;
  end do;
end proc:
t0 := time[real]():

trunc(evalhf(add(pattern(n,nC,M8,C8,P8), n=1..N)));



Suppose we had instead construced the data in this way


  local n::integer, k::integer, S::integer, ok::integer;
  S := 0;
  for n from 1 to N do
    ok := 1;
    for k to nC do
      if M[n,C[k]]<>P[k] then k := nC; ok := 0; end if;
    end do;
    if ok=1 then S := S + 1; end if;
  end do;
end proc:

cpattern:=Compiler:-Compile(pattern, 'inmem'=false):
t0 := time[real]():




These are just toy examples, deliberately intended for illustration and comparison rather than some "best" way to do the computation. (Please don't respond with a better way to do it. That's not my point.)

One possibility is to split out your purely floating-point and evalhf'able computations into their own dedicated procedure(s), and then do any non-evalhf'able or symbolic operations separately. I don't bother showing that for the following example, because it's trivial.

But sometimes such splitting involves complicated rewriting of one's existing procedures (which already mix those two aspects in more involved ways). Sometimes one of the following simpler code revisions is possible instead of such inconvenience.

No special acceleration.

f0 := proc()
  local x,res,y;
  res := add( sin(1.0*x), x=1..10^5);
  res + fsolve(y^3-1);
end proc:
CodeTools:-Usage( f0() );

memory used=0.62GiB, alloc change=33.00MiB, cpu time=4.38s, real time=4.39s, gc time=337.42ms


A procedure can "escape" evalhf mode temporarily, even for
non-evalhf'able computation (which returns a float result or NULL,
yet which might internally use some symbolic names), by using eval.

f1 := proc()
  local x,res,y;
  res := add( sin(1.0*x), x=1..10^5);
  res + eval(fsolve(y^3-1));
end proc:
CodeTools:-Usage( evalhf(f1()) );

memory used=2.86MiB, alloc change=0 bytes, cpu time=35.00ms, real time=36.00ms, gc time=0ns


By having option hfloat on the procedure, its float computations
get done using HFloat's, which can be fast because quite a lot of
arithmetic, and elementary functions can deal with those quickly.

It's not as fast as operating in evalhf mode, but often can be faster
for some basic floating-point computations than when done with no
special acceleration.

f2 := proc()
  option hfloat;
  local x,res,y;
  res := add( sin(1.0*x), x=1..10^5);
  res + fsolve(y^3-1);
end proc:
CodeTools:-Usage( f2() );

memory used=12.28MiB, alloc change=2.00MiB, cpu time=114.00ms, real time=114.00ms, gc time=8.30ms





TSelided := proc(ee, L:=infinity) local foo, oldom, u;
   oldom := kernelopts(':-opaquemodules'=false);
   try foo := SubexpressionMenu:-truncateTypeMK(ee, L);
   catch: finally kernelopts(':-opaquemodules'=oldom); end try;
end proc:

QQFProj := proc(q12::algebraic, q23::algebraic,
                q34::algebraic, q14::algebraic,
                prnt::boolean:=true, #{columns:=[QQFproj,Q13proj,Q24proj]}
  description "Projective quadruple quad formula and intermediate 13 and 24 quads.
               Useful for cyclic quadrilaterals";
  local qqf,q13,q24, sub1,sub2,sub3, R,values,DF,lens;
  uses DocumentTools;
  sub1:= (q12 + q23 + q34 + q14)^2 - 2*(q12^2 + q23^2 + q34^2 + q14^2) ;
  q13:=((q12-q23)^2-(q34-q14)^2)/(2*(q12+q23-q34-q14-2*q12*q23+2*q34*q14));#check this
  q24:=((q23-q34)^2-(q12-q14)^2)/(2*(q23+q34-q12-q14-2*q23*q34+2*q12*q14));#check this
  if prnt then
   DF:=DataFrame(TSelided~(<values>,L), columns=[`"Values Equations"`],
                 rows=[`#1  QQF`,`#2  Q13`,`#3  Q24`]);
   lens := [4 +8* max(op(length~(RowLabels(DF)))),
   Tabulate(DF,width=add(lens),widthmode = pixels,weights = lens);
  end if;
  return qqf,q13,q24
end proc:


q12:=1/2:q23:=9/10:q34:=25/26:q41:=9/130: #Cyclic quadrilateral


Q := [QQFProj(q12,q23,q34,q41,true)];





(((1/2)*(17+a)^(1/2)+(1/10)*(r^2+t^2)^2+(1/26)*a^4+(2/13)*a^3*b+(2/13)*a^3*c+(3/13)*a^2*b^2+(6/13)*a^2*b*c+(3/13)*a^2*c^2+(2/13)*a*b^3+(6/13)*a*b^2*c+(6/13)*a*b*c^2+(2/13)*a*c^3+(1/26)*b^4+(2/13)*b^3*c+(3/13)*b^2*c^2+(2/13)*b*c^3+(1/26)*c^4+(1/130)*(17+b)^(1/2))^2-35921/4225-(1/2)*a-(1/50)*(r^2+t^2)^4-2*((1/26)*a^4+(2/13)*a^3*b+(2/13)*a^3*c+(3/13)*a^2*b^2+(6/13)*a^2*b*c+(3/13)*a^2*c^2+(2/13)*a*b^3+(6/13)*a*b^2*c+(6/13)*a*b*c^2+(2/13)*a*c^3+(1/26)*b^4+(2/13)*b^3*c+(3/13)*b^2*c^2+(2/13)*b*c^3+(1/26)*c^4)^2-(1/8450)*b-(1/5)*(17+a)^(1/2)*(r^2+t^2)^2*((1/26)*a^4+(2/13)*a^3*b+(2/13)*a^3*c+(3/13)*a^2*b^2+(6/13)*a^2*b*c+(3/13)*a^2*c^2+(2/13)*a*b^3+(6/13)*a*b^2*c+(6/13)*a*b*c^2+(2/13)*a*c^3+(1/26)*b^4+(2/13)*b^3*c+(3/13)*b^2*c^2+(2/13)*b*c^3+(1/26)*c^4)-(1/650)*(17+a)^(1/2)*(r^2+t^2)^2*(17+b)^(1/2)-(1/65)*(17+a)^(1/2)*((1/26)*a^4+(2/13)*a^3*b+(2/13)*a^3*c+(3/13)*a^2*b^2+(6/13)*a^2*b*c+(3/13)*a^2*c^2+(2/13)*a*b^3+(6/13)*a*b^2*c+(6/13)*a*b*c^2+(2/13)*a*c^3+(1/26)*b^4+(2/13)*b^3*c+(3/13)*b^2*c^2+(2/13)*b*c^3+(1/26)*c^4)*(17+b)^(1/2)-(1/325)*(r^2+t^2)^2*((1/26)*a^4+(2/13)*a^3*b+(2/13)*a^3*c+(3/13)*a^2*b^2+(6/13)*a^2*b*c+(3/13)*a^2*c^2+(2/13)*a*b^3+(6/13)*a*b^2*c+(6/13)*a*b*c^2+(2/13)*a*c^3+(1/26)*b^4+(2/13)*b^3*c+(3/13)*b^2*c^2+(2/13)*b*c^3+(1/26)*c^4)*(17+b)^(1/2)+(1/325)*(17+a)^(1/2)*(r^2+t^2)^2*((1/26)*a^4+(2/13)*a^3*b+(2/13)*a^3*c+(3/13)*a^2*b^2+(6/13)*a^2*b*c+(3/13)*a^2*c^2+(2/13)*a*b^3+(6/13)*a*b^2*c+(6/13)*a*b*c^2+(2/13)*a*c^3+(1/26)*b^4+(2/13)*b^3*c+(3/13)*b^2*c^2+(2/13)*b*c^3+(1/26)*c^4)*(17+b)^(1/2))^2 = (8/325)*(17+a)^(1/2)*(r^2+t^2)^2*((1/26)*a^4+(2/13)*a^3*b+(2/13)*a^3*c+(3/13)*a^2*b^2+(6/13)*a^2*b*c+(3/13)*a^2*c^2+(2/13)*a*b^3+(6/13)*a*b^2*c+(6/13)*a*b*c^2+(2/13)*a*c^3+(1/26)*b^4+(2/13)*b^3*c+(3/13)*b^2*c^2+(2/13)*b*c^3+(1/26)*c^4)*(17+b)^(1/2)*(1-(1/2)*(17+a)^(1/2))*(1-(1/10)*(r^2+t^2)^2)*(1-(1/26)*a^4-(2/13)*a^3*b-(2/13)*a^3*c-(3/13)*a^2*b^2-(6/13)*a^2*b*c-(3/13)*a^2*c^2-(2/13)*a*b^3-(6/13)*a*b^2*c-(6/13)*a*b*c^2-(2/13)*a*c^3-(1/26)*b^4-(2/13)*b^3*c-(3/13)*b^2*c^2-(2/13)*b*c^3-(1/26)*c^4)*(1-(1/130)*(17+b)^(1/2))

TSelided(Q[1], 32);

(((1/2)*sqrt(17+a)+(1/10)*(r^2+t^2)^2+(1/26)*a^4+2*a^3*`&hellip;`*(1/13)+`&hellip;`)^2-`&hellip;`)^2 = `&hellip;`


You asked, "What is the problem?"

The problem is that the answer depends on the variables. The answer changes according to the signs of both a and b, even if all of a,b,h are taken as real.


r := a + (b - a)*z/h:

x1 := sqrt(r^2 - y^2):

The result depends on whether a and b are positive or negative.

simplify( int(int(int(1, x = -x1 .. x1), y = -r .. r), z = 0 .. h) )
   assuming h::real, a>0, b>0;


simplify( int(int(int(1, x = -x1 .. x1), y = -r .. r), z = 0 .. h) )
   assuming h::real, a<0, b>0;


simplify( int(int(int(1, x = -x1 .. x1), y = -r .. r), z = 0 .. h) )
   assuming h::real, a<0, b<0;



Your call InitState(5,5) calls Coherent(1,Pi/2,5) and that returns a 1-Vector.

Your call Coherent(5) returns a 5-Vector.

You've set up both InitState and Coherent with keyword parameters. You haven't set it up with optional ordered parameters.

When your InitState calls Coherent(1,Pi/2,5) then that "1" becomes the value of n_max (the first required positional parameter). The other two arguments, Pi/2 and 5, are thrown away. In particular, that's not the way to pass them along for the zeta and phi keyword parameters of your Coherent.

Perhaps you instead intended something like this?

InitState := proc({zeta:=1,phi:=Pi/2,L:=1,sigma:=0.01,beta:=0.02,k0:=-5*Pi},d1,d2) 
  local z1, Z0;
  z1 := Coherent(d1,':-zeta'=zeta,':-phi'=phi);
end proc:

That would utilize the value of d1 for the required parameter of Coherent. It would also pass along the values of zeta and phi to Coherent.

See next attachment for more detail.

If you wanted to use optional ordered parameters instead of keyword options then you'd also have to shift the required positional parameters to the front. See next attachment. Notice the absence of {...} braces around the declarations.

See also here.

Your previous Question was marked as Maple 2023, so I'm guessing that's the version you're using now.

In Maple 2024.0 the plot3d command supports the colorbar option (introduced for 2D plots in M2023).

But in fact one can attach a COLBAR plotting substructure into a PLOT3D plotting structure, even in M2023.

In the following example the image of the plot is from a single file that I manually exported using right-click. That single image file contains both surface and colorbar.

Here I used the 2D contourplot command as a quick way to construct the colorbar. But it sound as if you've already constructed your own 2D color-bar (for use in your Tabulate). Just wrap that 2D color-bar plot in a call to COLBAR, display that to the desired smaller size, and add that as a last argument to the PLOT3D structure.



`Maple 2023.2, X86 64 LINUX, Nov 24 2023, Build ID 1762575`

ars := sin(x*y), x=-3..3, y=-3..3, colorscheme=["Red","Green","Blue"]:



You cannot do it directly as some option to Tabulate.

But you can programmatically get a zoom by using some of the internal commands which Tabulate uses, and making use of an additional option of the InlinePlot constructor.

with(plots,display): with(plottools,cylinder):

c1 := display(cylinder([1, 1, 1], 1, 3), orientation = [45, 70],
              scaling = constrained, color = red, size = [300, 300]):
c2 := display(cylinder([1, 1, 1], 1, 3), orientation = [45, 70],
              scaling = constrained, color = blue, size = [300, 300]):

with(DocumentTools): with(DocumentTools:-Layout):

  Table(exterior = none, interior = none,
        Row(Cell(InlinePlot(c1, scale = 1.7)),
            Cell(InlinePlot(c2, scale = 0.4)))))):

However, I'm not sure that the size=[300,300] will be preserved properly upon worksheet Close/Reopen. It's possible the DocumentTools:-Components could also be used, with the Layout:-InlinePlot call further wrapped in a Components:-Plot call that forced the 300x300 dimensions as width and height. Then suppress the component boundaries, etc. (Sorry, I was once more familiar with these subtleties, but it's been a while...)

I would not be surprised if Edgardo puts a fix into a Physics update.

But, here is a hot patch (for Maple 2024.0) that lets ODESteps handle that example.


Student:-ODEs:-IVPOrder1:=FromInert(subs(_Inert_FUNCTION(_Inert_ASSIGNEDNAME("indets", "PROC", _Inert_ATTRIBUTE(_Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))))), _Inert_EXPSEQ(_Inert_LOCAL(6), _Inert_NAME("name", _Inert_ATTRIBUTE(_Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected")))))))=_Inert_FUNCTION(_Inert_ASSIGNEDNAME("indets", "PROC", _Inert_ATTRIBUTE(_Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))))), _Inert_EXPSEQ(_Inert_LOCAL(6), _Inert_FUNCTION(_Inert_NAME("And", _Inert_ATTRIBUTE(_Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))))), _Inert_EXPSEQ(_Inert_NAME("name", _Inert_ATTRIBUTE(_Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))))), _Inert_FUNCTION(_Inert_NAME("Not", _Inert_ATTRIBUTE(_Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))))), _Inert_EXPSEQ(_Inert_NAME("constant", _Inert_ATTRIBUTE(_Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))))))))))),ToInert(eval(Student:-ODEs:-IVPOrder1)))):



`Maple 2024.0, X86 64 LINUX, Mar 01 2024, Build ID 1794891`



diff(y(x), x)+x*y(x) = 1

y(0) = 0


y(x) = -((1/2)*I)*exp(-(1/2)*x^2)*Pi^(1/2)*2^(1/2)*erf(((1/2)*I)*2^(1/2)*x)


"[[,,"Let's solve"],[,,[(&DifferentialD;)/(&DifferentialD;x) y(x)+x y(x)=1,y(0)=0]],["&bullet;",,"Highest derivative means the order of the ODE is" 1],[,,(&DifferentialD;)/(&DifferentialD;x) y(x)],["&bullet;",,"Isolate the derivative"],[,,(&DifferentialD;)/(&DifferentialD;x) y(x)=-x y(x)+1],["&bullet;",,"Group terms with" y(x) "on the lhs of the ODE and the rest on the rhs of the ODE"],[,,(&DifferentialD;)/(&DifferentialD;x) y(x)+x y(x)=1],["&bullet;",,"The ODE is linear; multiply by an integrating factor" mu(x)],[,,mu(x) ((&DifferentialD;)/(&DifferentialD;x) y(x)+x y(x))=mu(x)],["&bullet;",,"Assume the lhs of the ODE is the total derivative" (&DifferentialD;)/(&DifferentialD;x) (mu(x) y(x))],[,,mu(x) ((&DifferentialD;)/(&DifferentialD;x) y(x)+x y(x))=((&DifferentialD;)/(&DifferentialD;x) mu(x)) y(x)+mu(x) ((&DifferentialD;)/(&DifferentialD;x) y(x))],["&bullet;",,"Isolate" (&DifferentialD;)/(&DifferentialD;x) mu(x)],[,,(&DifferentialD;)/(&DifferentialD;x) mu(x)=mu(x) x],["&bullet;",,"Solve to find the integrating factor"],[,,mu(x)=(e)^((x^2)/2)],["&bullet;",,"Integrate both sides with respect to" x],[,,[]=&int;mu(x) &DifferentialD;x+C1],["&bullet;",,"Evaluate the integral on the lhs"],[,,mu(x) y(x)=&int;mu(x) &DifferentialD;x+C1],["&bullet;",,"Solve for" y(x)],[,,y(x)=(&int;mu(x) &DifferentialD;x+C1)/(mu(x))],["&bullet;",,"Substitute" mu(x)=(e)^((x^2)/2)],[,,y(x)=(&int;(e)^((x^2)/2) &DifferentialD;x+C1)/((e)^((x^2)/2))],["&bullet;",,"Evaluate the integrals on the rhs"],[,,y(x)=(-(&ImaginaryI; sqrt(Pi) sqrt(2) erf(&ImaginaryI;/2 sqrt(2) x))/2+C1)/((e)^((x^2)/2))],["&bullet;",,"Simplify"],[,,y(x)=-((&ImaginaryI; sqrt(Pi) sqrt(2) erf(&ImaginaryI;/2 sqrt(2) x)-2 C1) (e)^(-(x^2)/2))/2],["&bullet;",,"Use initial condition" y(0)=0],[,,0=C1],["&bullet;",,"Solve for" `c__1`],[,,C1=0],["&bullet;",,"Substitute" `c__1`=0 "into general solution and simplify"],[,,y(x)=-&ImaginaryI;/2 (e)^(-(x^2)/2) sqrt(Pi) sqrt(2) erf(&ImaginaryI;/2 sqrt(2) x)],["&bullet;",,"Solution to the IVP"],[,,y(x)=-&ImaginaryI;/2 (e)^(-(x^2)/2) sqrt(Pi) sqrt(2) erf(&ImaginaryI;/2 sqrt(2) x)]]"




One thing that it shows is that the two results of using alone either simplify or combine coincide, since the set of two identical results has collapsed to a set with only one member.

{simplify,combine}(piecewise(x <= 0, 2*ln(1 - x), 0 < x, ln((x - 1)^2))) assuming (x, real);


[simplify,combine](piecewise(x <= 0, 2*ln(1 - x), 0 < x, ln((x - 1)^2))) assuming (x, real);


[ln((x-1)^2), ln((x-1)^2)]


The sentence pertaining to this example in the Maple 2024 Advanced Math What's New page is [emphasis mine],

   "In Maple 2024, simplify and combine are both now better at
    recognizing when two piecewise branch values can be merged into one:"

I think that the main gist of that sentence is that simplify and combine are each separately ("alone") better at dealing with this example.

This is not a bug. Rather, it's a frequently asked question.

The sum command relies on Maple's standard evaluation rules for procedure calls, in which all the arguments are evaluated up front. But before p takes on actual integer values the first argument being passed to sum is actually zero.

In contrast, the add command has special evaluation rules, in which case evaluation of its first argument is delayed until the summing-index name p takes on its actual values.


e[1] := (t,x,y,z)-> vector(4,[1,0,0,0]):
e[2] := (t,x,y,z)-> vector(4,[0,1,0,-6*z^4*(1-z)^3*(1-x^2)^2*(1-y^2)^3*x]):
e[3] := (t,x,y,z)-> vector(4,[0,0,1,-6*z^4*(1-z)^3*(1-x^2)^3*(1-y^2)^2*y]):
e[4] := (t,x,y,z)-> vector(4,[0,0,0,1-z^3*(7*z-4)*(z-1)^2*(y^2-1)^3*(x^2-1)^3]):

lie := (j,u,v)-> u[1]*diff(v[j],t)-v[1]*diff(u[j],t)+u[2]*diff(v[j],x)-v[2]*diff(u[j],x)


cf:=(k,l,m,t,x,y,z) -> seq(lie(p,e[k](t,x,y,z),e[l](t,x,y,z))*G(t,x,y,z)[p,m],p=1..4):

Warning, (in cf) `p` is implicitly declared local

cf1:=(k,l,m,t,x,y,z) -> sum(lie(p,e[k](t,x,y,z),e[l](t,x,y,z))*G(t,x,y,z)[p,m],p=1..4):



cf2:=(k,l,m,t,x,y,z) -> add(lie(p,e[k](t,x,y,z),e[l](t,x,y,z))*G(t,x,y,z)[p,m],p=1..4):

Warning, (in cf2) `p` is implicitly declared local



This is what gets passed to sum, which does not have special evaluation rules.



cf3:=(k,l,m,t,x,y,z) -> sum('lie'(p,e[k](t,x,y,z),e[l](t,x,y,z))*G(t,x,y,z)[p,m],p=1..4):





1 2 3 4 5 6 7 Last Page 1 of 313