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.
