Lull, pt. II

Unfortunately, I must make yet another update explaining why development of NCPrime applications appears to have ceased.

This is mostly due to the fact that active development has indeed come to a standstill. I regret to inform you that I have in fact done nothing at all to GJS 2.5.0 since around the time of my last post here (26 December 2012). I have also not made a single post yet this year, and indeed was on track to post nothing at all for the entire month of January!

My real-world life has gotten quite difficult lately, as I am no longer in school and consequently unemployed. Whilst this is temporary, I have six months ahead of me in which I appear to have nothing to do whatsoever. Seeking employment is proving more troublesome than I had ever expected, since despite my thorough knowledge of computers from a technical, diagnostic, and software (programming) standpoint, I currently lack the certifications necessary to work at most major (and minor) computer repair centers.

For example, Best Buy and Micro Center (to both of which I have applied) require at least A+ certification in order to work in their service and/or repair divisions, even (in some cases) providing only basic customer service. Best Buy does not mandate it for junior Geek Squad agents, but it is preferred.

Now, I could easily get such certifications, based on my research and conversations with people who happen to have them themselves. I will do so as soon as I feel adequately prepared, and that will certainly help me!

It's a foot in the door, at least.

Additionally, I have not been feeling very well lately, dealing with a great deal of personal issues, most of which are admittedly directly related to my current state of unemployment in a semester-long medical leave of absence from college.

All of this has contributed to my recent lack of programming - indeed, I have not even opened VS2012 in quite some time and just before writing this post was wracking my brain in attempts to remember exactly where I'd left off with GJS 2.5.0 and what my plans were to rectify the few minor issues that had cropped up after the first successful, yet altogether basic implementation of the "Quick Run" sieve testing style.

I sincerely hope to regain the motivation to continue development of GJS and, of course, other NCPrime applications in the very near future.

I will admit, however, that I have for quite some time been at a loss as to how I can further improve programs such as MuPuPriNT and IsItPrime. For example, MuPuPriNT's last update was on 5 December 2012, very nearly two months ago; IsItPrime had updates not much more recently. The last major updates to those applications was in fact nothing to do with overall functionality but more with making them entirely cross-platform capable (which was a success). The functionality of those two particular applications has remained pretty much the same since the middle of November (or earlier, in the case of certain features).

This is not necessarily a problem, but the best applications are the ones constantly being updated for the sake of providing upgrades to functionality, efficiency, and interface as well as fixes for minor bugs and addressing the occasional stability concern.

Perhaps it's just that I currently lack any ideas as to how I can enact some sort of immediate change in either of those particular applications and provide a substantial update of any sort. I'm really not all that concerned about MuPu and IIP, though. I would sooner resume active and focused development of GJSieve 2.5.0 than waste time tinkering with ideas I've more or less forced myself to think up for applications that already work as intended!

This obviously means that no, GJS 2.5.0 does not work as intended. In fact, it doesn't work at all. It will take me a little time to get back into the swing of things, but once I do (re-familiarize myself with writing code and using Visual Studio and so on and so forth) I am confident that I will be able to provide a highly functional and well-programmed version of GJSieve in the not-so-distant future.

Bear in mind, of course, that this version of GJSieve is not really going to look, feel, or work much like the GJS you're used to (provided you have used the latest version of GJSieve, which is currently listed as 2.2.3b). It's going to be much, much closer to functioning like a true prime number sieve, and it'll look a bit different as well (which is for the best). It will also implement a very similar command hierarchy and global variable delegation system to those already present in MuPuPriNT and, to a lesser extent, IsItPrime.

GJSieve has not officially been updated at all since 24 November 2012! From the first of November right up to now, exactly two months past the last update, there have only been 55 downloads of GJSieve (mostly in Spain, interestingly enough). In that same time period of 1 November 2012 to 24 January 2013, there have been only 67 downloads from MuPuPriNT in total, over half of which were the build-it-yourself source archive.

