Messages by Thread
-
-
[fricas-devel] 'make dist'
Waldek Hebisch
-
[fricas-devel] Error detected within library code: Shouldn't happen first time called.
'Nasser M. Abbasi' via FriCAS - computer algebra system
-
[fricas-devel] bulding hsbcl on debian 11
Ralf Hemmecke
-
[fricas-devel] ModMonic
Waldek Hebisch
-
[fricas-devel] build_helper
Ralf Hemmecke
-
[fricas-devel] FriCAS 1.3.9 is released
Waldek Hebisch
-
[fricas-devel] how to use unexposed operation addrows!
张志雄
-
[fricas-devel] nested roots
Ralf Hemmecke
-
[fricas-devel] Y function
Rafael Andraschko
-
[fricas-devel] Release
Waldek Hebisch
-
[fricas-devel] fricas citation page
Ralf Hemmecke
-
[fricas-devel] Adding not string based routine(s) to Unittest
Grégory Vanuxem
-
[fricas-devel] install.rst
Waldek Hebisch
-
[fricas-devel] fricas-wiki is still down
Ralf Hemmecke
-
[fricas-devel] Disabling verbose output of FriCAS built with ECL
Grégory Vanuxem
-
[fricas-devel] XHashTable
Ralf Hemmecke
-
[fricas-devel] which lisp to use when building Fricas, and how to control which one to use?
'Nasser M. Abbasi' via FriCAS - computer algebra system
-
[fricas-devel] [PATCH] misc cleanups and typo fixes
Qian Yun
-
[fricas-devel] Packaging FriCAS for Fedora
Nicholas Chisholm
-
[fricas-devel] modmap selection
Ralf Hemmecke
-
[fricas-devel] FriCAS status
hebisch
-
[fricas-devel] laurent series
Ralf Hemmecke
-
Re: [fricas-devel] laurent series
Waldek Hebisch
-
[fricas-devel] Re: [fricas-d> On Mon, Jun 12, 2023 at 10:49:02AM +0200, Ralf Hemmecke wrote:,>> Dear Waldek,,>>,>> I am heavily using UnivariateLaurentSeries. Unfortunately now I am running,>> into a memory problem (See end of mail.),>>,>> These numbers don't tell me anything, but what I see is that my main memory,>> (32 GB) is filled completely before I em put into ldb.,> ,> Below it look that your FriCAS is configured to use 11GB. If you,> have 32 GB you can try to give more memory to FriCAS (or less to,> figure out how far you can get in smaller memory).,> ,>> Unfortunately, I am totally inexperienced to figure out relevant information,>> with ldb.,>>,>> However, I think the problem must come form having stored all intermediate,>> result that are not garbage collected.,>>,>> -- red loop:=[288, 0][[28158, 9], [28150, 1]],>> -- redx:=[288, 0][[28158, 9], [28150, 1]],>> 196,>>,>> What you read above are some statistics I printed during the computation to,>> figure out the source of the problem.,>>,>> The computation goes with two laurent series, with orders -288 and 0.,>> The coefficient(ser,0) has 28158 binary digits in the numerator and 9 binary,>> digits in the denominator. Similar for the second series.,>>,>> If I estimate the amount of memory, then I roughly get,>>,>> (28158/8) bytes * 289 (num of coefficients -288..0) * 200 (num of such,>> series),>>,>> That gives roughly 30 MB if I am not wrong.,>>,>> I understand that UnivariateLaurentSeries internally must keep some,>> structure in order to compute the next coefficient (I'm actually only,>> interested in the coefficients -289..0, eventually.),> ,> There is overhead of list node per stream term. In your case this,> should be negligible (list node needs 16 bytes, your data is much,> larger).,> ,> I would have doubts about number of series that you keep. Namely,,> to be able to compute next terms series keep references to arguments.,> For multiplication that means argument to product are needed as long,> as product is needed. If you do say 1000 series multiplications,,> then you actually keep all arguments to multiplications which,> probably goes in thousends. Addition can discard "used" terms,,> but is you add a product than this still keeps reference to arguments,> of multiplication.,> ,> When doing computations with series conservative assumption,> is that you need to keep whole computation tree in memory.,> In other words, memory taken by series can be garbage collected,> only whan whole computation is done and all resulting series,> are discarded.,> ,>> Anyway. I have no clue how 30 GB are filled.,>>,>> Question, how can I find out whether there is some stuff that could perhaps,>> be garbage collected. With gnome-system-monitor I sometimes see jumps from,>> 7.5GB to 7GB, i.e. there is some garbage collection going on, but not,>> enough.,>>,>> I have already tried to additionally extend the prinipal part of any,>> argument series. The memory is filled with and without that strategy.,>>,>> Of course, the whole proplem can lie on my side, but since I currently do,>> not know how to figure out where in my code I would have to explicitly,>> remove a reference to some memory,,>>,>> I understand that it is not hard till impossible for you to give me some,>> hint without seeing my code, but I am hoping.,>>,>> Let me say just this. The series involve is the Klein j-invariant. From,>> which I will have to roughly have to take the 17th power of j(tau) and of,>> j(17 tau) and do reductions of another Laurent series with some "basis",>> polynomials bi(j,j17) where p is of degree < [17,17] in both series.,>> Then I multiply the result with j and reduce again by the basis. I need,>> roughly 300 of these rounds, but get my memory full in round 200.,> evel] laurent series
Ralf Hemmecke
-
[fricas-devel] laurent-series
Ralf Hemmecke
-
[fricas-devel] Aldor and FOAM-USER::|fiRaiseException|
Grégory Vanuxem
-
[fricas-devel] Modifying function selection order
Grégory Vanuxem
-
[fricas-devel] Re: [aldor-devel] Renaming $ to %
Ralf Hemmecke
-
[fricas-devel] Convert versus coerce
Waldek Hebisch
-
[fricas-devel] half of rowEchelon
Ralf Hemmecke
-
[fricas-devel] fyi, ChatGPT for integration added to one file
'Nasser M. Abbasi' via FriCAS - computer algebra system
-
[fricas-devel] Tensor Product
Sid Andal
-
[fricas-devel] Matrices of matrices
Waldek Hebisch
-
[fricas-devel] Hashable
Waldek Hebisch
-
[fricas-devel] Partial exposure
Waldek Hebisch
-
[fricas-devel] Coordinates for plotting
Waldek Hebisch