Re: [fricas-devel] heap exhausted
On 02/19/2016 10:59 PM, Kurt Pagani wrote: > I'm frequently confronted with this SBCL specific error ... usually it's > my bad - some recursion mistakes or bad design, Yeah, probably the same with me. I'm not yet finished with the analysis, but my suspicion is that I should have been more careful in computing with Laurent series. Multiplication is implemented like this. x : % * y : % == laurent(getExpon x + getExpon y, getUTS x * getUTS y) https://github.com/fricas/fricas/blob/master/src/algebra/laurent.spad#L225 That would explain the high orders that I see. I should probably have used "removeZeroes" in some places. However, I am somehow reluctant to introduce "removeZeroes" into my package. If this is necessary, then I will call this a bug in the FriCAS code and try to provide a patch that would remedy the situation. Otherwise, other users of UnivariateLaurentSeries might fall into the same trap. But wait until I'm finished with the real bug hunting. Ralf -- 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.
Re: [fricas-devel] heap exhausted
Hi Ralf I'm frequently confronted with this SBCL specific error ... usually it's my bad - some recursion mistakes or bad design, so that increasing of "dynamic-space-size" isn't a remedy. However, I had cases where it worked indeed. You might edit the install.sh of fricas_jupyter where the core is about to be built: echo - echo Creating iSPAD core from AxiomSYS ... echo - if [ -f $AXSYS ] ; then echo ")lisp (load \"lisp/sbcl.lisp\")" > acmd -- sbcl --core $AXSYS < acmd; sbcl --dynamic-space-size 3741824 --core $AXSYS < acmd; rm acmd; fi Since in lisp/sbcl.lisp we have the ":save-runtime-options t" it should (according to the SBCL manual) be stored in the executable. Of course, you can create a new AxiomSYS along the same lines ... Just an idea ;) Best regards Kurt ;;; ;;; Save image as iSPAD (call: iSPAD ) ;;; (sb-ext:save-lisp-and-die "iSPAD" :toplevel #'cl-jupyter-user::ispad-main :executable t :save-runtime-options t) )lisp (/ (- sb-vm:dynamic-space-end sb-vm:dynamic-space-start) (expt 1024 2)) -> Value = 1024 )lisp (sb-ext:dynamic-space-size) -> Value = 1073741824 Am 18.02.2016 um 00:47 schrieb Ralf Hemmecke: > H... I now also hit that problem in computations with Laurent series > with seemingly huge coefficients. > > https://www.mail-archive.com/fricas-devel%40googlegroups.com/msg08346.html > > I don't think I am able to compile and install sbcl myself. I'm > relatively happy with "apt-get install sbcl". > > Is there any chance that fricas will be able to pass commandline > arguments to AXIOMsys? > > Ralf > > == > > Heap exhausted during garbage collection: 608 bytes available, 992 > requested. > Gen StaPg UbSta LaSta LUbSt Boxed Unboxed LB LUB !move Alloc Waste > TrigWP GCs Mem-age >0: 0 0 0 0 0 0 0 0 00 > 0 107374180 0 0. >1: 0 0 0 0 0 0 0 0 00 > 0 107374180 0 0. >2: 0 0 0 0 0 0 0 0 00 > 0 107374180 0 0. >3: 0 0 0 0 0 0 0 0 00 > 0 107374180 0 0. >4: 32106 32105 0 0 1923 17241 0 0 0 617581824 > 10384128 107374180 0 1.2702 >5: 8424 8422 0 0 1099 2506 0 059 115008752 > 3119888 200 725 0 0. >6: 0 0 0 0 2870 255 0 0 0 10240 > 0 200 2637 0 0. >Total bytes allocated= 1054837248 >Dynamic-space-size bytes = 1073741824 > GC control variables: >*GC-INHIBIT* = true >*GC-PENDING* = true >*STOP-FOR-GC-PENDING* = false > fatal error encountered in SBCL pid 11521(tid 140737353836288): > Heap exhausted, game over. > > Welcome to LDB, a low-level debugger for the Lisp runtime environment. > ldb> > -- 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.
[fricas-devel] Help needed: Re: heap exhausted
Hi Waldek,
I need some help or at least a hint.
I'm currently investigating why I got...
On 02/18/2016 12:47 AM, Ralf Hemmecke wrote:
> Heap exhausted during garbage collection: 608 bytes available, 992
> requested.
It is anyway strange that the problem appears during garbage collection,
but that doesn't seem to be the real problem, since I don't think that I
am should be using that much memory.
I recomputed mod 1009 and the problem still appears. In fact, at the
moment I am probably very close. It looks like the series implementation
(multiplication) is troublesome.
At some point in the computation, I multiply a laurent series of order
-2 with itself. And, when printed it shows me something of order -2827.
Let me explain the output.
[MEM t, q^(-2)+O(q^(-1))] -- original series
[MEM gt, 2] -- its grade (= -ord)
[MEM t2, O(q^(-2827))]-- this is how t2:=t*t is printed
[MEM gt2, 4] -- grade of t*t
[MEM t2-2, q^(-4)+O(q^(-3))] -- print t2 again
[MEM lct2, 1] -- leading coefficient of t2
[MEM t2, [2, 0, 5, 4, 36, 36, 72, 957]] -- the first 8 coefficients
[MEM t4, O(q^(-5659))]-- t4=t2*t2
The thing is that t is of Finite0Series, which is (in fact) just this
---
Finite0Series(C: CommutativeRing, var: Symbol, cen: C): Exports == Impl
where
UTS ==> UnivariateTaylorSeries(C, var, cen)
ULS ==> UnivariateLaurentSeries(C, var, cen)
Exports ==> Join(UnivariateLaurentSeriesConstructorCategory(C, UTS),
QEtaAlgebra C) with
coerce: Variable(var) -> %
++ \spad{coerce(var)} converts the series variable \spad{var} into a
++ Laurent series.
coerce: ULS -> %
Impl ==> ULS add
Rep ==> ULS
coerce(v : Variable(var)): % == monomial(1, 1)
coerce(s: ULS): % == per s
zero?(x: %): Boolean == order(x, 1) > 0
qetaGrade(x: %): Z == -order(x, 0)
qetaCoefficient(x: %, k: Z): C == coefficient(x, -k)
qetaLeadingCoefficient(x: %): C == leadingCoefficient x
---
So the multiplication is identical to UnivariateLaurentSeries.
After calling the "order" function on t2, the "true" order of t2 should
be stored in the datastructure of t2, after it figured out that some
coefficient is non-zero, right?
I really don't understand why t4=t2*t2 still prints as O(q^(-5659)). The
program crashes with the "heap exhausted" error while computing the
order of t4.
I'll now dig deeper into the code, but I don't think it should happen
that the product of two series of order -2 should result in something
that believes its order might be -2827. Or am I wrong?
Help!
Ralf
--
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.
