Or at least, that's what it would look like as a console application. -v and -nv switches (or more likely, just -v) for verbose and non-verbose modes.
Implementing the non-verbose BFTD testing method for trial<n was easy. Copy the existing BFTD implementation that tests only up to the square root and change the parts where it uses the square root.
There are a lot of buttons and switches and check boxes and stuff now, but the general idea is that BFTD has many, many more options available.
So, here is a hypothetical to explain why these options are needed. Assume that your time is important and you'd rather not wait more than you absolutely have to!
You have a number that is kind of large and you'd like to test it. You open IsItPrime and select SPAT. It finds nothing. You select BFTD up to the square root, and it seems to find nothing either. You are still unsure, so you select BFTD up to n in verbose mode, since you really would like to see what is being tested.
Perhaps it finds a factor. Maybe not. Either way, using every testing option available to you is pretty important, especially when considering that no mathematician would take you seriously if you just tested up to the square root by trial division using this silly IsItPrime app you found on SourceForge one day between browsing artistic and eco-friendly desktop environments for your latest obscure Linux distro.
IsItPrime is, like any other "primality tester," much better at finding composites. Numbers you might think are prime sometimes turn out to have a couple factors up in the range of 6-9 digits - who would have thought? And that million-digit number you just calculated? Yeah, it has the factor 3.
IsItPrime really shines in verbose mode, since if you really want to factor a number, you sure can. It still sometimes finds the trial number = candidate number = factor, but that can and will be fixed.
The next big hurdle is rewriting GJSieve, GJSieveW, GJSieveC, and GJSievePy to all use this triple-threaded testing method. Already, their implementations in MuPuPriNT 1.1 all use separate threads for tests, but only one at a time. Considering the numbers being tested usually exceed 100,000 digits...that doesn't really make sense!
Oh and I haven't forgotten about Mac. I'm working on it. Probably today, actually!
Implementing the non-verbose BFTD testing method for trial<n was easy. Copy the existing BFTD implementation that tests only up to the square root and change the parts where it uses the square root.
There are a lot of buttons and switches and check boxes and stuff now, but the general idea is that BFTD has many, many more options available.
So, here is a hypothetical to explain why these options are needed. Assume that your time is important and you'd rather not wait more than you absolutely have to!
You have a number that is kind of large and you'd like to test it. You open IsItPrime and select SPAT. It finds nothing. You select BFTD up to the square root, and it seems to find nothing either. You are still unsure, so you select BFTD up to n in verbose mode, since you really would like to see what is being tested.
Perhaps it finds a factor. Maybe not. Either way, using every testing option available to you is pretty important, especially when considering that no mathematician would take you seriously if you just tested up to the square root by trial division using this silly IsItPrime app you found on SourceForge one day between browsing artistic and eco-friendly desktop environments for your latest obscure Linux distro.
IsItPrime is, like any other "primality tester," much better at finding composites. Numbers you might think are prime sometimes turn out to have a couple factors up in the range of 6-9 digits - who would have thought? And that million-digit number you just calculated? Yeah, it has the factor 3.
IsItPrime really shines in verbose mode, since if you really want to factor a number, you sure can. It still sometimes finds the trial number = candidate number = factor, but that can and will be fixed.
The next big hurdle is rewriting GJSieve, GJSieveW, GJSieveC, and GJSievePy to all use this triple-threaded testing method. Already, their implementations in MuPuPriNT 1.1 all use separate threads for tests, but only one at a time. Considering the numbers being tested usually exceed 100,000 digits...that doesn't really make sense!
Oh and I haven't forgotten about Mac. I'm working on it. Probably today, actually!
No comments:
Post a Comment