[PATCH] mpn/generic/jacbase: Another method

[marco.bodrato at tutanota.com]

Ciao,


16 feb 2026, 08:49 da sparks05 at proton.me:

> ----8<----
> Patch 1/4: mpn/generic/jacbase: Another method
>  
> This is basically a refinement of JACOBI_BASE_METHOD = 4, so I'm not sure
> if this should replace 4 or exist as an alternative.  For now, it's an
> alternative created as a way to learn about the tune/ infrastructure.
>
If I understand correctly, the main idea of method 5 is to have just one exit condition for the loop, so that each run has a single branch. Of course this means that method 4 returns earlier in some cases.
This happens, when GCD(a,b)!=1, so that jacobi(a,b)=0, am I right?How much faster is method 5 over method 4 when GCD=1? How the two methods compare when GCD!=1? How the two cases are distributed?


> ----8<----
> Patch 2/4: tune/common: Do double_cmp_ptr in a more standards-compliant way.
>
Maybe a good idea.

> ----8<----
> Patch 3/4: tune/common: Do double_cmp_ptr in a more standards-compliant way.
>
Duplicated?

> ----8<----
> Patch 4/4: tune/speed.h: Don't require that x be odd.
>


> This code raises a few questions:
> 1) Why is y > 1 so essential?  I agree it's not very interesting
>  to benchmark, but it doesn't seem worth the explicit test.
>
Some implementations do not handle the y==1 case correctly, so we avoid triggering unsupported cases.

> 2) What about sorting x and y so x <= y?  Obviously,
>  this changes the distribution significantly.  Rather than y
>  being uniform, this makes large y much more likely.
>
Right, but there is also another possible reason.
SPEED_ROUTINE_MPN_JACBASE uses SPEED_ROUTINE_MPN_GCD_1_CALL, the latter selects the size (in bits) of x and y based on different parameters (size, and r).
Is this useful, is this not for Jacobi?
If we swap the two numbers, we loose that control.

Even if actually we didn't add the FLAG_R_OPTIONAL flag to speed_mpn_jacobi_base...

Ĝis,
mb