On 2025-07-27 01:51, Torbjörn Granlund wrote:
Thank you for merging the new mpn-based factoring code!
The code looks good, I did not see anything which needs improvements.
I believe the factoring speedup for numbers of 3 or more limb is quite
significant (2x-3x), even when not considering the t
Thank you for merging the new mpn-based factoring code!
The code looks good, I did not see anything which needs improvements.
I believe the factoring speedup for numbers of 3 or more limb is quite
significant (2x-3x), even when not considering the time saved by not
proving primality of found fact
On 5/20/25 09:04, Torbjörn Granlund wrote:
The current factor.c code is becoming insanely complex. Contructs
masking bugs triggered on hypothetical systems doesn't help with
managing complexity.
If such hardware seems to be quite some time away, what about
guarding the code for the ranges we k
Paul Eggert writes:
> if (n < (wide_uint) FIRST_OMITTED_PRIME * FIRST_OMITTED_PRIME)
>return true;
>was incorrect.
> Why is it incorrect?
Because when you run it on a machine with 128-bit unsigned long (or
whatever type is being used for the word size), N can be 155
On 5/19/25 15:23, Torbjörn Granlund wrote:
Paul Eggert writes:
before my Saturday coreutils commit[1], this code in prime_p:
/* We have already cast out small primes. */
if (n < (wide_uint) FIRST_OMITTED_PRIME * FIRST_OMITTED_PRIME)
return true;
was incorrect.
Why is
Paul Eggert writes:
Fine, but the 128-bit bug is independent of uintmax_t. Suppose we
change factor.c to never use uintmax_t, and suppose we have a
(theoretical but allowed) platform where unsigned long is 128 bits and
where factor.c uses that type for its words. Then before my Saturday
On 2025-05-18 02:07, Torbjörn Granlund wrote:
I don't think is makes much sense to handle two 128-bit words in this
code. In fact, the use of uintmax_t was a mistake, it should use
"unsigned long" or "unsigned long long" whichever is efficiently
supported directly by the hardware.
Fine, but t
Just a quick note.
I don't think is makes much sense to handle two 128-bit words in this
code. In fact, the use of uintmax_t was a mistake, it should use
"unsigned long" or "unsigned long long" whichever is efficiently
supported directly by the hardware.
While uintmax_t could be made to work als
I recently found out that GNU coreutils 'factor' misbehaves if its
internal word is 128 bits rather than the usual 64. This could happen if
one builds Coreutils 9.7 on a platform with 128-bit uintmax_t, something
that POSIX allows (though it's only theoretical now as far as I know).
The proble
