On Sun, Mar 16, 2025 at 05:05:02PM +0100, 'Ralf Hemmecke' via FriCAS - computer
algebra system wrote:
> On 3/16/25 16:42, Waldek Hebisch wrote:
> > > %%% (3) -> position(k2)
> > >
> > > (3) 2048
>
> > Positions have gaps, that is deliberate to limit renumbering.
>
> OK. But then I must have missed the place where these gaps are introduced.
See 'enterInCache' in 'kl.spad (second signature) and constant DIFF.
> In fact, I do not quite get the ordering of the kernels.
> I saw the triage function that is used for comparison of kernels.
>
> triage(k1, k2) ==
> height(k1) ~= height(k2) => B2Z(height(k1) < height(k2))
> operator(k1) ~= operator(k2) => B2Z(operator(k1) < operator(k2))
> (n1 := #(argument k1)) ~= (n2 := #(argument k2)) => B2Z(n1 < n2)
> -- Handled by linear search earlier
> -- ((func := property(operator k1, SPECIALEQUAL)) case None) and
> -- (((func::None) pretend ((%, %) -> Boolean)) (k1, k2)) => 0
> for x1 in argument(k1) for x2 in argument(k2) repeat
> x1 ~= x2 => return B2Z(smaller?(x1, x2))
> 0
>
> That seems to suggest that if the same kernels are introduced in two
> different sessions they would inserted into the cache array in the same
> order. Maybe not in the same position, but comparing the kernels with <
> should be the same in both sessions. (OK, except when "smaller?" behaves
> differently.)
Roughly yes. There are two irregularites. Some kernels have special
equality and 'smaller?' is not an order. So if you insert kernel
in a different order also order on kernels may be different.
And extra kernels may affect result (in real ordered set order
on a subset is independent on extra elements in the set, but
we have only "almost order").
--
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/Z9cGVh11XiMBfqmn%40fricas.org.
