As new features are being built into upcoming releases of Maple, here is one request that would be very helpful for those of us who use Maple to teach lower-level (Calculus) students.
Maple can work nicely with functions, but students are not always so comfortable with this language. Here's a current example.
Suppose you want to find the tangent line to a function. We might work as follows.
> f := x -> sqrt(4-x^2);
/ 2\
x -> sqrt\4 - x /
> df := D( f ); # typed, or from context-menu
x
x -> - ------------
/ 2\
sqrt\4 - x /
> TL := f(1)+df(1)*(x-1); # tangent line at (1,sqrt(3))
(1/2) 1 (1/2)
3 - - 3 (x - 1)
3
This works nicely and looks fine. Now change the function.
f := x -> sin(x);
x -> sin(x)
df := D( f ); # typed, or from context-menu
cos
TL := f(1)+df(1)*(x-1); # tangent line at (1,sin(1))
sin(1) + cos(1) (x - 1)
This works fine, but does not LOOK good. The problem is that Maple is TOO SMART. It knows that the derivative function (x->cos(x)) is simply the cosine FUNCTION. Instead of the abbreviation (cos) I want to be able to tell Maple to show this result as (x->cos(x)).
The problem is that this output is not something that students would have seen previously.
This discrepancy in the appearance of the output occurs only when the derivative is so simple that Maple recognizes it as one of its built-in functions. Some slight changes to the problem allow us to avoid this annoyance.
f := x -> 2*sin(x);
x -> 2 sin(x)
df := D( f ); # typed, or from context-menu
x -> 2 cos(x)
TL := f(1)+df(1)*(x-1); # tangent line at (1,cos(1))
2 sin(1) + 2 cos(1) (x - 1)
I have to admit that the previous example did surprise me. I thought Maple would be smart enough to recognize f as 2*sin and df as 2*cos, but we see otherwise.
As a final example, consider
f := x -> cos(x);
x -> cos(x)
df := D( f ); # typed, or from context-menu
x -> -sin(x)
TL := f(1)+df(1)*(x-1); # tangent line at (1,cos(1))
cos(1) - sin(1) (x - 1)
Here, I have no complaints but I am curious. Why didn't Maple recognize f as cos and produce a display that I could complain about.
This example illustrates to me that Maple can be given the smarts to decide when NOT to simplify a function.
Could this be solved be having a user-controlled setting of some sort? (Maybe something like _ShowFunctionDefn:=explicit;) It's another example of some user control that could make Maple much more effective for teaching.
Thanks for listening,
Doug
Comments
Fragile
What Maple is doing is called
-reduction. This is the rule that, in the lambda calculus, x->f(x) = f. However, this
-reduction is implemented in maple in a fragile (as you note above) and ultimately annoying way.
What you are asking is that you would prefer
-expanded versions, especially if the input had explicit parameters. And this makes sense, because Maple is much stronger in manipulating functions containing expressions than expressions that denote (pointfree) functions. A function is pointfree when you do not need to name its parameter.
The big problem is that people who implemented
-reduction did so because they were really smart and had just independently re-discovered this feature of the lambda-calculus. So they did not know to look in the fast literature on this topic, which would have warned them of the weird side-effects you are noticing above. It is also worth noticing that this was much worse before Maple 6, where if you try your tests you'll get even more puzzling results. We fixed as much as we could at that time, but missed some cases.
can it be fixed, though?
I tried to watch maple do its work here, but...
> restart:
> stopat(`PD/PD`,22): # Maple 11.00
> D(x->sin(x));
[]
`PD/PD`:
22* body := pointto(disassemble(addressof(p))[6]);
DBG> next
Error, (in D/procedure) invalid keyword expression
Ok, I can imagine that pointto() might not work properly within the debugger.
So I trace `PD/PD` instead. It returns x->cos(x) to `D`. OK.
So, continuing to watch D at work, it look's like it's the call reduce_opr(eval(d,1)) which turns x->cos(x) into cos.
How dangerous would it be to replace one's D with a version which did not call reduce_opr ?
acer
No clue!
reduce_opr is a new builtin that was added to Maple after my time -- I have no idea what it does, and it's not documented. Since we can't peek at the kernel source to find out, our only hope is that someone from Maplesoft will reply to this one. reduce_opr might also do some quite useful transformations that should not be lost.
Consistency?
Doug,
You might like to try this. Tools>Tasks>Browse>Calculus>Derivatives>Applications>TangentLine.
Enter your second example (sin(x), x=1), click Compute Details and look at the f'(x) box. One might expect it to be the same as in your post, but no, Maple has other ideas!
Should we laugh, or cry?
J. Tarr
Planned inconsistency
I believe that this is an example of planned inconsistency. The developers know that the 'core' functionality is weird, so in a setting where 'weird' is unacceptable (like education), task helpers and the Student package and ... contain reimplementations (or hacks around) some internal functionality, to get around 'weird'. Of course, this creates inconsistency, but at least if you stick to the most-recently-coded way of doing things, things are less-weird.
But think about what the real cost of this is: all this time that the developers are spending re-implementing core functionality in some dark corner of Maple is time not spent improving something else. Worse, because these pieces of code are buried in strange places, they can't easily be re-used, so these hacks are actually re-implemented multiple times! And of course, the hacks are frequently library-level code, getting around kernel code, with all the inefficiencies that that entails.
This is the real, tangible cost of backwards compatibility with broken features and antiquated designs - bloated code, slower development, painful maintenance. In other words, the wonderfully talented and eager-to-improve-Maple developers at Maplesoft are slowed down tremendously from doing what they would like to do for the customers by bad decisions made sometimes 2 decades ago. [I have heard this directly from multiple developers]. This 'planned inconsistency' is the best they can do under the circumstances.