Re: [fricas-devel] Re: [BUG] another case of falsely claim an integral is not integrable
On 12/5/20 11:26 PM, Waldek Hebisch wrote: On Sat, Dec 05, 2020 at 09:06:22PM +0800, oldk1331 wrote: Almost sure it is bug when adding new kernel in cache, in function "enterInCache". ATM our handling of kernel cache is unsound. Basicaly, kernel cache assumes order and in fact there are no consistent order on kernels. Can you share more details about this? Still, it shocks me a little that we trade correctness for speed... Currently, IMO correct direction is to limit creation of new kernel and better detect cases when we already created needed kernel. This in necessary to avoid other bugs and with limiting creation of kernels using linear search will be less problematic. I agree. "trigs2explogs" would be a good place to start limiting creation of kernels. Also, does that mean we will move to linear search in the future? On Fri, Dec 4, 2020, 6:11 PM Qian Yun wrote: If we replace gg := eval(gg0, tgg0, tgg1) in integrat.spad with gg := trigs2explogs(gg0, []) then this bug disappears. But I'm still not clear about the root cause of this bug. Have you tried 'subst' instead of 'eval'? 'subst' is dumber and hence ususaly safer than 'eval'. I tried using "subst" instead of "eval", doesn't solve this bug. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/093b937f-77e8-b40a-3e46-2f5178bba028%40gmail.com.
Re: [fricas-devel] Re: [BUG] another case of falsely claim an integral is not integrable
On Sat, Dec 05, 2020 at 09:06:22PM +0800, oldk1331 wrote: > Almost sure it is bug when adding new kernel in cache, in function > "enterInCache". ATM our handling of kernel cache is unsound. Basicaly, kernel cache assumes order and in fact there are no consistent order on kernels. Many problems would go away if we would switch to linear search for kernels (awoiding use of order). But that would slow down unormously routines making heavy use of kernels (mainly series expansion and limits). And some problem would remains. Currently, IMO correct direction is to limit creation of new kernel and better detect cases when we already created needed kernel. This in necessary to avoid other bugs and with limiting creation of kernels using linear search will be less problematic. One recuring problem is that expression routines try to be smart and perform various simplifications. In integrator we need full control of kernels and _any_ kernel trasformation without explicit request from integrator is a bug. In cases where integrator depended on some behind the scene kernel manipulations in other routines we need to make sure that integrator still have sufficient control. This may require creating new versions of auxiliary routines. Let me add that large part of 'integrat.spad' is a quick hack to mitigate some bad effects of transformations in other routines. This should be replaced by new routine... > > On Fri, Dec 4, 2020, 6:11 PM Qian Yun wrote: > > > > > If we replace > > gg := eval(gg0, tgg0, tgg1) > > in integrat.spad with > > gg := trigs2explogs(gg0, []) > > then this bug disappears. But I'm still not clear about the > > root cause of this bug. Have you tried 'subst' instead of 'eval'? 'subst' is dumber and hence ususaly safer than 'eval'. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20201205152658.GA14442%40math.uni.wroc.pl.
[fricas-devel] Re: [BUG] another case of falsely claim an integral is not integrable
Almost sure it is bug when adding new kernel in cache, in function "enterInCache". On Fri, Dec 4, 2020, 6:11 PM Qian Yun wrote: > > > Tracing shows the computation diverge at "extendedEuclidean" in > > "normalHermiteIntegrate" of TranscendentalHermiteIntegration in > > intrf.spad. > > The reason that "extendedEuclidean" gives wrong result is that > something wrong happened earlier: there are expressions with > the same appearance but have different kernel underneath. > > The creation of different kernels happens at "trigs2explogs" > in "integrate" in integrat.spad. > > The definition of "trigs2explogs" seems alright, still it's > unknown why the same input may produce different kernels. > > If we replace > gg := eval(gg0, tgg0, tgg1) > in integrat.spad with > gg := trigs2explogs(gg0, []) > then this bug disappears. But I'm still not clear about the > root cause of this bug. > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAGBJN91tvF4HV_qW4sVmkVSFptdqqjQHpDiHC%3DDeaXqY2bJXpA%40mail.gmail.com.
