Yes, delta7's first response made that point, about using the antiderivative.

And, yes, Maple is capable of generating the nicer answer. As was mentioned, that happened in some earlier versions of Maple.

The thing is, there are lots of ways to accomplish some definite integration problems. There is FTOC, which we see allows Maple to get a nice form. There is change of variables, which also works nicely here. Pattern matching might also get this one  smoothly. (Search for MeijerG and integration and you can find lots of hits, many even on this site.)

Setting infolevel[int] to 3, and running the original definite integration call, one can see that Maple 12 uses an elliptic integral methodology.

It can be very difficult to tell in advance which methods will work best for a given problem -- which will both succeed and get the nicest answer, fastest. The front dispatcher of `int` has to do this. And it must be an art form, to have it please most of the people most of the time. I could envision that tweaking it to "fix" one particular example could likely "break" many other examples.

Maybe this state of affairs could be improved by crude use of Threads. Run several methods in parallel, and take which ever solution is nicest, to return to the user.

acer

The `zip` routine can be used to process two lists elementwise.

For example, (this can be also be done with `seq`, as you had originally)

> L := [1,19,4,7,21,16]:
> zip((a,b)->`if`(a<b,a,b), L[1..-2],L[2..-1]);
                               [1, 4, 4, 7, 16]

If I was doing these sorts of things with large numbers of floats, and speed was of utmost concern, then I would consider using Arrays of datatype=float[8] and map[evalhf] and/or evalhf'able procedures. Since Arrays are fixed size, then instead of replacing elements with NULL (to shorten them) I might use some specific (very large in magnitude) negative number which could be subsequently ignored. I note that map[evalhf] can understand max() and min() but not `if`.

acer

The `zip` routine can be used to process two lists elementwise.

For example, (this can be also be done with `seq`, as you had originally)

> L := [1,19,4,7,21,16]:
> zip((a,b)->`if`(a<b,a,b), L[1..-2],L[2..-1]);
                               [1, 4, 4, 7, 16]

If I was doing these sorts of things with large numbers of floats, and speed was of utmost concern, then I would consider using Arrays of datatype=float[8] and map[evalhf] and/or evalhf'able procedures. Since Arrays are fixed size, then instead of replacing elements with NULL (to shorten them) I might use some specific (very large in magnitude) negative number which could be subsequently ignored. I note that map[evalhf] can understand max() and min() but not `if`.

acer

Wasn't the problem that table references couldn't be used as (formal) parameter names for a procedure, rather than as input aguments which is what you now seem to be discussing? I don't see how the above addresses that.

Also, it doesn't matter if one types the keystrokes x[1] or x_1 since they both create the table reference x[1] in Maple 11 &12.

This reminds me that I also don't like using atomic identifiers such as `#msub(mi("x"),mn("1"))` because context-menus don't typeset them properly. Sure, it gets typeset nicely as x-subscript-1 in 2D Math output, but every now and then its true nature pops up.

For example, create an expression containing the atomic identifier (or subliteral from the layout palette) and then look at the Solve->Solve for Variable context-menu item. That MathML object that then shows up as the variable (name) will likely confuse many users.

acer

Wasn't the problem that table references couldn't be used as (formal) parameter names for a procedure, rather than as input aguments which is what you now seem to be discussing? I don't see how the above addresses that.

Also, it doesn't matter if one types the keystrokes x[1] or x_1 since they both create the table reference x[1] in Maple 11 &12.

This reminds me that I also don't like using atomic identifiers such as `#msub(mi("x"),mn("1"))` because context-menus don't typeset them properly. Sure, it gets typeset nicely as x-subscript-1 in 2D Math output, but every now and then its true nature pops up.

For example, create an expression containing the atomic identifier (or subliteral from the layout palette) and then look at the Solve->Solve for Variable context-menu item. That MathML object that then shows up as the variable (name) will likely confuse many users.

acer

Thanks for catching that. Joe.

Of course, `x[0]` won't be nicely typeset as a subscripted variable.

The request was very simple, and it's disappointing that it cannot be done. One wishes to define an operator and use a subscripted name as the parameter. But it cannot be done anywhere near easily because typed-in (!) subscripted names are table references by default and can only be toggled to symbols via hard to find context-menus. And the palettes are often more trouble than they are worth, when one is typing. And there is no visual cue in 2D Math as to whether a subscripted name is a table reference or an atomic symbol.

Having subscripted names be table references (underneath the hood) is the wrong default behaviour. This is another example corroborating that.

acer

Thanks for catching that. Joe.

Of course, `x[0]` won't be nicely typeset as a subscripted variable.

The request was very simple, and it's disappointing that it cannot be done. One wishes to define an operator and use a subscripted name as the parameter. But it cannot be done anywhere near easily because typed-in (!) subscripted names are table references by default and can only be toggled to symbols via hard to find context-menus. And the palettes are often more trouble than they are worth, when one is typing. And there is no visual cue in 2D Math as to whether a subscripted name is a table reference or an atomic symbol.

