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.

## Advertising

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.