I feel rather bad about not only letting my project(s) stagnate, but also for not keeping everyone informed as well as I should have. Rest assured, though, NCPrime is still alive and well - or at least, making great progress towards a full recovery!

- Jaska Börner 24 January 2013

Lull

I thought I should probably post here again, since I haven't in over two weeks.

I have not been programming very much or at all in these last few weeks for several reasons, none of which have anything to do with a lack of ideas or motivation. Mostly, I have been incredibly busy (tis/twas the season) and have been working on several other projects at the same time.

• I have been trying to find uses for old and/or broken computer parts, so I have been tearing them apart down to individual electronic components and bits of circuit board in hopes that I might be able to make them into jewellery or decorations of some sort. 
• I have been cleaning and organizing my own room as well as other parts of my family's house, which is a Sisyphean task.
• I have been driving a lot and running errands, so I am out of the house too often to sit and program for hours on end. 

Generally speaking, I'm afraid to start on anything because I may not be able to finish - and I can't stand leaving things unfinished!

That said, GJSieve 2.5.0 is very much still unfinished. Currently, the "quick run" option is crudely implemented and doesn't really work very well, if at all. The ideas I have to make it better and smoother are:

• Make global variables for determining and reporting the testing range
• Make a wrapper class that is owned by the main window class and is responsible for creating and managing the worker classes, which in turn manage the testing thread(s)
• Have the wrapper class contain variables that are updated via signals from the worker and update statistics on the test
• Have the wrapper class receive signals from the threads in order to update the GUI in real-time
• When a test begins, fill the newly-created (or already-existing) worker class instance with a new candidate number at the chosen k and the current number in the range
• When a test ends, rather than exiting the thread, a signal will be sent to the wrapper class instance to find the next candidate number at the chosen k using the next number in the range
• When the last number in the range is reached, the wrapper class will be responsible for sending signals that exit the threads and printing statistics on the entire sieve run
• Have the wrapper class responsible for clean-up
• Delete the wrapper class instance when safe to do so

This is just for quick runs at the moment. I will eventually have to implement this for all testing types.

I am still debating whether to keep verbose and reverse BFTD testing in this iteration of GJSieve. If it is to be a true "sieve," there is no real reason to factor a candidate number in its entirety! What may end up being the actual available testing options are quick runs, triple-threaded BFTD, and six-threaded BFTD.

The latter two will of course work the same way as verbose and reverse already do, but it would be tricky to write because the threads will need to send signals to the worker almost constantly, which would trigger a slot that signals all threads if a factor has been found. That's just so when one thread finds a factor, they all stop. I know it can be done, but it will be difficult - especially for the reverse testing!

This will all come to fruition in 2013, I can promise you that much.

Slight blog redo

I edited and updated the blog format itself a bit today, in keeping with the heavy modifications I made to my personal blog, which was long overdue for a refresh!

Soon enough we'll need a logo. I already have one, but it's too big / not the right shape exactly to go up top with the description:

There is a story behind this ubiquitous NullCoding design - it's just for another time. And perhaps another blog...

IsItPrime 2.1.0 beta source + Windows exe

SourceForge had a bit of trouble processing these files, it seems...so they weren't available for download until today despite uploading them two days ago. The default download still points to 2.0.8. Nope. Try this 2.1.0 executable instead!

If you want the source, check the readme file (bottom of page) first, and then download this archive.

I have still not tested this on Mac or Linux, but it's exactly the same build process and procedure as MuPuPriNT and definitely takes less time.

I will release executables for Mac and Linux when I have the chance. I will test it on Mac in the very near future. I need to move all my computers across the state, so I currently don't have a Linux machine available (but will tomorrow).

Sorry those links took so long.

Source Code and More Updates!

MuPuPriNT is on a roll - almost 50 downloads this week, mostly of source code! This is great. I had no idea people were that interested. Also, it's cool that they're downloading source. This leads me to believe that the majority of people who are into recreational mathematics and prime number testing run some form of Linux and therefore need to be able to build from source.

