A useful suggestion, djc.

I wonder why `expand/Sum` and `student/expand/Sum` differ in this way. (Are students less likely to handle infinite bounds?!)

interface(verboseproc=3):
eval(`expand/Sum`);
eval(`student/expand/Sum`);

acer

Yes, I already pointed out that the wording of the error message was not good.

I mentioned that I didn't have Maple in front of me at the time, to check which symbolic quantity would act differently. As usual when I go by memory, I get the idea right but the detail wrong.

> Pi(17);
                                    Pi(17)
 
> Pi(17.0);
                                   Pi(17.0)
 
> evalf(Pi(17));
                                    Pi(17)
 
> evalf(Pi(17.0));
                                   Pi(17.0)

There are lots of expressions in Maple which evaluate to numeric under evalf, but which would not do so if first applied to an argument (as if they were operators).

Brushing off the expression/operator distinctions, even if only for (complex) numeric values, if a bad habit, and is asking for future trouble.

acer

Yes, I already pointed out that the wording of the error message was not good.

I mentioned that I didn't have Maple in front of me at the time, to check which symbolic quantity would act differently. As usual when I go by memory, I get the idea right but the detail wrong.

> Pi(17);
                                    Pi(17)
 
> Pi(17.0);
                                   Pi(17.0)
 
> evalf(Pi(17));
                                    Pi(17)
 
> evalf(Pi(17.0));
                                   Pi(17.0)

There are lots of expressions in Maple which evaluate to numeric under evalf, but which would not do so if first applied to an argument (as if they were operators).

Brushing off the expression/operator distinctions, even if only for (complex) numeric values, if a bad habit, and is asking for future trouble.

acer

If I recall, that error can occur when expressions and procedures are mixed. It's not a very clear wording. I don't have Maple right now, but you might try,

fsolve( tt->zerovalue(tt)-8, 195..200);

fsolve( 'zerovalue'(tt)-8, tt=195..200);

While Maple can treat 8 as an operator -- 8(17) gives 8, etc -- it's not true of general symbolic or exact radical numeric quantities. So it seems more consistent to disallow 8 to be used alongside zerovalue, than to have a more confusing behavioural discrepency between 8 and sqrt(2) say.If I recall, not everyone agrees on this.

acer

If I recall, that error can occur when expressions and procedures are mixed. It's not a very clear wording. I don't have Maple right now, but you might try,

fsolve( tt->zerovalue(tt)-8, 195..200);

fsolve( 'zerovalue'(tt)-8, tt=195..200);

While Maple can treat 8 as an operator -- 8(17) gives 8, etc -- it's not true of general symbolic or exact radical numeric quantities. So it seems more consistent to disallow 8 to be used alongside zerovalue, than to have a more confusing behavioural discrepency between 8 and sqrt(2) say.If I recall, not everyone agrees on this.

acer

You could try something like this,

Explore(DEtools[DEplot]({diff(x(t),t) = v(t), diff(v(t),t) = c*v(t)+k*sin(x(t))},
                        [x(t),v(t)],t=0..20,
                        [[x(0)=A,v(0)=B],[x(0)=A+Pi,v(0)=B],
                         [x(0)=A,v(0)=-B],[x(0)=A+Pi,v(0)=-B]],
                        arrows=none));

When the dialogue box pops up, set the ranges something like this (adjust if you wish),

  A:      0.0     5.0
  B:     -5.0     0.0
  c:     -1.0    -0.1
  k:     -1.0    -0.1
  t:   skip
  arrows:  skip
  none:  skip

Make sure that it runs in a "New" kernel connection.

acer

You could try something like this,

Explore(DEtools[DEplot]({diff(x(t),t) = v(t), diff(v(t),t) = c*v(t)+k*sin(x(t))},
                        [x(t),v(t)],t=0..20,
                        [[x(0)=A,v(0)=B],[x(0)=A+Pi,v(0)=B],
                         [x(0)=A,v(0)=-B],[x(0)=A+Pi,v(0)=-B]],
                        arrows=none));

When the dialogue box pops up, set the ranges something like this (adjust if you wish),

  A:      0.0     5.0
  B:     -5.0     0.0
  c:     -1.0    -0.1
  k:     -1.0    -0.1
  t:   skip
  arrows:  skip
  none:  skip

Make sure that it runs in a "New" kernel connection.

acer

You originally had two different problems. The second problem, that `i1` returns a nonreal value for some omega in the range, is still present. See bits about Re() and Im() above. Try calling `i1`, as you have it now, for some values, to see what it returns.

