A list of mp_int's plus management

[czurnieden]

This is the last pluck from #190 the rest is all based on a functioning sieve.

[minad]

@czurnieden I wonder if these functions should be part of tommath since they feel a bit too high level to me. These function go in the direction of providing vector operations and I think that's out of scope.

[czurnieden]

I wonder if these functions should be part of tommath since they feel a bit too high level to me

These functions were formerly internal functions for the communication between the individual parts of the factorizing: prime generating, simple sieving, and Pollard-Rho. (A quadratic sieve is planned but I think that would be too much, a bit out of scope as you phrased it.) All of those were in a single file once which was, rightfully I think, frowned upon, so I took them apart. Once apart they needed a method to communicate, of course, and the functions listed here were born. I tried to keep them as simple and as small and unobtrusive as possible.
Not "high level" at all, just an internal communication tool that also happens to be useful on its own. I gave the primorial as an example but a simple method to handle a bunch of mp_int's comes handy in more than one situation. So I decided against making them private.

[minad]

Ok, if you use them elsewhere I am fine with the functions. But I still tend to make them private.

[czurnieden]

Ok, if you use them elsewhere I am fine with the functions.

I'm not a fan of featurities, no worry ;-)

It might have made the impression because some of the functions building on it are still in limbo waiting for this (and two other PRs) to merge.

[minad]

I'm not a fan of featurities, no worry ;-) It might have made the impression because some of the functions building on it are still in limbo waiting for this (and two other PRs) to merge.

I am ok with the functions. But I would like to cleanup the public API a bit, this is what I am doing with this deprecation stuff. Since these functions are used internally for now, I would like them to be private.
It is easier to make functions public than making them private. Is there a strong argument that the functions are general and useful enough for the public api?

[sjaeckel]

Since these functions are used internally for now, I would like them to be private.
It is easier to make functions public than making them private. Is there a strong argument that the functions are general and useful enough for the public api?

I'm also pro private if there's no good reason (yet) to have them public.

[czurnieden]

They are not needed by any of my current PRs, so I'll close this pull-request and put it back up (or a new one) when I need these functions.

If I make them private I would have to remove the tests too. That is a) work ;-) and b) I do not like to have untested stuff here if it can be avoided and c) if it goes private it is more or less dead code, so closing it for the time is the easiest way.

[minad]

If I make them private I would have to remove the tests too. That is a) work ;-) and b) I do not like to have untested stuff here if it can be avoided and c) if it goes private it is more or less dead code, so closing it for the time is the easiest way.

As things are now you can also test the s_* functions. While testing the public api is more important, it is also ok to have separate unit tests for nontrivial private functions.

[czurnieden]

As things are now you can also test the s_* functions.

Ah, didn't see it. (should follow your communications here more closely)

But it would still be quasi dead code and it's better to keep the tree clean.
And nothing is lost here, just switched off, easily to reinstate if necessary.

[minad]

But it would still be quasi dead code and it's better to keep the tree clean. And nothing is lost here, just switched off, easily to reinstate if necessary.

Sure, not in this case. I just wanted to give you the info that testing private functions is possible now :)