I have also written IsItPrime 2.1.0, which like MuPuPriNT is meant to be built from source. It looks a bit different from previous versions:

IsItPrime 2.1.0 GUI, adapted from MuPuPriNT's

This version also uses many more global variables and definitions, several of which are determined at runtime and one of which is determined at build time (currently on Windows only), asking if you wish to build a debugging display widget as well.

This widget will have more use in the future, as it is a full-featured debug display. Currently, though, it does very little except show the current working directory and, on Mac, mysterious error messages.

In the future, I will include a build option to ask what "style" you wish to build - currently, the default is Windows7Style for Windows, MacStyle for Mac, and CleanLooks for Linux (I believe - not sure on the latter). Theoretically, you should be able to use whichever you want. This can easily be determined with a simple build-time-generated file with a single definition in it. I will work on that!

Additionally, I am still working on a completely overhauled GJSieve that is actually a true sieve as discussed in this post. It's still in the planning process, but I hope to begin development very soon.

I currently have a lot going on in the real world outside of my programming ventures, so my time needs managed quite well. So far, so good - but we'll see what the future brings. But for NCPrime in general, it looks pretty bright!

Links to download IsItPrime executables and source will be up as soon as SourceForge has processed the files. It seems they're a bit slow on that at the moment.

MuPuPriNT for Mac 2.1.2a

Turns out that building on Mac is not nearly as much of a pain as I thought - but building for Qt5, now that's a pain.

You can find a pre-built app bundle (zipped up) here. I guess I could have put it in a disk image, but oh well, I didn't.

Next I will try for Qt5, but that's actually going to involve changing a fair bit of code. I can't have two versions of Qt installed at the same time, since the executables placed in /usr/bin/ need to be called plain "qmake" and "uic," not "qmake-4.8" and so on and so forth...we'll see!

This Mac version is fairly stable, but is still plagued by that bizarre "null pixmap" problem that never shows up anywhere else...

Future of GJSieve?

There is a question mark in the title for two reasons.

For one, I have wondered for some time if the naming convention is particularly relevant anymore. Originally, GJSieve was named for its two developers, in order of their actual contributions to the application as of about 5 March 2012, which is the earliest date at which I can find actual source code for the absolute first (and therefore most elementary) version of GJSieve. The G stands for Gabriel and the J for Jaska (me!)

I came up with the idea, of course, but Gabriel actually wrote the original rough draft of the program. Thus, he was listed as a developer on the Google Code page we used to use as a main project site. Since we no longer use Google Code, he is not included as a developer at all. He has also not actually done anything relating to GJSieve or other NCPrime applications (beyond moral support and encouragement) since that initial design phase.

There is also the question of whether GJSieve (and therefore MuPuPriNT) is actually a "sieve" at all. Wikipedia says that, from a computational number theory perspective, a prime sieve works by:

...creating a list of all integers up to a desired limit and progressively removing composite numbers (which it directly generates) until only primes are left. This is the most efficient way to obtain a large range of primes; however, to find individual primes, direct primality tests are more efficient.

What GJSieve actually does is test one number at a time at a specific k and n (for Proth numbers, in this case). Thus, it is more accurately styled a "direct primality test" in this context.

If I were to rename GJSieve, it'd be called NCProth or something to that effect, since "NCPrime" is the name of this software development label as a whole.

Another idea is to stop development of GJSieve as a standalone entirely, since it does nothing that MuPuPriNT cannot!

However, I think a more viable course of action is to develop an entirely new application, which could still be called GJSieve, that asks for a specific value of n and then a range of k, and then generates a large array of Proth integers for each k at that n and subsequently tests all of them using any of several fast testing methods to see which (if any) out of that array are possible primes. Then it'd be a true sieve!

This is not merely an idea - it's actually going to happen. I just haven't started yet, that's all.

I will, as mentioned, continue calling it GJSieve as a tribute to Gabriel, who did after all get me interested in programming on my own and was responsible for the initial design of GJSieve up to version 0.3a way back in March of 2012.

That's all on GJSieve for now.

