When the poster's original limit in latex

 \lim_{(x,y)\rightarrow (0,0)}\frac{e^x+e^y}{\cos x-\sin y}

is pasted into Wolfram Alpha, the latex code is parsed and the value of the limit is returned.  Maple's really behind on the LaTeX front. 

Maple tries to reinvent the wheel, only to come up with some sort of oblong shape.


\documentclass{article}

 \usepackage{color}
 

It's hard to imagine a better solution. Maple should embrace it.

Mich: I can confirm that MapleTA/LaTeX support has not moved epsilon for several releases.

I make an honest effort to author questions with LaTeX each release, and nothing has improved. I gave up on this dream a few years ago, but always check back with each new release.

Support is poor. Replies from tech support are brief, snarky, and unhelpful. I dread each new release, because they seem to never repair ongoing problems. As you observe, their examples still do not work! So nobody seems to be putting in effort.

As an institution, we are trying to figure out a way of migrating from this withering product.

@pagan 

"Just" changing a few settings is straightforward for me. Have done it for years.

But the bugaboo is that we expose lots of undergraduates to Maple in our calculus sequence. Every year when we have yet another version (15?). The we have to communicate settings for preferences to IT. And then students buy their own editions, and get confused.

It's just a never ending battle and nuisance to try to get everybody to calibrate with classic, or with standard/worksheet or with standard/document/1D, etc.or with some other bifurcation.

Having two parsers is madness, to say it mildly. As a faculty and instituion, we are clearly migrating to competitors. Personally, as a long-time user of Maple, I am sorry to say that I see the wisdom in this evolution.

@pagan 

It is ashamed that we have such bifurcation: document/worksheet, 2D/1D input, standard/classic.

It's like the Tower of Babel. Users are scattered and confused.

I guess I view it as progress. Somebody might want "e" to be the eccentricity of an ellipse, or the charge of an electron, or an entry in {a,b,c,d,e}. So in spite of the ubiquity of the Euler constant, we should not tie up "e" to be exp(1).

Notice if you do this

e:=exp(1);

then "e" starts to look different in the Maple session.

@Axel Vogt 

Agreed. Carthago (2D input, especially document mode)  delenda est.

It's been years, and it's no better.

@Axel Vogt 

Agreed. Carthago (2D input, especially document mode)  delenda est.

It's been years, and it's no better.

There is no need for evalf here:

value(Int((sum(x^(2*k+1), k = 1 .. infinity))*sqrt(1-x), x = 0 .. 1));

gives a nice closed form expression involving arctanh.

There is no need for evalf here:

value(Int((sum(x^(2*k+1), k = 1 .. infinity))*sqrt(1-x), x = 0 .. 1));

gives a nice closed form expression involving arctanh.

@Chris 

I think the issue is that converting

ln(9*x+(81*x^2-16)^(1/2)) to arccosh(9/4*x)+C involves some "branch-cut" analysis.

I think that the conversion is valid if x>-4/9, because we need to know that

sqrt(9*x-4)*sqrt(9*x+4)=sqrt(81*x^2-16)

Look at this:

A := ln(9*x+(81*x^2-16)^(1/2));

B:=arccosh(9/4*x);

plot(A-B,x=-1..1);

Notice the difference is a constant only if x>-4/9.

So it's no failing of Maple that it does not make the conversion without assumptions on x.

The way to remove the torn boundaries is to control things with the plot range, not with the function definition:

plot3d(sin(2*x+2*y), x=0..3, y=3-x..0, axes=normal);

The way to remove the torn boundaries is to control things with the plot range, not with the function definition:

plot3d(sin(2*x+2*y), x=0..3, y=3-x..0, axes=normal);

It's not easy to help without some specific code, so I suggest you post some code. You can find it in the question editor under "Edit Source." You can copy-paste that into Mapleprimes.

You  need to clarify your mathematics and definitions.

If y=x^2*sin(x) and if u=sin(x) then dy/du=(dy/dx)*(dx/du)=(dy/dx)/(du/dx)=diff(y,x)/cos(x)

which gives the result Robert got by implicitdiff, namely (cos(x)*x^2+2*sin(x)*x)/cos(x)

Yet if y=x^2*sin(x) and  instead u=x^2, then the same reasoning gives (1/2)*(cos(x)*x^2+2*sin(x)*x)/x.
 
 However, if you think of the odd function x^2*sin(x) in terms of its Maclaurin series, then since it is odd, it depends only on odd powers of x, and is independent of even powers, so its derivative with respect to x^2 should be 0. Given this discrepancy, it is clear that you need to be careful about your definitions and expectations.