Я не большой поклонник обрезания бесконечной суммы при некотором значении верхней границы для n
, по крайней мере, не демонстрируя ни символически, ни численно, что это оправдано. То есть, это измельчение не дает ложного представления о сходимости.
Итак, вы спросили, как заставить его работать "тяжелее". Я буду считать, что это означает, что вы тоже можете позволить evalf/Sum
самому решать, будет ли каждая бесконечная числовая сумма сходиться - вместо того, чтобы вручную усекать ее до некоторого конечного значения для верхнего значения диапазона для n
.
Для забавы и предостережения я также делю числитель и знаменатель K
на потенциально большой вызов exp
(потенциально намного больший, чем 1). В этом может не быть необходимости.
restart;
lapeq:=diff(v(x,y),x$2)+diff(v(x,y),y$2)=0:
bcs:=v(x,0)=0,v(0,y)=0,v(1,y)=0,v(x,1)=100:
sol1:=pdsolve({lapeq,bcs}):
vxy:=eval(v(x,y),sol1):
K:=op(1,vxy):
J:=simplify(combine(numer(K)/exp(2*Pi*n)))
/simplify(combine(denom(K)/exp(2*Pi*n))):
F:=subs(__d=J,
proc(x,y) local k, m, n, r;
if y<0.8 then
r:=Sum(__d,n=1..infinity);
else
UseHardwareFloats:=false;
m := ceil(1*abs(y/0.80)^16);
r:=add(Sum(eval(__d,n=m*n-k),n=1..infinity),
k=0..m-1);
end if;
evalf(r);
end proc):
plot3d( F, 0..1, 0..0.99 );
Естественно, это медленнее, чем простое измельчение терминов для получения конечной суммы. И вы можете быть удовлетворены некоторой техникой, которая устанавливает, что суммы исключенных терминов ничтожны.