MuPuPriNT Source + Cross-Platform Stuff (finally!)

As the title may have hinted, MuPuPriNT is now well on its way to being supported cross-platform!

After a very intense late-night coding session, I have just about completed a buildable version for Linux. Since I only have a 64-bit Ubuntu 12.10 machine for testing, I can't vouch for the application's compatibility with other Linux environments, especially if they aren't using the Unity desktop. However, it should still at least build.

Thing is, you need Qt installed fully to build anything, which is why I'll also simply release the application itself.

Same goes for Mac. I spent about four hours today getting the Mac version to compile. I now have a universal cross-platform Qt project file that ought to work on Windows (32 and 64-bit), Mac OS X 10.7+, and Linux 3.2.*+!

Not all that much has changed except some rather complicated preprocessor directives for OS-specific functions (for instance, getting the current username and folder paths is different for Windows from the methods for Unix and/or OS X).

Essentially, that means the MuPuPriNT source code is now full of stuff like #ifdef __unix and #ifdef __APPLE__, but it all works properly. Getting it to distinguish between WIN32 and _WIN64 is tricky considering _WIN64 is included in the WIN32 definition (why though?), but I got it eventually.

So, some links for you!

MuPuPriNT 2.1.3 Extended (stable beta) for Windows

MuPuPriNT source archive including 2.1.3 for Windows x86 and x86_64 and 2.1.2a for OS X and Linux

An app bundle for Mac is coming soon. I think it might be 64-bit only. Then again, it might be 32-bit only. I have no idea. It's not like Windows where the library architecture depends on the compiler you use. It's just "make." Ah well. It didn't say the executable was 32-bit.

Also, an application for Linux (specifically Unity) is coming soon as well. I know it works.

MuPuPriNT on Linux (just a test - it looks better now!)

MuPuPriNT on Mac in the office

There is one small issue with the Mac version - it's not stable. You will notice in the debug log (which is not entirely necessary I admit) that it occasionally says "warning: QPixmap::scaled is a null pixmap" and I have NO idea what that means or why it only happens on Mac. I haven't been able to find that in the source code anywhere so I assume it has to do with the Mac libraries specifically...

To build on Windows, use a Visual Studio tools command prompt, x86 or x64. That will determine what you end up building, NOT the project file itself! The project file just has a check to see if it's win32 or win64, but it won't make a difference if you use a compiler that's different from what you think the project file is going to build.

More instructions can be found in the individual readme files in the source archive itself and also here.

Yay future! :) This is a big step forward for me and NCPrime in general, since I've been talking about porting my apps for months (ever since I first made a rough alpha of GJSieve for Mac in Obj-C). Now, with Qt, not only is it possible, it's exactly the same functionality in any OS!

Once I get some things in the real world squared away, I'll work more on the stability of the Mac version and then possibly look into porting to other versions of Linux as well as some BSD-based stuff, perhaps...

MuPuPriNT 2.1.2 Extended beta

It didn't take long (but it was a fair bit of work)! MuPuPriNT 2.1.2 Extended is now available for testing. You can find it here.

From the README included:

This version of MuPuPriNT uses a unified testing structure for all eleven types of numbers it can calculate. This has resulted in substantial code clean-up and reduced memory usage, and also gave an opportunity to implement some much-needed stability fixes.

Additionally, functions such as Tweeting, saving results files, and saving numbers themselves have all been updated and work properly for every different type of number.

The application now uses global variables almost exclusively to determine information about test status and number properties, meaning the amount of locally-defined "stuff" has gone down dramatically, which is also good news for memory usage.

Finally, all dialogs and other interfaces have been updated, since previously they displayed either incorrect information or an incorrect version number (or both).

I have also implemented a slight change for reverse testing that is still experimental - in cases where the square root used as an upper limit is too big to fit an unsigned long integer, GMP/MPIR variables are used. This is, unfortunately, rather memory-intensive and therefore pretty slow.

