@Preben Alsholm 

If this were the case for such a standard feature like email notifications, I would find it quite contradictory with the justification for switching from Drupal to Windows/Visual Studio:

To remedy this, we are going to switch the architecture to use the standard Windows/Visual Studio platform that we use for our other web endeavours.  Among other things, one of the primary benefits of this change is that we will have increased capacity within our web development team to troubleshoot and update the site.

@antoniuspisa 

As each factor f has a different dummy variable k, I would set it explicitelly and use instead:

f := (x,k) -> Int(fk(k)*exp(I*k*x), k = -infinity .. infinity):
Q:=Int(a(t)*f(x,k1)*f(x,k2), x = -infinity .. infinity);

@antoniuspisa 

As each factor f has a different dummy variable k, I would set it explicitelly and use instead:

f := (x,k) -> Int(fk(k)*exp(I*k*x), k = -infinity .. infinity):
Q:=Int(a(t)*f(x,k1)*f(x,k2), x = -infinity .. infinity);

@antoniuspisa 

There is a package IntegrationTools, sadly mostly limited to manipulating single integrals. For a multiple integral like your example:

J:=Int( Int(f1(k1)*exp(I*k1*x),k1=-infinity..infinity) * Int(g1(k2)*exp(I*k2*x),
k2=-infinity..infinity), x=-infinity..infinity):

this workaround can be used:

map(IntegrationTools:-GetIntegrand,IntegrationTools:-GetIntegrand(J)):
X,K:=selectremove(has,%,x):
RX,RK:=selectremove(has,indets(J,equation),x):
Int(K*Int(X,op(RX)),op(RK));

@antoniuspisa 

There is a package IntegrationTools, sadly mostly limited to manipulating single integrals. For a multiple integral like your example:

J:=Int( Int(f1(k1)*exp(I*k1*x),k1=-infinity..infinity) * Int(g1(k2)*exp(I*k2*x),
k2=-infinity..infinity), x=-infinity..infinity):

this workaround can be used:

map(IntegrationTools:-GetIntegrand,IntegrationTools:-GetIntegrand(J)):
X,K:=selectremove(has,%,x):
RX,RK:=selectremove(has,indets(J,equation),x):
Int(K*Int(X,op(RX)),op(RK));

@antoniuspisa 

This question is a FAQ, see e.g. this thread.

@antoniuspisa 

This question is a FAQ, see e.g. this thread.

Differences also occur between 1D and 2D input with multiple left single quotes, including an even-odd effect in 1D input, etc.

@acer 

If Maplesoft considers that 2D input mode is so useful for newcomers that will keep it, loosing 1D legacy code for that market may be seen as a minor inconvenience. In this scenario, I think that the divergence route is a less bad option than forcing reunification.

@acer

You have got it perfectly. This is a lobby campaign for pattern matching in Maple, either for the improvement of applyrule (correcting its many bugs and weaknesses) or for something better. The background is, in the terms of the talk Computer Algebra vs Symbolic Computation by Stephen M. Watt, that much of the development in Maple goes into Computer Algebra and too little into Symbolic Computation, something that I miss permanently.

At this point, I cannot avoid quoting myself, elsewhere, over eight years ago:

There are operations for which pattern matching techniques are by far the most natural and efficient way of doing them. I considered its introduction in R5 a step forward to cover a big weakness of Maple system in comparison with Mathematica. Indeed, while talking with Mathematica users about that system, I have always heared praises to the power of its pattern matching facilities. Hence it may be one of the reasons for people choosing Mathematica. So, even for purely comercial reasons, this is a point that WMI should consider improving.

Back to the present, applyrule turns out as the right way for possibly porting Rubi into Maple.

I also think that a solid, efficient pattern matching utility could help to improve part of Maple own code, in that pattern matching is actually being used in diverse disguised ways, in multiple "reinventions of the wheel". Certainly, I have a "date" with inttrans.

@pagan 

About posting, may be that there is a larger difference in frequency in recent months between math/kernel vs GUI, but not so much earlier. Anyways, that is not the point, but rather why efficiency was and is such a high priority in the former area but not so much in the latter. I have no doubt that developers won't devote their time to improving efficiency in their Maple code unless product or group management makes such decisions. So, the results that they have posted here about improving efficiency in the math/kernel area should be, in general, a reflection of such decisions.

And you have also described the great pains required to make the Java GUI barely usable nowadays (a description that I agree completely). So, I wonder which are the technical reasons explaining this decision to start and keep using Java, if, apparently, "lower cost" routes exist. Clearly, a large enough difference in "cost" between keeping and porting can justify the switch.

@pagan 

About posting, may be that there is a larger difference in frequency in recent months between math/kernel vs GUI, but not so much earlier. Anyways, that is not the point, but rather why efficiency was and is such a high priority in the former area but not so much in the latter. I have no doubt that developers won't devote their time to improving efficiency in their Maple code unless product or group management makes such decisions. So, the results that they have posted here about improving efficiency in the math/kernel area should be, in general, a reflection of such decisions.

And you have also described the great pains required to make the Java GUI barely usable nowadays (a description that I agree completely). So, I wonder which are the technical reasons explaining this decision to start and keep using Java, if, apparently, "lower cost" routes exist. Clearly, a large enough difference in "cost" between keeping and porting can justify the switch.

If the Java based GUI still has severe performance problems, better alternatives exist and  the main concern of Maple developers is performance (as their posts here show), which are the technical reasons explaining the persistent use of Java?

If the Java based GUI still has severe performance problems, better alternatives exist and  the main concern of Maple developers is performance (as their posts here show), which are the technical reasons explaining the persistent use of Java?

@acer 

This could be an option:

RemoveAllAssumptions:=proc() 
local u;  global `property/object`,`property/OrigName`:
for u in map(op,[indices(`property/OrigName`)]) do
`property/object`[u]:=``:
end do:
zip(assign, map(op,[entries(`property/OrigName`)]), map(op,[entries(`property/OrigName`)])):
`property/OrigName`:=table():
end proc:

It should restore the property tables property/object and property/OrigName to their initial state, and assign back to the variables on which a property was attached, their names as value. I.e. it should provide a "property restart".

z:=y;
                                z := y

assume(x>0);
y:=x;

                                y := x

z;
                                  x

RemoveAllAssumptions():
about(x);
x:
  nothing known about this object

z;
                                  x

y;
                                  x