Stupid Vectors

GJSieve for Windows uses a vector to determine a trial division number. It's set up like this:

	std::vector<unsigned long int> ta(99999);
	for (u=0; u<99999; u++, dos++) //we start at two because 1 is obviously always a factor
	{
	ta[u] = dos;
	}
	for (u=0; u<99999; u++)
	{
	trial = ta[u]; // see, no confusion now
	mpz_fdiv_r_ui (remainder, proth, trial);
	etc...

view raw gjsvector.cpp hosted with ❤ by GitHub

Whereas with the Mac version, it looks like this:

	mpz_t remainder, quotient, squareroot;
	mpz_init (remainder);
	mpz_init (quotient);
	mpz_init (squareroot);
	unsigned long int trial = 2;
	mpz_sqrt(squareroot, proth);
	[ProgressBar incrementBy:delta];
	for(trial=2; mpz_cmp_ui(proth,trial) > 0; trial++)
	{
	mpz_fdiv_r_ui (remainder, proth, trial);
	[ProgressBar incrementBy:delta];
	if (mpz_cmpabs (remainder, ZERO) == 0 && mpz_cmp_ui(squareroot,trial) > 0)
	etc...

view raw vectorless.m hosted with ❤ by GitHub

And guess what? It does the same thing.

Now, this may be the reason GJSieve for Windows is a bit more limited in what it can do. Vectors are luckily thread-safe and not a memory leak, but a vector of the maximum size possible? That can't be too kind to the program.

I'm going to re-write GJSieve for Windows to use this vector-less approach, which simply makes more sense in both an implementation and practical sense.

I have to say though, Objective-C is really wonderful in memory management and whatnot. Even if there was a leak, it would probably tell me how to patch it up.

So, expect a new version of GJSieve for Windows in the near-ish future. If it works well (or, preferably, better), the vector-less approach will be implemented in MuPuPriNT as well.

Speaking of the multi-tester, expect a Mac version of that sometime soon-ish as well!