On Sun, Jun 14, 2026 at 10:40:59PM +0800, Qian Yun wrote: > I keep finding new things down this rabbit hole... > > After latest patch, profiler shows smaller?$EXPR > takes a lot of time. So I took a look. > > triage$Kernel calls smaller?$EXPR. > It is used to sort the kernels. > > smaller?$EXPR calls > smaller?(numer(x)*denom(y), numer(y)*denom(x)) > > Well, we know there is no well defined order in EXPR. > > The multiplication is expensive, we can change it to > smaller?(x : %, y : %) == > denom(x) = denom(y) => smaller?(numer(x), numer(y)) > smaller?(denom(x), denom(y)) > > This should also have the side effect that kernels with same > denom will appear near together?
That looks problematic to me. Namely, if we have two different representations x1 and x2 of the same value, than modified variant will give them some order, that is smaller?(x1, x2) or smaller?(x2, x1) will be true. Original version gives false in such case. To put it differently, 'smaller?' is not true order, but is not far from one. The modification above makes difference from order much worse. Let me add that for Expression(Integer) doing 'algreduc' with 'algreduc_flag$Lisp' set to true will produce representation which almost canonical, that is canonical up to choice of kernels. With canonical representaion we would get true linear order using any of definitions above. But, 'algreduc' may be quite expensive. > Anyway, this change will reduce memory usage of mapleok.input > by 20%. > > But there are 2 regression test failures in rsimp.output. > > But they are good failures, the new results are simpler than > the old ones! (I checked, their values are correct.) Yes, result of 'rsimp' is non-unique. Its correctness should not depend on order of kernels, while exact form may depend on order. > 11: EQUL: (rs4, (30*sqrt(11)::eI + 11*sqrt(15))*a7715/11) > +--+ +--+ +--+ > (2 \|15 + \|11 )\|28 > Output1: ---------------------- > 2 > +--+ > +--+ +--+ |77 > (11 \|15 + 30 \|11 ) |-- > \|15 > Output2: -------------------------- > 11 > > 29: EQUL: (rs13, (6*sqrt(11) - 11*sqrt(3))*a12096_1331/6) > 6+-+ +--+ +-+6+-+ > Output1: \|7 \|11 - 2 \|3 \|7 > +-----+ > +--+ +-+ |12096 > (6 \|11 - 11 \|3 ) 6|----- > \| 1331 > Output2: ---------------------------- > 6 > > (for rs4, sqrt(28) can be further simplified to 2*sqrt(7)) > (for rs13, it is negative, but the absolute value is correct.) > > I'm too excited to share this finding. I haven't check further yet. > I hope this change does not have unwanted side effects, so it is safe > to be included. > > - 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/a9d72260-59e8-4e8f-a41d-3dfd31418ae0%40gmail.com. -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/ai9MAchKSem6AliC%40fricas.org.
