The Maple input in your material is in a format that is called 2D Math. That's the format in which the input can appear as nicely marked up math with symbols and all that jazz.

In 2D Math, a name with a subscript (which in your example is entered as p_0) is actually the table reference p[0] under the hood.

If you select a section of input then you can use the menus (top-menu's Format -> Convert To, or right-click context-menu's Convert To) to toggle the selected between 2D Math and 1D input.

So, when you had p[0] assigned a value, then Maple got all confused when you tried to assign a procedure to p (which, incidentally, made use of p[0]) and then to plot it. Very often in Maple, it is not possible to use a name like p for one thing while also using its indexed entries for something else.

There's a way around this, if one really wants to use 2D Math. After typing in your p_0 (which is p[0] at that moment) you can select it with the mouse an use the right-click context menu and convert that subscripted item into its own unique name. That unique name, which in 2D Math would still appear as the subscripted p, would be fully distinct from p and so not suffer from a collision elsewhere. The context-menu choice would be 2D Math -> Convert To -> Atomic Identifier.

The idea is that, by toggling a subscripted name (identifier) as atomic (unique) it would be distinct from the unsubscripted same name.

There are some snags. The first, which is just bearable, is that you have to toggle every single instance of inputing p_0 in 2D Math. You could also use the `subliteral` palette object and get the same effect, but that would mean having to keep switching between keyboard and mouse action when entering math. The second is that table references for subscripted names is probably the wrong default, and can't be turned off as a preference. And the term "atomic identifier" is unintuitive and so not as good as "unique name". And the whole business is rather underdocumented, though it sure does come up a lot here on mapleprimes.

When I tried toggling the instances of p_0 in your uploaded worksheet (which were p[0]) I found that they produced different unique names. So the procedure which contained the p_0 would not be able to evaluate to an actual real number, since its p_0 was not assigned! By using the menus to convert both instances to 1D input, after I had toggled them as Atomic Identifiers, I found that they were different names underneath. The first one, where the assignment took place, was,

`#msub(mi("p",fontstyle = "normal"),mn("0"))`

The second one, inside the operator definition, was,

`#msub(mi("p"),mn("0"))`

And the assignment to the former would not get utilized when accessing the latter. For me, that was a new twist on this issue.

acer

The Maple input in your material is in a format that is called 2D Math. That's the format in which the input can appear as nicely marked up math with symbols and all that jazz.

In 2D Math, a name with a subscript (which in your example is entered as p_0) is actually the table reference p[0] under the hood.

If you select a section of input then you can use the menus (top-menu's Format -> Convert To, or right-click context-menu's Convert To) to toggle the selected between 2D Math and 1D input.

So, when you had p[0] assigned a value, then Maple got all confused when you tried to assign a procedure to p (which, incidentally, made use of p[0]) and then to plot it. Very often in Maple, it is not possible to use a name like p for one thing while also using its indexed entries for something else.

There's a way around this, if one really wants to use 2D Math. After typing in your p_0 (which is p[0] at that moment) you can select it with the mouse an use the right-click context menu and convert that subscripted item into its own unique name. That unique name, which in 2D Math would still appear as the subscripted p, would be fully distinct from p and so not suffer from a collision elsewhere. The context-menu choice would be 2D Math -> Convert To -> Atomic Identifier.

The idea is that, by toggling a subscripted name (identifier) as atomic (unique) it would be distinct from the unsubscripted same name.

There are some snags. The first, which is just bearable, is that you have to toggle every single instance of inputing p_0 in 2D Math. You could also use the `subliteral` palette object and get the same effect, but that would mean having to keep switching between keyboard and mouse action when entering math. The second is that table references for subscripted names is probably the wrong default, and can't be turned off as a preference. And the term "atomic identifier" is unintuitive and so not as good as "unique name". And the whole business is rather underdocumented, though it sure does come up a lot here on mapleprimes.