Perhaps I will be able to find a way to speed things up in the future, but for now, huge numbers (with a square root over 4 billion, or over 10 digits in general) are a bit out of the scope of MuPuPriNT. If it has any factors at all, single-threaded BFTD or even SPAT are both likely to find them anyway.

MuPuPriNT 2.1.1 Extended beta

You can now try out MuPuPriNT 2.1.1 Extended! Find it here.

This adds testing functionality for seven new types of numbers, so there is now a total of eleven numbers you can calculate and test.

I also fixed the screenshot capabilities and modified the way the Test button works. You won't notice anything on the GUI end, but behind the scenes there has been a great deal of code clean-up and modifications to make things run a lot smoother.

Additionally, this version introduces and prototypes a completely working unified testing interface. This means that instead of about twenty different files for testing each type of number, there are now about that many that can be used to test any number at all!

Future versions will be trimmed, source-code-wise, so that there are many fewer files in the project in general. This should also speed compilation time, which has been bothering me lately, and will also facilitate finally making a fully cross-platform version that can be built from source with qmake.

I'm almost there, actually - I just need to figure out how to get it to not link against Windows-specific libraries, for example, and then I should be able to start testing on my Mac and eventually a Linux machine as well!

A New Era for NCPrime Development!

Okay, so the title is a bit dramatic. But it's accurate.

Today, I installed Windows 8 on the laptop I use for programming (and taking notes in class). It's an ASUS X54C-BBK5 15.4" basic notebook...with a Corsair Force 3 SATA III SSD, easily one of the fastest available at its modest price point. POST to login in 4 seconds running 64-bit Windows 8 Pro. Very nice indeed.

I took this opportunity primarily to finally try out Visual Studio 2012, and I must say, I was instantly hooked. Just look at the interface.

It's color-coded like XCode! and Eclipse. And NetBeans. And, well, most IDEs out there.

I mean wow. Great. It's easier to use than I thought. I initially was hesitant because I thought I'd have to learn a whole new set of features, but it turns out the few immediately noticeable functionality changes are actually intuitive and also improvements.

Futuristic, no?

I did, however, have to re-build Qt from source in its entirety, which took about two hours even with /MP. There are a few necessary tweaks to be made in order to build Qt 4.8.3 for VS2012 even though the mkspec remains win32-msvc2010. Since I built it with the VS2012 64-bit command prompt, I ended up with 64-bit Qt libraries and DLLs, which is fantastic, because now MuPuPriNT Extended (and soon every other NCPrime app) will be fully 64-bit!

I have yet to test the app on Windows 7 now it's rebuilt. I do have several Windows 7 machines available for testing. None have Qt installed, which is good to test the deployment itself, and one is (for some reason) 32-bit, so I'll have a go at that. Later I'll get around to testing everything on XP as well, although in the past there have been no issues even on a low-end laptop from 2005.

Currently, however, I am working on bug-squashing as for some reason the unified testing procedures for verbose and reverse BFTD do not work at all. In fact, they crash the application regardless of the number type selected or other options...

Here's what it all looks like at the moment!

MuPuPriNT Overhaul and Milestone Acknowledgements

This is the 100th post on this blog! It seems like I've made a lot more than that, but perhaps that's just me.

In any case, I have taken the last few days to make some major changes to MuPuPriNT - specifically, what it can do. Currently, MuPuPriNT 2.0.2 beta is the latest version available; it is only capable of testing four different kinds of numbers.

So, I am working on MuPuPriNT 2.1.0 Extended, which can test eleven different kinds! This includes Wagstaff, Carol, Kynea, Leyland, Thabit, and Cuban types 1 and 2 in addition to the current Proth, Cullen, Woodall, and Pythagorean options. The interface has been adjusted accordingly:

Note that there is now a drop-down box for number type selection instead of a slider. Additionally, there is now a button called "Numbers" which will display a table containing information about each type of number available for testing, including their requirements (for instance, n greater than 1, q must be prime, etc).

Also, I have made some major changes to the MuPuPriNT SourceForge page! Check it out.

