It is interesting that if you use a indefinite construction in Maple 17, you can still get a hypergeometric solution:

int(     (  1+(a*x)^t  )^(-1/t)      , x );

It is interesting that if you use a indefinite construction in Maple 17, you can still get a hypergeometric solution:

int(     (  1+(a*x)^t  )^(-1/t)      , x );

Maybe you can build the restriction y<x/59 into the domain specification. Use x=53..70, y=53..x/59 for example.

plot3d(21430.800231-(x*359.016725)-((x/y)*389.223603)+(x*(x/y)*6.487414)+(118.7333*0.109468),x=53..70,y=53..x/59,grid=[20,20]);

@spradlig 

You are correct about what 2D input means. We do of course show students how to change the setting so that 1D input is the default on their personal copy of Maple, but we can't force students to do so. With a hundred or so different students each semester, merely showing students how to change defaults is not effective.

More fundamentally, the idea of having two different input parsers is madness, especially when using Maple in teaching. See this post

http://www.mapleprimes.com/posts/35973-Parser-Differences 

@Carl Love 

We did make it the default on campus computers, with some difficulty. But students often purchase their own copies, which come with the default all over again (document mode with 2d input?). Eventually we decided to give up our expectation of a common interface.

We too started using Maple in about 1993, because of the pricing and licensing advantages. Also, the pedagogical value of  Maple Input syntax was very attractive. Since the inception of the Standard interface with its 2D input default, our use of Maple in teaching undergraduates has dropped significantly.

How the original questioner is thinking about u(0.16) and u(0.25) is murky.  That they can be prescribed freely is a possible interpretation.

 Suppose it is prescribed that u(0.16)=u(0.25)=0 (so the ode would be u'' + 1.7 + uu'=0) along with the stated conditions on u(0) and u(1).

Your solution would not satisfy these conditions, but it should still be possible to find a continuous solution that is not differentiable at the two interior points.

How the original questioner is thinking about u(0.16) and u(0.25) is murky.  That they can be prescribed freely is a possible interpretation.

 Suppose it is prescribed that u(0.16)=u(0.25)=0 (so the ode would be u'' + 1.7 + uu'=0) along with the stated conditions on u(0) and u(1).

Your solution would not satisfy these conditions, but it should still be possible to find a continuous solution that is not differentiable at the two interior points.

@Markiyan Hirnyk 

This is odd, because when I use 

limit (sin(x^2)+sin(y^2))/(x-y) as x->0 and y->0

in Wolfram Alpha, the result is "limit does not exist..value may depend on x,y path." This result is obviously correct, since we can have an approach with x>y and another with x<y.

The fact that Maple does not return anything for

limit((sin(x^2)+sin(y^2))/(x-y),{x=0,y=0});

is reasonable, but weak. I still contend that Maple ought to be able to evaluate the original limit corresponding to sin(x)+sin(y).

@Markiyan Hirnyk 

This is odd, because when I use 

limit (sin(x^2)+sin(y^2))/(x-y) as x->0 and y->0

in Wolfram Alpha, the result is "limit does not exist..value may depend on x,y path." This result is obviously correct, since we can have an approach with x>y and another with x<y.

The fact that Maple does not return anything for

limit((sin(x^2)+sin(y^2))/(x-y),{x=0,y=0});

is reasonable, but weak. I still contend that Maple ought to be able to evaluate the original limit corresponding to sin(x)+sin(y).

Yet Wolfram Alpha gets the result with 

limit sin(x)+sin(y) as x->0, y->0

This is an easy problem, and so it is hard to understand why any software package would have a limitation here.  

Yet Wolfram Alpha gets the result with 

limit sin(x)+sin(y) as x->0, y->0

This is an easy problem, and so it is hard to understand why any software package would have a limitation here.  

@rlopez 

I watched the "Tangent and Normal Lines-Solution by Task Template" video.

 There is a box in the template where one is prompted to enter a value for x0,

 where the default is x0=0.

My comment was meant to suggest that the tool makes it too easy to >not< make

 the exact same mistake described in my example. Making the mistake is good, 

because it causes cognitive conflict. An environment where the learner is insulated 

from this is not "bad." It just supports a different philosophy of learning. 

I appreciate the value of re-sequencing concepts and skills. But my take on the value of Maple in undergraduate education diverges from the "clickable math" paradigm. The real value of Maple in education comes from a feedback between syntax, content, and cognition.

For example, a student in Calculus I is asked to display the graph of y=x^2 and its tangent line at x=2. Student erroneously ends up with y=4+2*x*(x-2) as the equation of the tangent line. The graph of the curve and "line" looks wrong and causes cognitive conflict. In resolving the conflict, the student learns. In clickable math, it seems too easy to circumvent cognitive conflict. 

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.