Assumptions can be tricky. When you place assumptions on a name in Maple then what happens is that Maple creates a new instance of that name. But it doesn't always affect any other instance of the name. This is one of those situations.

Once you make those assumptions on a and b, then you have to be more careful if you subsequently want to substitute for instance of a and b which don't have them.

The a and b in your definition of f do not have assumptions on them, per se. Sure, when you call f then maple uses its lexical scoping functionality to get them from an outer level. That's how it makes your convenient simplification of sqrt(b^2) work out. But in order to substitute into eval(f) you would need to change the original a and b.

> restart:

> f := x -> (a*b)/sqrt((a*cos(x))^2 + (b*sin(x))^2):
> assume (a > 0, b > 0):

> subs([a=14, b=20], eval(f));
                                        a b
                      x -> -----------------------------
                                 2       2    2       2
                           sqrt(a  cos(x)  + b  sin(x) )

> subs([':-a'=14, ':-b'=20], eval(f));
                                        280
                     x -> -------------------------------
                                         2             2
                          sqrt(196 cos(x)  + 400 sin(x) )

And the nice simplification that you wanted from f will still obtain.

> eq2 := 20.3 = f(Pi/2);
                               eq2 := 20.3 = a~

You can then plot it.

plot(subs([':-a'=14, ':-b'=20], eval(f)), 0..2*Pi, coords = polar);

Do you want a closed form (formulaic) result involving unassigned N, or would it suffice to have a procedure or operator like N -> f(N) ?

Do you want a closed form (formulaic) result involving unassigned N, or would it suffice to have a procedure or operator like N -> f(N) ?

If this were done now then it would be nice if the released version were Maple 8.

However, there may be some forwards compatibility problems related to certain operating systems. On Windows and Solaris it would likely be OK. On Linux (32-bit) there might be glibc problems.

I just "summed" the integers k because that was a simple example to show. You can replace the first instance of k in the add() or sum() calls with whatever expressions involving k that you want.

I just "summed" the integers k because that was a simple example to show. You can replace the first instance of k in the add() or sum() calls with whatever expressions involving k that you want.

Well, it's still slower than seq(), using simpler $ syntax.

> restart: time( [`$`(1..2000000)] );
                                     0.305

> restart: time( [$1..2000000] );
                                     0.290

> restart: time( [seq(1..2000000)] );
                                     0.080

I averaged those timings, with multiple runs.

As Joe pointed out, the time saving is not great. It lessens as the number of terms grows further.

But there may also be a memory saving.

> restart: time( [$1..2000000] ); quit;
                                     0.303
 
bytes used=49481744, alloc=48749856, time=0.45

(new session)
> restart: time( [seq(1..2000000)] ); quit
                                     0.080
 
bytes used=17484760, alloc=16774144, time=0.09

The typing time isn't very interesting, if one is comparing efficiency for say programmatic rather than interactive use.

Well, it's still slower than seq(), using simpler $ syntax.

> restart: time( [`$`(1..2000000)] );
                                     0.305

> restart: time( [$1..2000000] );
                                     0.290

> restart: time( [seq(1..2000000)] );
                                     0.080

I averaged those timings, with multiple runs.

As Joe pointed out, the time saving is not great. It lessens as the number of terms grows further.

But there may also be a memory saving.

> restart: time( [$1..2000000] ); quit;
                                     0.303
 
bytes used=49481744, alloc=48749856, time=0.45

(new session)
> restart: time( [seq(1..2000000)] ); quit
                                     0.080
 
bytes used=17484760, alloc=16774144, time=0.09

The typing time isn't very interesting, if one is comparing efficiency for say programmatic rather than interactive use.

> restart:
> time( [`$`(1..2000000)] );
                                     0.323

> restart:
> time( [seq(1..2000000)] );
                                     0.071

> restart:
> time( [`$`(1..2000000)] );
                                     0.323

> restart:
> time( [seq(1..2000000)] );
                                     0.071

selectremove(x -> member(`mod`(x,4),{0,1}),[seq(1..20)]);

selectremove(x -> member(`mod`(x,4),{0,1}),[seq(1..20)]);

The evaluation rules for $ are different than that of seq(). This comes up on mapleprimes now and then. (It could be a FAQ..)

with(combinat, fibonacci):
array([[k, fibonacci(k), 'modp'(fibonacci(k)-1, 9)+1] $ k = 0 .. 4]);

The evaluation rules for $ are different than that of seq(). This comes up on mapleprimes now and then. (It could be a FAQ..)

with(combinat, fibonacci):
array([[k, fibonacci(k), 'modp'(fibonacci(k)-1, 9)+1] $ k = 0 .. 4]);

First, with procedures,

restart:
f := x -> a*x^2+b*x+c;
f(11);
df := D(f);
df(11);
plot( subs([a=123,b=456,c=789],eval(f)), 0..1000);

Now, with expressions,

restart:
f := a*x^2+b*x+c;
eval(f,x=11);
df := diff(f,x);
eval(df,x=11);
eval(f,[a=123,b=456,c=789])
plot( eval(f,[a=123,b=456,c=789]), x=0..1000);

Here's what you were doing before. You set up f as an operator (a type of Maple procedure). And then when you enter f(x) Maple actually evaluates that procedure at the name x. So the result of calling f(x) is then an expression. That's why diff() would succeeds on it as you intend.

So you were mixing functions and expressions. That's not bad, but could be confusing to you. You might find it easier to stick with one or the other, until it becomes familiar.

Notice how, with procedures, the independent variable's name isn't important (and gets left out) when calling D() or plot().