On Thu, Apr 18, 2024 at 01:51:34PM -0700, 'Martin R' via FriCAS - computer algebra system wrote: > OK, I think I have to give up. The InputForm consists of 23 964 324 > atoms. I guess that there is no sensible way to transmit this, right?
Well, compress it. FriCAS internal representation is designed to share subexpressions. Things like %%Q0 take place for definition and than every use just references definition. Convertion to InputForm essentially forces expansion and "unsharing" of subexpression. In principle we could restore sharing using "lambda expression", that is apply anonymous function to arguments, like: (x, y) +-> x^2 + x*y + y^3)(x+1, sqrt(x - 1) + x) 2 +-----+ 3 2 (1) (3 x + 2 x)\|x - 1 + x + 5 x + 1 This is small expression, so anonymous function just adds bulk, but for bigger expressions such form could be much smaller, because arguments are just described once instead of repeating description multiple times. In principle convertion to InputForm could use this, but clearly that would require extra code in Expression and some logic to decide when the result is smaller than more strightforward approach. And InputForm is supposed to rebuild back given value, so there would be need for testing and in principle we may need to fix some interpreter bugs. And there is significant potential for breakage in sbcl: by default FriCAS functions are compiled and sbcl compiler tends to blow up on largish functions which contain no conditionals (I am not sure if lack of conditionals is essential, just my guess). As a safer alternative we could implement 'where' in intepreter (there is no function involved, so no compilation to blow up). Or you could implement a "compress" pass in your interface that walks the tree and identifies all shared subtrees. I mean something like 'minimalise' in 'src/interp/compress.boot'. In somewhat different spirit, interface should allow transmiting large values when needed. And 23 964 324 atoms means few hundreds megabytes. Modern machines can move it from place to place in tens of milliseconds. Pointer walking takes more time, but should be managable, on fast machine sbcl can produce this InputForm in about 50 milliseconds. Of course, the silly 1Gb limit in sbcl means that default version can not do it. With enough memory convertion of input form to string (unparse) takes 9.84s and resulting string has 67Mb. And of course InputForm was not designed for heavy use.. -- 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/ZiGyF4ewjqFQ8KuE%40fricas.org.