On 6/12/26 8:42 AM, Waldek Hebisch wrote: > >> 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. > > Hmm, that is what 'reduc' is essentially doing. But there is a > catch: reducing with respect to one kernel may expose other ones. > So we order kernels and start reduction from the most complex > one and then repeat this with simpler kernels. Also, we allow > arbitrary algebraic kernels and do not require minimal polynomials > to be monic, so reduction is more complex than in case of roots. >
Because 'reduc' is called by every + - * / =, any tiny optimization could be helpful in the end. My current plan is to do search and replace in parallel, say for alg_ker1^n1*alg_ker2^n2, do transformation for them in one loop. Then loop on the result until no transformation are needed. This should save many memory allocations. Also this opens doors for optimization like sum([e1,e2,e3,...]), mul([e1,e2,e3,...]). - 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/f63006e4-c3c1-4269-9d9e-c4cf8bd033ad%40gmail.com.