When I tried toggling the instances of p_0 in your uploaded worksheet (which were p[0]) I found that they produced different unique names. So the procedure which contained the p_0 would not be able to evaluate to an actual real number, since its p_0 was not assigned! By using the menus to convert both instances to 1D input, after I had toggled them as Atomic Identifiers, I found that they were different names underneath. The first one, where the assignment took place, was,

`#msub(mi("p",fontstyle = "normal"),mn("0"))`

The second one, inside the operator definition, was,

`#msub(mi("p"),mn("0"))`

And the assignment to the former would not get utilized when accessing the latter. For me, that was a new twist on this issue.

acer

If Maple always went to the expense of trying to do such simplifications then it would hurt the performance for anyone who didn't need or want it for a particular example.

How would one go about turning that simplification off?

And what if there were radicals in the coefficients of the cubic? It could become very expensive to try to determine whether the roots were purely real.

Would drawing the line at, say, rational coefficients appear inconsistent?

And what if one didn't want a result with trig in it, but wanted the explicit radicals only (when possible) from `solve`?

It may be difficult to justify an automatic and potentially expensive simplification which might not always suit everyone.

acer

If Maple always went to the expense of trying to do such simplifications then it would hurt the performance for anyone who didn't need or want it for a particular example.

How would one go about turning that simplification off?

And what if there were radicals in the coefficients of the cubic? It could become very expensive to try to determine whether the roots were purely real.

Would drawing the line at, say, rational coefficients appear inconsistent?

And what if one didn't want a result with trig in it, but wanted the explicit radicals only (when possible) from `solve`?

It may be difficult to justify an automatic and potentially expensive simplification which might not always suit everyone.

acer

I believe that you can insert a URL by selecting some existing text with the mouse and then, with that text highlighted, using the Insert/Edit Link button.

If you haven't yet written that part of the text then you can insert the link first and then edit it afterwards as source. By that I mean switch to source-mode using the "Source" button at the top of the Editor. Then edit by hand what lies between the <a..> and </a> (leaving the href part alone).

It's mildly inconvenient if the text portion cannot be entered or edited in the Insert/Edit Link pop-up.

