Some updates:
The following 'smaller?' change causes some test result
to change differently than before, here is the reason:
1. for mapleok.input changes, for example:
in1378a:=integrate(z*acoth(1-(1-z)^(1/2)), z= 0..1,"noPole")
Used to be:
- 12 log(4) - 3 log(- 1) + 20
(65) -----------------------------
12
Now is:
- 3 log(4) + 5
(65) --------------
3
The reason is that, for definite integration, firstly
indefinite integration is done, then calls limit,
which calls mrv_limit, which calls 'normalize' before
anything else.
The different comes from 'normalize'.
'normalize' tries to find algebraic relations between kernels,
it does so by trying to represent latter kernels in 'tower'
by previous ones.
So the differences of kernel ordering have an impact there.
My patch causes kernels with complex denominator more likely
to be represented by kernels without complex denominator.
2. for rsimp.out changes
The difference comes from ordering in 'factorList',
for example in 'rsimp1_gen_2' called by 'rsimp_gen_2'
called by 'rsimp2_gen' called by 'rsimp'.
The order in 'factorList' is determined by 'smaller?'.
Also it seems that the factorization itself depends
on order.
Maybe in AlgebraicNumber, we can have more meaningful
'smaller?' defined?
So in the above cases, order in Expression matters,
and seems that different orders are both "correct",
just the result might be more complex or simpler.
I still believe the changed version does a better job.
- Qian
On 6/14/26 10:40 PM, 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?
>
> 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.)
>
> 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/492a7439-5177-46ca-9929-939def262799%40gmail.com.
