Torbjörn Granlund wrote on 2023-06-17 16:12:
These logs are only the ones which repeatedly downloads large parts of
the repository. There are many other indefinitely repeated requests,
but these below are the ones which really cause significant CPU load and
network traffic.
20.57.73.47 - -
Torbjörn Granlund wrote on 2020-06-02 11:22:
Surely the field _lc could be be renamed to something less confusing
without dire compatibility consequences. :-)
Since it was still used like that for the backwards-compatible generator, and
access was done through the macros anyway, this was
Pedro Gimeno wrote on 2020-06-02 02:12:
Here's the patch as I submitted it for review (I believe), which has some patch
comments that I added to facilitate the review:
http://www.formauri.es/personal/pgimeno/temp/gmp_snap_mt.diff
Sorry, updated link:
http://www.formauri.es/personal
Torbjörn Granlund wrote on 2020-06-01 12:10:
Question 1: Why is _mp_lc wrapped in a union?
Historical reasons. It was that way when I implemented MT.
Question 2: "_lc" = Linear Congruential? This is supposed to be a
generic structure, right?
Historical reasons again :)
Unfortunately, my
Seth Troisi wrote on 2019-09-03 08:59:
3. add mpz_nextprime_seq(a, b) => next prime a + k*b with k >= 1
Personally I would prefer it named mpz_nextprime_step or mpz_nextprime_stride
or mpz_nextprime_strided. Or even mpz_nexprime_with_step, if that doesn't
violate some naming convention I'm
Torbjörn Granlund wrote on 15/04/2019 21.57:
Or return the low bit k bits (not all 128)?
That works too, at the cost of reducing the throughput. If that's faster than
including a 128-bit addition in the process, sure.
___
gmp-devel mailing list
Niels Möller wrote on 15/04/2019 20.01:
Pedro Gimeno writes:
It should not be a problem for AES256. It's kinda unusual to need
something around 2^136 random bits, to say the least. For AES128, it
should be mostly fine, but it might introduce a slight bias in some
applications. For any 64-bit
Torbjörn Granlund wrote on 15/04/2019 13.55:
Since long, I have intended to implement AES-based PRNGs in GMP. The
idea being that if AES is a good encryption algorithm, the sequence
AES_encrypt(cnt,key) for cnt=0,1,... will be simply great. :-)
It will be OK, for a relatively low number of
Torbjörn Granlund wrote, On 2018-12-05 13:55:
> Let's follow these principles:
>
> 1. We don't need to support every past and present system. E.g., we
>do not support any 16-bit or 8-bit processors, nor do we support the
>once popular 36-bit systems.
>
> 2. We should avoid undefined
Torbjörn Granlund wrote, On 2018-12-04 13:45:
> Pedro Gimeno writes:
>
> An assertion of LONG_MIN < -LONG_MAX should make the code safe in that case.
>
> Does The Standard even guarantee thet there are about as many negative
> and positive number?
>
> I am re
Torbjörn Granlund wrote, On 2018-12-04 07:39:
> Marco Bodrato writes:
>
> But, what about the LONG_MIN == -LONG_MAX case?
> The result is undefined, isn't it?
>
> Does anybody (apart from Vincent) have access to such a machine?
> :-)
An assertion of LONG_MIN < -LONG_MAX should make the
Torbjörn Granlund wrote, On 2018-11-22 09:17:
> Getting anywhere near 2^64 will still be too hard for our resources.
> Assuming we can do 10^7 primes per second on the fastest GMP computer,
> it's still a task which would take some 1500 years.
Did you mean pseudoprimes?
All primes are guaranteed
equal to a pointer to any object or
function.
4. Conversion of a null pointer to another pointer type yields a null pointer
of that type. Any two null pointers shall compare equal.
Doesn't that allow using (void *)0 for the suggested purpose?
--
Pedro Gimeno
Torbjorn Granlund wrote:
I started a page: http://gmplib.org/devel/incompatibility.html
We might want to classify incompatibilities as source, binary, and both.
I have not listed obsolete functions. The cost of retaining obsolete
function compatibility is very low; the temptation to
Torbjorn Granlund wrote:
Pedro Gimeno p.gim...@formauri.es writes:
My recollection is that gmp_errno was not thread-safe, not just
obsolete, and that that was a reason for getting rid of it.
Making some C error handling mechanism would be great, though. I am not
sure that's easy
15 matches
Mail list logo
