addendum
Shifting doesn't work either because of the preceding evals (k->k-1), so
one might sum from 1..n and add eval(x,k,0). If a<0? Splitting and
adding x(0)?
a:=low segment s
b:=high segment s
if a=0 then
eval(u::F, k, 1 + b) - eval(u::F, k, 1) + eval(x,k,0)
else
if a>0 then eval(u::F, k, 1 + b) - eval(u::F, k, a)
-- else?
On 03/06/2026 22:23, Kurt Pagani wrote:
You are right, the err stems from line 2773.
I have extracted the relevant steps and it's the last one which gives
the error, obviously because of the subst k --> k-1. One solution might
be to shift the boundaries to k=1..n+1 and adjust x correspondingly?
This, however, would mean some preprocessing ...
R ==> INT
F ==> EXPR R
K ==> Kernel F
IK ==> IndexedExponents K
SMP ==> SparseMultivariatePolynomial(R, K)
GSM ==> GosperSummationMethod(IK,K,R,SMP ,F)
newk():K == kernel(new()$Symbol)
x:F:=k*factorial(k)
--x:=4^k/binomial(2*k, k)
s:=k=0..n
k := kernel(variable s)@K
x1:=eval(x,k,k::F-1)
f:=normalize(x/x1)
u0 := GospersMethod(f, k, newk)$GSM
u:=x1 * eval(u0::F, k, k::F-1 ) ---> k(k - 1)!
eval(u::F, k, 1 + high(segment(s))) - eval(u::F, k, low(segment(s)))
On 03/06/2026 20:22, Waldek Hebisch wrote:
On Wed, Jun 03, 2026 at 03:20:57PM +0200, Kurt Pagani wrote:
I get the following error in certain sums when starting at k=0:
(1) -> sum(4^k/binomial(2*k, k), k=0..n)
>> Error detected within library code:
catdef: division by zero
eval(4^k/binomial(2*k, k),k=0) --> 1
eval(4^k/binomial(2*k, k),k=-1) --> above error message
I suspect the error could be triggered in innersum(x, k) in
combfunc.spad
(line 2785/eval k::F-1 ??) but am not sure.
There are similar examples like:
sum(n*factorial(n), n=0..m)
AFAICS the error is in line 2773:
eval(u@F, k, 1 + high(segment(s))) - eval(u@F, k, low(segment(s)))
Previous evals are symbolic, so should not signal error. The
above substitutes numeric value which is not always possible.
We need smarter function instead of 'eval' so that it can correctly
evaluate 0/0 things. Taking limit may help, but limits of
binomial expressions can be tricky, that is result may depend on
how exactly one approaches to limit. So it needs some analysis
before we implement something smarter.
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/19e70b95-f9c5-4d02-a22a-48ac9eae3418%40gmail.com.