I am going to be adding more to the wiki in the future, but if you are interested in how MuPuPriNT extended will work, check out the About page for 2.1.0.

Finally, I am looking into creating a unified testing procedure for MuPuPriNT. This would mean that instead of over twenty different header and source files for each type of number, there would be around twenty in total for the entire application! This would dramatically reduce compilation time, which lately has soared to about three minutes even using the /MP option. Also, it just makes more sense, and would remove a great deal of repeat code from the source repository and the application itself.

I know this is totally possible, so I will start by writing and testing this unified testing procedure with the new additions to MuPuPriNT's number "vocabulary" in order to determine its viability for full implementation. This will probably happen within the next week or so.

Since this is a milestone post on this blog, I'd just like to thank all of you who follow my progress, provide feedback and recommendations on SourceForge, and actually test or use my applications. I recognize that prime number testing is a bit of a "niche market," but I'm glad there are others out there whose interest in recreational mathematics has led them to the NCPrime family!

GJSieve 2.0.3 beta

I'm on a roll. Now GJSieve uses significantly less memory (>30MB) for tests and also has the option to save the number to its own file! Find 2.0.3 beta here.

Yes, I am still technically considering this a beta. It is in testing. It is not perfect. It is also not too terribly flawed once you get past the fact the GUI is prone to lock up sometimes. But not all the time. Only sometimes. It's strange.

In any case, test away.

Massive Integer I/O

One of the biggest challenges faced when dealing with massive multiple-precision integers is memory usage. The last thing we want is stack overflows stemming from attempts to read or write a number too big for the space allocated.

Luckily, GMP (MPIR for Windows) seems to render most of those concerns moot, as it dynamically allocates, re-allocates, and eventually frees memory as variables are initialized, operated upon, and subsequently cleared. Of course, it ultimately still comes down to the programmer to remember to properly initialize all variables before their first use, and clear them from memory when done with them.

A more in-depth approach involves manually clearing and re-initializing integer variables as is done in all NCPrime applications. At the end of a single round of testing (dividing n by x), the variables that store(d) the remainder and quotient are cleared and immediately re-initialized. Since GMP/MPIR uses a standard zero-initialization technique, there is no loss of data and no residuals, meaning you will never end up with a partial integer being rounded up or down to give a variable a value it shouldn't actually have.

When the testing thread exits, several things happen. This will be covered in a later post, but behind the scenes, stuff is constantly getting deleted from and (sometimes) re-entered into memory. On completion of the thread, the instance of the "worker" class is scheduled for deletion when safe to do so. This happens as soon as the thread has completely exited. The worker class contains instances of structures for testing data, which are deleted when the worker instance is. Deletion of the structure leads to clearing of the actual variables used in testing.

It is a bit complicated, but efficient nonetheless. However, using multiple-precision integers internally is easy compared to inputting and outputting them. Input is done via strings. That is easy enough, especially considering the data in question already exists as a string (usually somewhere in the GUI).

Output is difficult because it involves creating a massive array of multi-byte characters...this usually, if not always eats up available memory. I have caught applications like GJSieve using well over 2GiB of RAM on some machines. It doesn't even get close to that on my usual testing/programming machine with a total of 4GiB RAM.

Printing the number takes A LOT less memory as it does not ever actually display the number. In fact, if the number is already displayed, it does practically no work at all. If not, it simply calculates the number based on the current number type selected and prints it to a string.

This is why I recommend in applications like MuPuPriNT and GJSieve leaving the "Show Number" box unchecked unless it is a small number (or a Pythagorean number, as those are often much smaller).

I just thought I'd write about that for a while. In the future, expect more posts on the inner workings of NCPrime applications. It really is quite fascinating.

MuPuPriNT 2.0.2 beta

I have finished MuPuPriNT 2.0.2. This is still considered a beta release, but it is quite stable and has all the functionality I wish it to at this time. Find it here.

