On 6/11/26 11:48 PM, Waldek Hebisch wrote: > > I see, mutiplication in EXPR is probably good enough to pass > our existing tests, but this does not look right. Note that > we may have nested roots and mutiplying two roots may introduce > new denominators. > > In general, representation of Expression is only normal: when > result of an operation is 0 it will give 0 at representation > level, but equal expressions may have different representations. > > AFAICS the following should be OK: > > algreduc((numer(x)*$Rep denom(y) -$Rep numer(y)*$Rep denom(x))::%, > commonk(x, y)) =$Rep 0 >
Thanks, this works (need to tweak signature a bit), but the memory usage grows from 8.5GB to 9.7GB compare to previous (flawed) version. Profile shows lots of time and memory is spent in =$EXPR, reduc$EXPR. As I see it, the purpose of 'reduc' is to simplify algebraic expression, and the purpose of 'algreduc' is to rationalize the denominator depending on getSimplifyDenomsFlag. I can leave 'algreduc' alone. But for 'reduc', I think its implementation is very inefficient. I think, in theory, we can walk the variables of Rep to check for algebraic kernels and do transformation if necessary. I'll report back with numbers. - Qian -- 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 visit https://groups.google.com/d/msgid/fricas-devel/89073314-735f-41c8-9375-ee124a04bd8d%40gmail.com.
