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?

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.

As a workaround one can do something like

rsimp(1)$RootSimplification

to initialize RootSimplification.

Thank you.

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.

%%% (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.

ATM it is not clear to me what to do: doing initialization as Spad
code triggers very bad behaviour in Spad compiler (very long compile
time) and after that in sbcl (running out of memory).

Do you know the real cause of why the compiler behaves so badly?

Ralf

--
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/c7a022df-869a-4bc6-98ab-f7c498056eb8%40hemmecke.org.

Reply via email to