On Mon, Mar 25, 2024 at 07:00:44PM +0100, Ralf Hemmecke wrote:
> On 3/25/24 16:13, Waldek Hebisch wrote:
> > This is a bug in FriCAS. RootSimplification uses interpreter to
> > initialize its variables. However, this does not work when first
> > use of RootSimplification is inside a function.
>
> Ah. OK. Thank you.
>
> What about documenting this?
Well, normal thing to do is to fix a bug. Documenting a bug is
least resort, when fix is too hard.
> > It is not clear whom to blame, RootSimplification uses interpreter
> > differently than rest of algebra.
>
> Oh. I actually do not understand at all, why you implemented
> RootSimplification via calling "interpret". Is that really necessary?
> You mentioned that the compiler behaves badly with the respective SPAD
> initialization. But what exactly does that mean?
> The expression in rp3s looks big, but why would that be unmanageable by
> by the compiler?
>
> Probably you also do not like that the interpreter is called in SPAD
> code. That looks strange to me, more like a workaround. AFAIU, it is a
> workaround.
Yes, using interpreter is a workaround. There are actually two releated
problems. One is long compile time in Spad compiler. That should be
eventually fixed by rewiting Spad compiler to use deffierent approach.
More precisely, currently Spad compiler uses recursive approach to
compiling expressions. However, overloading means that given expression
may be analysed multiple times (one for each applicable type).
With recursive approach parts of expression are analysed multiple
times, leading to runtime which is exponential is size of expression.
Alternative is a bottom up approach, where compiler produces all
possible alternatives for each subexpression. On simple expressions
this may be more work than recusive approach (which may finish before
exploring all alternatives), but on more complex expression bottom up
approach avoid reding the same work again and again. Interpreter
uses a variation of bottom up approach, and for expressions in case
is much faster than Spad compiler. Interpreter commits early to one
alternative so may reject some code that Spad compiler accepts.
Also, interpreter has its own quirks that may cause very long
typechecking time. But in this case interpreter works in resonable
time and IMO Spad compiler in the future should use bottom up
approach.
The second problem is sbcl compilation. Apparently when sbcl
sees largish piece of code containing no jump it takes it as
excelent opportunity to optimize. It tries to collect a lot
of information about the code and runs out of memory. Using
interpreter we avoid Lisp compiler. Note that expression I use
are toplevel expressions which are subject to pure interpretation.
Using interpreter function would probably solve problem of Spad
compile time, but we still would have problem with sbcl
compiler.
BTW: I did not try largest expression, but on a smaller expression
sbcl runs out of memory, but ECL works. Still, resulting C
compile time is large (and memory use is large), so those expression
apparently stretch all optimizers. gcc probably got more
tuning on "bad" examples so it handles it (with degraded performance),
but sbcl simply blows up.
> > BTW: There is another trouble with interpreter and RootSimplification:
> > initializing RootSimplification also assigns values to a few variables
> > in user session.
>
> That is a *big* trouble if you use variables that are likely to be used
> in user code before the initialization happens in RootSimplification.
> The simplest workaround for this is probably to use variables starting
> with underscore, i.e. _a, etc. or generate a new symbol and concatenate
> with "_a", "_b", etc. and replace the variables in the string
> expressions of rp... by the respective symbol before it it given to
> interpret. str_to_expr could be a good place to do that string
> modification. Also "eI" is a bad name for hidden initialization.
Well, I hope for better solution. When I wrote the code I (wrongly)
assumend that all variables will be local to the evaluation and will
not affect what user sees. Apparently, currently the only way to
get local variables in interpreter is to use a function. But this
is exactly what I want to avoid, because of sbcl compile time for
a function.
> %%% (1) -> a: Integer := 1
>
> (1) 1
> Type:
> Integer
> %%% (2) -> rsimp(1)$RootSimplification
>
> Cannot convert right-hand side of assignment
> a
>
> to an object of the type Integer of the left-hand side.
Yes.
--
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/ZgHyiHM2BlMBHGiP%40fricas.org.