acer

You originally had two different problems. The second problem, that `i1` returns a nonreal value for some omega in the range, is still present. See bits about Re() and Im() above. Try calling `i1`, as you have it now, for some values, to see what it returns.

acer

I presume that you want to make the plot (file) creation programmatic, so that interactive plot exporting following plotsetup(maplet) is not a viable choice.

It doesn't look quite as polished, but how about using plots:-logplot instead of plot?

It looks like a bug, that the axis[2]=[mode=plot] option is not being recognized as incompatible with the commandline plotps driver.

acer

If you look again, more closely, you should be able to see that my eval(expr,M=1) did not compute the integral. The output of that was an inert Int call (without M).

 (**) restart:
 (**) expr:=Int(x*M,x=0..1/(3*M));
                                         1
                                        ---
                                        3 M
                                       /
                                      |
                             expr :=  |     x M dx
                                      |
                                     /
                                       0

 (**) eval(expr,M=1); # notice the result
                                     1/3
                                    /
                                   |
                                   |     x dx
                                   |
                                  /
                                    0

 (**) lprint(%);
Int(x,x = 0 .. 1/3)

I notice that you still have the name M around, even after the eval or the subs. It is possible that your expression (the result of those p() function calls) contains an escaped local M which is distinct from the global name M. Try wrapping around your expression a call to convert such names to their global versions, ie,

eval( convert(expr,`global`), M=1);

It is possible that you had a situation similar to this:

 (**) restart:
 (**) p:=proc() local M; return 1/(3*M); end proc:
 (**) expr:=p();
                                           1
                                  expr := ---
                                          3 M

 (**) eval(expr,M=1);
                                       1
                                      ---
                                      3 M

 (**) eval(convert(expr,`global`),M=1);
                                      1/3

acer

If you look again, more closely, you should be able to see that my eval(expr,M=1) did not compute the integral. The output of that was an inert Int call (without M).

 (**) restart:
 (**) expr:=Int(x*M,x=0..1/(3*M));
                                         1
                                        ---
                                        3 M
                                       /
                                      |
                             expr :=  |     x M dx
                                      |
                                     /
                                       0

 (**) eval(expr,M=1); # notice the result
                                     1/3
                                    /
                                   |
                                   |     x dx
                                   |
                                  /
                                    0

 (**) lprint(%);
Int(x,x = 0 .. 1/3)

I notice that you still have the name M around, even after the eval or the subs. It is possible that your expression (the result of those p() function calls) contains an escaped local M which is distinct from the global name M. Try wrapping around your expression a call to convert such names to their global versions, ie,

eval( convert(expr,`global`), M=1);

It is possible that you had a situation similar to this:

 (**) restart:
 (**) p:=proc() local M; return 1/(3*M); end proc:
 (**) expr:=p();
                                           1
                                  expr := ---
                                          3 M

 (**) eval(expr,M=1);
                                       1
                                      ---
                                      3 M

 (**) eval(convert(expr,`global`),M=1);
                                      1/3

acer

Obligatory quote.

Sorry, I just had to get that in. Personally, I don't mind.

acer

A minor simplification of Alejandro's technique (or temporarily rebinding `+` to its original global version),

> restart:
> with(Units:-Standard):

> use `+` = :-`+` in
> ee:=4*Unit(m)=3*Unit(m)+p/(1000*Unit(kg/m^3)*9.86*Unit(m*s^(-2))):
> end use:

> isolate(ee,p):
> convert(combine(rhs(%),units),units,bar);
                      0.09860000000 [bar]

The basic idea is that it is the Units:-Standard:-`+` version of `+` which is so picky about commensurability of units (dimensions). So, temporarily, one can revert just that. It only need to be reverted for the creation of the arithmetic expression.

acer

A minor simplification of Alejandro's technique (or temporarily rebinding `+` to its original global version),

> restart:
> with(Units:-Standard):

> use `+` = :-`+` in
> ee:=4*Unit(m)=3*Unit(m)+p/(1000*Unit(kg/m^3)*9.86*Unit(m*s^(-2))):
> end use:

> isolate(ee,p):
> convert(combine(rhs(%),units),units,bar);
                      0.09860000000 [bar]

The basic idea is that it is the Units:-Standard:-`+` version of `+` which is so picky about commensurability of units (dimensions). So, temporarily, one can revert just that. It only need to be reverted for the creation of the arithmetic expression.

acer