On Fri, Mar 05, 2021 at 09:41:57PM +0100, Ralf Hemmecke wrote: > On 05.03.21 14:25, Waldek Hebisch wrote: > > On Thu, Mar 04, 2021 at 05:02:41PM +0100, Ralf Hemmecke wrote: > >>>> Third, is it a bug that compile TMFORM requires so much RAM? > >>>> We should look into it to see if RAM usage can be reduced. > >>> > >>> AFAICS RAM usage during compilation of TMFORM is really sbcl > >>> bug. It seem that the problem is the same as AWAIC. > >>> Namely, we need to initialise a table and at Lisp level > >>> it is longish segment of code with calls but no jump. > >> > >> Are we talking about TexmacsFormat? > >> > >> The only long list is for CorkFunc. But that is a list of records. What > >> can be difficult for that to be compiled in Lisp? > > > > Just one explanation: Spad data is mutable. Lisp constant > > data is immutable, so Spad _have to_ translate list for CorkFunc > > as a sequence of calls to 'construct'. This is 794 calls, > > not very large number and _should_ not be problem for Lisp > > compiler. But apparently it is. > > First of all, I actually do not understand why this Cork stuff is in > texmacs.spad at all. FriCAS does not generate any Unicode data. > The only way unicode can appear is inside a String. This is what > texmacs.spad takes care of. Obviously, the Texmacs people seem to use > mathematical symbols in strings when working with FriCAS. What I do not > quite understand is why TexmacsFormat has to do that this translation > from unicode encoding to Texmacs encoding. I would have guessed that > Texmacs itself is able to do this conversion.
We have this wonderful thing called ChangeLog and corresponding entry is: 2014-10-01 Bill Page <[email protected]>, Texmacs interface encodes scheme Cork symbols as unicode characters .... IIRC around that time Bill also wrote to the list about it. As I wrote currently due to Guile dependencies Texmacs does not build on my machine. Unfortunately, I was unable to find in-depth documentation of communication format used by Texmacs. Few things I know are from experimentaion... > Anyway, attached you find a modified texmacs.spad, where I simply > translated the List(Record(key:SI, entry:String)) into a simple > List(String) and constructed the respective HashTable from that list. > On my laptop, the compilation if that texmacs.spad is more or less > instant, at least it takes a few seconds less than the texmacs.spad that > is currently in the repository. Presumably, it takes also less RAM, but > I don't know how to check that. Well, writing integers as strings is not really satisfactory solution. OTOH, given how problematic TMFORM is we may have no better way... > > AWAIC produces more than > > Sorry, what is AWAIC? Table of atomic data. It is (maybe earlier version) in the FriCAS wiki. Kurt Pagani (I am not sure, but probably he produced Spad translation of the table) some time ago wrote about it. While not a top priority item it would be nice to include it, or at least have it as working "optional package". Unfortunatly, ATM compilation with sbcl fails (clisp and ECL can compile it). To say the truth, precomputed tables are quite useful to speed up computations. For example, standard trick to speed up work with towers of finite fields is to use precomputed table of embeddings. So better (well, reasonable) handling of intialized tables would be quite useful. > >> Maybe it helps to list > >> the data as a list of lists and do the construction a bit differently. > > > > AFAICS there is no reasonable workaround at Spad level... > > I wonder whether my attempt might work. I think it should work. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210305233252.GC37163%40math.uni.wroc.pl.