That numeric integral is hard, I think, to get with good accuracy. Which is something that the author did not address. How accurate an answer did he want? How accurate an answer did he receive from Mathematica?  He appeared to have ignored Mathematica's printed advice and bumped up the MaxRecursion parameter but not chosen Method->Oscillatory. He did not mention that Maple's evalf(Int(..) has [documented] separate options to control both the working precision and an accuracy tolerance.

What I liked about the example is that it illustrates a dichotomy for software. Should it always just try and be super smart and magically handle everything? Or should it provide lots of powerful options and controls to assist with the nastier problems? How should it balance ease of use versus power? And how should it guide the user? Maple's evalf(Int()) can dump out a lot of userinfo messages, if infolevel[`evalf/int`] is set higher than 0. But I don't think that it will use Maple's WARNING() mechanism to offer succinct advice when it fails to converge and returns unevaluated.

An alternative view of the performance on that example is how the two systems behaved when the author threw a nasty problem at them -- likely deliberately in a naive way. On the one hand I think that Maple does have more documented controls than the author claimed to have found (he hinted that he tried stuff), but on the other hand Mathematica was helpful.

Hmm. Why isn't Warning a help alias for WARNING.

acer

I believe that you can insert a URL by selecting some existing text with the mouse and then, with that text highlighted, using the Insert/Edit Link button.

If you haven't yet written that part of the text then you can insert the link first and then edit it afterwards as source. By that I mean switch to source-mode using the "Source" button at the top of the Editor. Then edit by hand what lies between the <a..> and </a> (leaving the href part alone).

It's mildly inconvenient if the text portion cannot be entered or edited in the Insert/Edit Link pop-up.

That numeric integral is hard, I think, to get with good accuracy. Which is something that the author did not address. How accurate an answer did he want? How accurate an answer did he receive from Mathematica?  He appeared to have ignored Mathematica's printed advice and bumped up the MaxRecursion parameter but not chosen Method->Oscillatory. He did not mention that Maple's evalf(Int(..) has [documented] separate options to control both the working precision and an accuracy tolerance.

What I liked about the example is that it illustrates a dichotomy for software. Should it always just try and be super smart and magically handle everything? Or should it provide lots of powerful options and controls to assist with the nastier problems? How should it balance ease of use versus power? And how should it guide the user? Maple's evalf(Int()) can dump out a lot of userinfo messages, if infolevel[`evalf/int`] is set higher than 0. But I don't think that it will use Maple's WARNING() mechanism to offer succinct advice when it fails to converge and returns unevaluated.

An alternative view of the performance on that example is how the two systems behaved when the author threw a nasty problem at them -- likely deliberately in a naive way. On the one hand I think that Maple does have more documented controls than the author claimed to have found (he hinted that he tried stuff), but on the other hand Mathematica was helpful.

Hmm. Why isn't Warning a help alias for WARNING.

acer

I get a lot of mileage out of trying to adhere to a simple principal of using function parameter names which do not coincide with global names in my expressions. It helps me keep it straight.

For example, you probably wouldn't have been puzzled at all if you'd written it as,

N1 := u+v;
M1 := (a,b) -> N1;

The unapply function is nice. Without it, we might be writing things like,

N1 := u+v;
M1 := (a,b)->subs({u=a,v=b},N1);
M1(s,t);

..and then we could get confused by this,

N1 := u+v;
M1 := (u,v)->subs({u=u,v=v},N1);
M1(s,t);

and resort to this,

N1 := u+v;
M1 := (u,v)->subs({:-u=u,:-v=v},N1);
M1(s,t);

And then we might realize that the above wouldn't work all inside a procedure in which u and v were locals. In desperation,

p:=proc() local u,v,N1,M1;
  N1 := u+v;
  M1 := subs({U=u,V=v},(u,v)->subs({U=u,V=v},N1));
  M1(s,t);
end proc:
p();

And then we'd go crazy.

acer

The number of things that people believe that they know how to accomplish is greater than the number which can be done well with the time and people resources available. That's the case for Maple development, too.

I don't think highly of an article which seems to put so much weight on a single computational result. I agree with another poster here, that in effect one could judge a CAS by how well it helps in a given discipline that  is chosen up front.

Every CAS or piece of math software fails on some (different set of) simple problems. Look at the flood of bug reports about Mathematica 6 recently reported on comp.soft-sys.math.maple. I wouldn't pass definitive judgement on Mathematica based on just a few of those reports. Similarly I wouldn't discount Maple based on a single numerical quadrature result.

I was never a big fan of the Wester review that Jacques cited in an earlier comment in this thread. I can see that some people might like its attempt at breadth. But my view is that since complete coverage is next to impossible it is better to focus on one's particular needs. I'd rather see many discipline- or functionality-specific reviews. Pragmatism, that's all I have to offer.

There is one specialized review of which I'm aware. It focuses on statistics and data analysis, with a bit of overflow into general numerics, plots, i/o and format exchange, etc. It is the ncrunch review of Stefan Steinhaus. Granted it has a few problems, where use of the programs might have been better optimized. But he makes an effort to consult with a representative expert, to get the code into fair shape for all. It's not perfect, and not nearly as expert as Wester's, but it's a start toward discipline-specific analysis. I'd like to see a similar review by, say, mechanical engineers, or 1st-year-calculus college lecturers, or chemists, or...

acer

The number of things that people believe that they know how to accomplish is greater than the number which can be done well with the time and people resources available. That's the case for Maple development, too.

I don't think highly of an article which seems to put so much weight on a single computational result. I agree with another poster here, that in effect one could judge a CAS by how well it helps in a given discipline that  is chosen up front.

Every CAS or piece of math software fails on some (different set of) simple problems. Look at the flood of bug reports about Mathematica 6 recently reported on comp.soft-sys.math.maple. I wouldn't pass definitive judgement on Mathematica based on just a few of those reports. Similarly I wouldn't discount Maple based on a single numerical quadrature result.

I was never a big fan of the Wester review that Jacques cited in an earlier comment in this thread. I can see that some people might like its attempt at breadth. But my view is that since complete coverage is next to impossible it is better to focus on one's particular needs. I'd rather see many discipline- or functionality-specific reviews. Pragmatism, that's all I have to offer.

There is one specialized review of which I'm aware. It focuses on statistics and data analysis, with a bit of overflow into general numerics, plots, i/o and format exchange, etc. It is the ncrunch review of Stefan Steinhaus. Granted it has a few problems, where use of the programs might have been better optimized. But he makes an effort to consult with a representative expert, to get the code into fair shape for all. It's not perfect, and not nearly as expert as Wester's, but it's a start toward discipline-specific analysis. I'd like to see a similar review by, say, mechanical engineers, or 1st-year-calculus college lecturers, or chemists, or...

acer

Why couldn't they be allowed to differ by a constant?

If two antiderivatives differ by a constant, and if you differentiate them, will you get the same result?

acer

There are a few things that might be holding Maple back here.

One of those is that the compiled external (NAG) routine d01akc which specializes in oscillatory non-singular integrands has a  `max_num_subint` parameter which is not exposed at the user-level in Maple. The accuracy tolerances are exposed, via evalf/Int's `epsilon` parameter. But the maximal number of allowed subintervals is not so exposed. So that specialized routine will fail for an integral behaving like BesselJ(0,50001*x) when it attempts to use more than 200 (a hard coded default value) subintervals. With 200 subintervals only, one can only request an epsilon of about 5e-2 or so for the integrand at hand to succeed. I didn't try to subvert Maple and so test whether that routine could handle 50001*x in reasonable time, if allowed a very high number of subintervals.

Not having a super fast compiled hardware floating-point BesselJ0 may also affect the performance. Axel Vogt made some interesting posts and comments here a while back about fast BesselK and using that for numeric quadrature.

acer

There are a few things that might be holding Maple back here.

One of those is that the compiled external (NAG) routine d01akc which specializes in oscillatory non-singular integrands has a  `max_num_subint` parameter which is not exposed at the user-level in Maple. The accuracy tolerances are exposed, via evalf/Int's `epsilon` parameter. But the maximal number of allowed subintervals is not so exposed. So that specialized routine will fail for an integral behaving like BesselJ(0,50001*x) when it attempts to use more than 200 (a hard coded default value) subintervals. With 200 subintervals only, one can only request an epsilon of about 5e-2 or so for the integrand at hand to succeed. I didn't try to subvert Maple and so test whether that routine could handle 50001*x in reasonable time, if allowed a very high number of subintervals.

Not having a super fast compiled hardware floating-point BesselJ0 may also affect the performance. Axel Vogt made some interesting posts and comments here a while back about fast BesselK and using that for numeric quadrature.

acer

I suspect that he was referring to g the acceleration due to gravity, or a force on a body of mass m under such acceleration.

acer

I suspect that he was referring to g the acceleration due to gravity, or a force on a body of mass m under such acceleration.

acer

If we're lucky, someone will explain its relationship to the lambda calculus in detail.

Jacques has written in the past that, "Maple's unapply is the same as Church's lambda abstraction operator."

The help-page ?unapply says,

- The unapply command implements the lambda-expressions of lambda calculus.

For reference see ``An Implementation of Operators for Symbolic Algebra
Systems'' by G.H. Gonnet, SYMSAC July 1986.

What I wonder is whether the help ever claimed that, "The scoping behaviour of unbound names is not the same in the lambda calculus," and if so how that might be true.

acer