Almost there! I envision releasing IsItPrime 1.7.0 at least by this weekend!
Implemented:
BFTD up to the square root in verbose mode seems a bit useless, but it isn't. If anything, it will show you a more accurate representation of factors, since it will not display most (or any) quotients of already-found factors. I have already written this, but it's pretty rough and I need to test it.
SPAT-Ex, or Small Prime Array Testing Extended, will use a much larger array of prime numbers, perhaps something like this. Currently, it stops at 541, which is not an arbitrary number - it's the 100th prime.
An interesting, albeit somewhat unnecessary, way to do that would be to go back to the "arraymaker" code used in GJSieve 1.5.1 (console), which simply creates an array of the numbers 2-99999. That was superseded by the "stupid vector" I talked about awhile ago, which in turn was displaced by a simple loop that increases the trial number without any kind of data structure involved. Much more memory-friendly, that!
The arraymaker implementation could simply be a function that creates an array of the numbers 2-3600 and then tests each of them for primality, and if they are prime, it inserts them into an array and iterates the array up by one. That would create an array of the first 500 primes.
There is really no reason other than recreation, as in "recreational mathematics." :)
I also need to make sure the BFTD threading is working. For up to n in verbose mode, it works great.
Also, BFTD up to the square root in non-verbose mode works fine. Each thread simply checks the length of text in the factor display box after completing a test (unless it's the one writing to the box). If there is text in the box, it knows a factor has been found by another thread and it stops.
So it is essentially a race - which thread can find a factor first? Exciting! Especially when, you know, it doesn't immediately stop at 3 or something...
Implemented:
- BFTD up to n in verbose mode (displays ALL factors)
- BFTD up to n in non-verbose mode (stops at ONE factor)
- BFTD up to square root in non-verbose mode (stops at ONE factor)
- SPAT in non-verbose mode (stops at ONE prime factor)
- BFTD up to square root in verbose mode (displays more than one factor, but only up to and (possibly) including the square root)
- SPAT in verbose mode (displays more than one factor, but only the prime factors)
- SPAT-Ex (larger prime array)
BFTD up to the square root in verbose mode seems a bit useless, but it isn't. If anything, it will show you a more accurate representation of factors, since it will not display most (or any) quotients of already-found factors. I have already written this, but it's pretty rough and I need to test it.
SPAT-Ex, or Small Prime Array Testing Extended, will use a much larger array of prime numbers, perhaps something like this. Currently, it stops at 541, which is not an arbitrary number - it's the 100th prime.
An interesting, albeit somewhat unnecessary, way to do that would be to go back to the "arraymaker" code used in GJSieve 1.5.1 (console), which simply creates an array of the numbers 2-99999. That was superseded by the "stupid vector" I talked about awhile ago, which in turn was displaced by a simple loop that increases the trial number without any kind of data structure involved. Much more memory-friendly, that!
The arraymaker implementation could simply be a function that creates an array of the numbers 2-3600 and then tests each of them for primality, and if they are prime, it inserts them into an array and iterates the array up by one. That would create an array of the first 500 primes.
There is really no reason other than recreation, as in "recreational mathematics." :)
I also need to make sure the BFTD threading is working. For up to n in verbose mode, it works great.
Also, BFTD up to the square root in non-verbose mode works fine. Each thread simply checks the length of text in the factor display box after completing a test (unless it's the one writing to the box). If there is text in the box, it knows a factor has been found by another thread and it stops.
So it is essentially a race - which thread can find a factor first? Exciting! Especially when, you know, it doesn't immediately stop at 3 or something...
No comments:
Post a Comment