Note that it is a good idea to leave "Show Number" un-checked, especially for very large numbers...if it is longer than a few hundred thousand digits, displaying the number will require creating a massive array in memory, which takes a ridiculous amount of memory to display, register, and render - not worth it! Save yourself some time.

Additionally, there is now an option to print the full number to a (separate) results file. This will be stored in a folder inside Documents/MuPuPriNT Results called Calculated Numbers (with sub-folders for each type of number).

It's all highly efficient and quite organized. It should work just fine. If not, let me know.

Also, Tweeting has been fixed and the string and/or URL created will always encode properly now. That one was tricky, but is functional and rather useful, too!

IsItPrime 2.0.8

IsItPrime 2.0.8 is out now. Find the archive here.

Changes:

• major stability fixes and memory usage reductions for single-threaded BFTD and SPAT. 
• new form of Tweeting results - choose what you want to say or include! - formatting fixes as usual - more detailed testing info
• much more stable in long tests 

Known issues:

• GUI still locks up
• Pause/Resume functionality doesn't exist
• Hard/Impossible to stop a test in progress...working on it! 

Note: currently the application must be kept with the two included DLLs. This will change in the future, but for now the application is built to call DLLs and not linked with static libraries included in the build. I'm still working on that!

I am currently having no luck with the static libraries, or with Qt 5.0 beta in general. I'm sure I can try more in the future once some things get patched up and/or I get more familiar with the whole qmake thing and makefiles in general. That should make stuff a bit easier, especially for cross-platform builds!

Latest NCPrime Applications

Changes made in GJSieve 2.2.1, IsItPrime 2.0.7, and MuPuPriNT 2.0.0 as of late are all about the same, so here goes:

• use a slider to select a test type instead of ugly checkboxes
• use a slider to select a number type in MuPuPriNT 
• Saved results files are more detailed with regards to what was actually done
• Quick Stats is also more detailed 
• Time measurements are now correct (both CPU time and wall clock time)
• BFTD (non-verbose) was renamed to BFTD (single), meaning single-threaded
• SPAT and BFTD (single) have been changed and updated to use a more modern and safe thread management system, so memory usage by these tests should be dramatically lower (not in IsItPrime...yet!)
• BFTD (single) is also much more stable now

Known issues:

• The Pause, Resume, and STOP buttons (still) do nothing. I am unsure if they ever will. I am looking into reasons for the GUI locking up despite running things in a separate thread, though I think it might be due to the GUI object itself being the thread's / threads' parent.
• In that vein, the application may say it is "not responding" whilst doing a very long test. This is, unfortunately, normal. I have not yet run a test long enough to verify if the application is working or actually hanging, as CPU usage remains normal (for a primality test, that is)

Future changes:

• MuPuPriNT Tweeting will say what kind of number was tested 
• All Tweeting will say (provided the test in question has finished) if the number was prime, or how many factors it had (you will have options!)
• Saved results files will be even more detailed!
• You will also have the option to include the full calculated number in the results file (or, more likely, in a separate file altogether) - this will probably take a while and might not work properly or at all for very very large numbers.

GJSieve 2.2.1 beta

I also finished the testing version of GJSieve 2.2.1 for Windows using Qt. Find the archive here.

In the next post, I will describe changes to this, IsItPrime, and MuPuPriNT (all of which have been refreshed and updated within the last few days!)

MuPuPriNT 2.0.0 beta

Here is the testing release of MuPuPriNT 2.0.0. It is still a beta, but everything should be totally functional. You can find the archive here. Bear in mind this is still not a full redistributable, so the application cannot be moved out of the directory where it's located because it needs to be in the same place as the two DLLs.

This version will only work for Windows at the moment. I will release the source once I have created a version buildable with qmake, but that is still in testing. I am still not entirely sure how to make cross-platform builds, but I'm working on it.

GJSieve will be out shortly.

I broke Qt

Not quite sure how I managed to do this, but I did. I waited about an hour to build Qt statically and this is what I get :(

So much for an open redistributable...

Well, it's back to the drawing board on this one for sure. I should have it fixed by later tonight...I hope...