oldk1331 wrote:
>
> I discovered this bug while I am digging another one:
>
> Martin's orignal integral: integrate((a + b*x)/((3 + x^2)*(1 - x^2)^(1/3)), x)
> fails. However integrate(1/((3 + x^2)*(1 - x^2)^(1/3)), x) succeeds
> while integrate(a/((3 + x^2)*(1 - x^2)^(1/3)), x) fails:
>
> (1) -> integrate(a/((3 + x^2)*(1 - x^2)^(1/3)), x)
>
> >> Error detected within library code:
> catdef: division by zero
>
> Note that this is not an "integration error", it comes from catdef.
>
> More interestingly, the third time you invok this expression,
> it stucks instead of giving this error.
>
> ")set break break" and the backtrace leads me to bringDown
> from FunctionSpaceReduce from pfo.spad.
>
> After some "print", I find that there's:
> nn : Integer := 1
> ......
> K2Z k == ... setelt!(redmap, k, random(nn)$Z)::F
> ......
> eval(f, lk := kernels f, [K2Z k for k in lk])
>
> The nn is supposed to be the initial seed, however
> random(nn) will always return 0 before nn get modified
> elsewhere. So when f includes a kernel in denominator,
> the divesion by zero error will occur.
nn is set by 'newReduc'. 'newReduc' should be called before
'bringDown' -- if it is called too late this is a bug.
> This part of code is modified by r1976, which seems to
> have bugs:
>
> 1) The default value for nn is incorrect, and nn is not
> updated after being used in K2Z.
The FSRED code is somewhat fishy. First we estimate
how much randomness we need and call 'newReduc'.
Then there are several calls to 'bringDown'. If we
have the same kernel in two calls the kernel should
be replaced by the same integer. In other words
we should get consistent reduction in several calls.
After we are done with one divisor we call 'newReduc'
and start new series of calls to bringDown'.
AFAICS code using FSRED has design problem: due to random
choice we may reduce denominator to 0. I believe that
in such case we should restart computations using different
reduction. But current code just signals error (which is
definitely wrong).
> 3) Before r1976, seems this integration still doesn't return
> in a long time, maybe there's a bug somewhere else.
Computations with divisors may be quite heavy and take very
long time (days, months and possibly years). It may also
need substantial memory, so after long computation you
may funally run out of memory. Speeding up computations
with divisors is essentially a research problem: there
are some papers giving theoretical algorithms, but complexity
estimates are high enough that it is not clear if such
algorithms will work well in practice. And I am not
aware of descriptions of practical implementations.
--
Waldek Hebisch
--
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 fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