Having subscripted names be table references (underneath the hood) is the wrong default behaviour. This is another example corroborating that.

acer

Having TROUBLE with `for` or `do`? Then READ the HELP-PAGE for `for` or `do`.

The HELP-PAGE for `do` is accessible by entering ?do or ?for

It says that the printing from nested loops is controlled via printlevel, in the bullet point titled "Note about Nested Loops". It has a cross-reference to ?printlevel

acer

Array(0..2,0..1,0..3,0..2, (i,j,k,l)->_a[i,j,k,l]);

A[1,0,3,2];

acer

You can end the line with a colon (not the usual semicolon) and it will suppress printing all those pages of output.

evals := LinearAlgebra:-Eigenvalues(M):

If your resulting Vector has been assigned to a variable (above, evals) then you can access its elements as evals[1], evals[2], etc. Or, you can assign those to new variables.

a := evals[1]:

If you got the Vector of eigenvalues by using the context-menus (ie. by right-clicking on a Matrix and using the popup menus) then you can immediately refer to that Vector by using the % symbol. In Maple, % means the "last thing evaluated". See the help-page on topic ditto. For example, you could do as follows.

evals := %:
evals[1];

Your question is not a bad one. It's quite normal to want to simply enter a command like Eigenvalues(M) without assigning it to anything. And then, when it's finished, you want to assign it to some variable without having to wait while recomputing the whole thing. The %, %%, and %%% constructs let you do just that.

The help-page is named "ditto", because many releases ago the symbols for this were double-quotes (") rather than percent (%).

acer

You can end the line with a colon (not the usual semicolon) and it will suppress printing all those pages of output.

evals := LinearAlgebra:-Eigenvalues(M):

If your resulting Vector has been assigned to a variable (above, evals) then you can access its elements as evals[1], evals[2], etc. Or, you can assign those to new variables.

a := evals[1]:

If you got the Vector of eigenvalues by using the context-menus (ie. by right-clicking on a Matrix and using the popup menus) then you can immediately refer to that Vector by using the % symbol. In Maple, % means the "last thing evaluated". See the help-page on topic ditto. For example, you could do as follows.

evals := %:
evals[1];

Your question is not a bad one. It's quite normal to want to simply enter a command like Eigenvalues(M) without assigning it to anything. And then, when it's finished, you want to assign it to some variable without having to wait while recomputing the whole thing. The %, %%, and %%% constructs let you do just that.

The help-page is named "ditto", because many releases ago the symbols for this were double-quotes (") rather than percent (%).

acer

Have you looked at the DynamicSystems:-BodePlot routine, in Maple 12? It has an option linearmag to control whether the vertical axis has logarithmic scale. Its frequency scale is logarithmic by default (and controllable with its linearfreq option.)

acer

Have you looked at the DynamicSystems:-BodePlot routine, in Maple 12? It has an option linearmag to control whether the vertical axis has logarithmic scale. Its frequency scale is logarithmic by default (and controllable with its linearfreq option.)

acer

I'm not sure whether Joe meant "going that route, with eventual use of unapply" as opposed to "use of unapply". I suspect that he meant the former, because he knows Maple very well. But it can be made explicitly clear, for the benefit of other readers.

It is not the application of unapply, in itself, which causes the conversion of sqrt to an exponent of 1/2. Running these examples above, in the Standard GUI, with 2D output makes output containing either sqrt or ^(1/2) appear with the mathematical surd symbol. But underneath, they are different.

For symbolic `a` the input sqrt(a^2) will result in output of the form a^(1/2). This symbolic evaluation is the point at which conversion from sqrt to power 1/2 takes place. Subsequent unapply w.r.t. symbol `a` isn't where that conversion happens. Although, clearly, going the route of symbolic-evaluation followed by unapply together entail the conversion.

> restart:
>
> z := sqrt(a^2); # the "loss" is here
                                        2 1/2
                                 z := (a )

> lprint(%);
(a^2)^(1/2)
>
> f := unapply(z,a);
                                           2 1/2
                               f := a -> (a )

> lprint(%);
a -> (a^2)^(1/2)
>
> f(4);
                                       1/2
                                     16

The above may be contrasted with what happens when the sqrt() is embedded within a procedure. In that case, sqrt() is not preempted by the evaluation at nonnumeric symbol `a`.

> g := a -> sqrt(a);
                               g := a -> sqrt(a)

> lprint(%);
a -> sqrt(a)
>
> g(4);
                                       2

None of this is anything new, of course. It's old news. And it's what underlies the problem of the original example. (I recall trying to explain once before, on here.)

Now, what could be done about this state of affairs? Could `^` expressions be simplified at uniquification time? Could the eval() routine substitute calls of the form `^`(...,1/integer) with calls to sqrt() or root(), in the case that the evaluation point is numeric?

acer

Thanks Joe, but I was not surprised that it worked OK for `&*`.

I'm wondering why it doesn't work for `^`, `*`, and `+`. As I believe that I showed, op(0,..) of such things can be accessed.

acer