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

As Roman explained, the `expand` command can take you from (a+b)^9 to the expanded formula.

> formula:=(a+b)^9:

> sort(expand(formula));
     9      8         7  2       6  3        5  4        4  5       3  6
    a  + 9 a  b + 36 a  b  + 84 a  b  + 126 a  b  + 126 a  b  + 84 a  b 

             2  7        8    9
       + 36 a  b  + 9 a b  + b 

Since your post was cut short, it wasn't clear whether you were looking for a way to get from T below to S below (where n is not a specific positive integer),

> S:=Sum(binomial(n,i)*a^i*b^(n-i),i=0..n);
                        n                             
                      -----                           
                       \                              
                        )                   i  (n - i)
                       /    binomial(n, i) a  b       
                      -----                           
                      i = 0                           

> T:=simplify(value(S)) assuming n::posint;
                                         n
                                  (a + b) 

acer

As Roman explained, the `expand` command can take you from (a+b)^9 to the expanded formula.

> formula:=(a+b)^9:

> sort(expand(formula));
     9      8         7  2       6  3        5  4        4  5       3  6
    a  + 9 a  b + 36 a  b  + 84 a  b  + 126 a  b  + 126 a  b  + 84 a  b 

             2  7        8    9
       + 36 a  b  + 9 a b  + b 

Since your post was cut short, it wasn't clear whether you were looking for a way to get from T below to S below (where n is not a specific positive integer),

> S:=Sum(binomial(n,i)*a^i*b^(n-i),i=0..n);
                        n                             
                      -----                           
                       \                              
                        )                   i  (n - i)
                       /    binomial(n, i) a  b       
                      -----                           
                      i = 0                           

> T:=simplify(value(S)) assuming n::posint;
                                         n
                                  (a + b) 

acer

I disagree with that principal as you've stated it applying to Maple (as it now stands).

For a product, `op` is a straightforward command for obtaining the multiplicands, which is a mathematical operation. Picking apart a product's multiplicands can be prefaced by a type check, to distinguish it from other `op` applications. Those two internal routines that you cited, while quite possibly useful for the task at hand, are undocumented and/or no more mathematical than `op` as applied above.

Since Maple itself often blurs such nominal distinctions and functionality, what's the point of rigid adherence to a lofty ideal?

"Pragmatism. Is that all you have have to offer?" - Guildenstern

acer

I disagree with that principal as you've stated it applying to Maple (as it now stands).

For a product, `op` is a straightforward command for obtaining the multiplicands, which is a mathematical operation. Picking apart a product's multiplicands can be prefaced by a type check, to distinguish it from other `op` applications. Those two internal routines that you cited, while quite possibly useful for the task at hand, are undocumented and/or no more mathematical than `op` as applied above.

Since Maple itself often blurs such nominal distinctions and functionality, what's the point of rigid adherence to a lofty ideal?

"Pragmatism. Is that all you have have to offer?" - Guildenstern

acer

The desirable goal seems not to avoid `op`, but rather to find a single methodology which automatically does the simplification for expressions in the given class. (Hence, more examples might be useful, although we might be able to guess the general class as involving rational powers, etc.)

In your subs/eval code, the foerknowledge of the power 1/3 & 3 seemed key. An automatic method wouldn't rely on having determined that by inspection.

acer

The desirable goal seems not to avoid `op`, but rather to find a single methodology which automatically does the simplification for expressions in the given class. (Hence, more examples might be useful, although we might be able to guess the general class as involving rational powers, etc.)

In your subs/eval code, the foerknowledge of the power 1/3 & 3 seemed key. An automatic method wouldn't rely on having determined that by inspection.

acer

And what you wrote there (including &^ vs Power) is good to know, and to be reminded about.

acer

And what you wrote there (including &^ vs Power) is good to know, and to be reminded about.

acer

Curious coincidences are fascinating. I might only imagine it, but it seems to happen often that some topic in Maple comes up in a cluster of different places.

For some weeks now, I've been hoping to find time for a semi-finished blog post, about how one might "load" a function from a "3rd party" .dll while in Maple, and then pass that to another external routine using the techniques of address+function-pointer. The idea is to get better efficiency when using Compiler:-Compile'd routines, as opposed to using the usual, less direct evalMapleProc callback. I hope to find time to finish the post in about 2 weeks.

And then by another coincidence, the same technique came up as the way to solve a very similar issue is a project I was working on last week. And now Axel mentions what sounds like the same thing in essence.  (I'm not at all surprised that Axel would have done it -- just amused that it arises right now.)

acer