Wednesday, December 26, 2012


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.

Tuesday, December 11, 2012

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...

Saturday, December 8, 2012

IsItPrime 2.1.0 beta source + Windows exe

SourceForge had a bit of trouble processing these files, it 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.

Thursday, December 6, 2012

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.

Wednesday, December 5, 2012

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...

Tuesday, December 4, 2012

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.

Sunday, December 2, 2012

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...

Saturday, December 1, 2012

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.

Friday, November 30, 2012

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!

Wednesday, November 28, 2012

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!

Monday, November 26, 2012

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!

Saturday, November 24, 2012

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.

Friday, November 23, 2012

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!

Monday, November 19, 2012

IsItPrime 2.0.8

IsItPrime 2.0.8 is out now. Find the archive here.

  • 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!

Sunday, November 18, 2012

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!)

Saturday, November 17, 2012

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.

Tuesday, November 13, 2012

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...

MuPuPriNT 2.0.0 in progress

It's been over a month since this application got an update. So, since I'm on a roll with Qt stuff, here's what I've done to the aged MuPuPriNT interface and format!

Notice the use of sliders in place of silly check boxes. Also, the buttons are bigger now. It's also a lot easier to tell what kind of test you've selected and what kind of number you're calculating or testing because the labels become bold when selected.

Still working on using all of those boxes.

Sunday, November 11, 2012

GJSieve 2.2.1 in progress

I have almost completed GJSieve 2.2.1. It just needs a few more stability tweaks for reverse testing and we'll be good to go! Also, not all the menu functionality is implemented yet and there are still some options for user configuration I'd like to add, or at least look into adding.

GJSieve 2.2.1 is completely redone graphically and also uses revamped testing algorithms. Memory usage is no longer nearly as big of an issue as it was before. In fact, everything should be quite manageable now!

Here's what the interface looks like at present:

Saturday, November 10, 2012

IsItPrime Source

Taken from this page of the IsItPrime wiki.

If you are looking for really old code, click the "Code" link. That's from 1.6.0 for Windows.
The more modern code is in a SVN repo under "Source." This contains the modern (but deprecated) 1.9.5 for Windows, as well as a /branches repo for the original 2.0.0 and a /qt branch.

As of 10 November 2012, only the /qt branch is up-to-date! This is where the current version's source is contained. This was originally for the /branches repo, but that ended up getting clogged with old libraries and a lot of files that were either unnecessary or deprecated but not removed.

Also, I'm very new to the whole concept of SVN and source management in general, so bear with me. I currently use VisualSVN plugin for Visual Studio 2010 Professional (which in turn utilizes TortoiseSVN) and it's mostly automated in that I just need to click stuff. That works for me but I'm always open to suggestions on new approaches.

So, again - checkout the /qt branch if you must, not anything else (unless for some reason you want old, bad, broken, ugly, or just plain wrong code).

I don't like admitting I'm unfamiliar with things I try to do anyway, but well, it's true.

Tuesday, November 6, 2012

GJSieve Qt version

I was really on a roll yesterday and have re-done GJSieve's interface to use Qt as well.

Thus far, all basic UI functionality is there, including saving, Tweeting, and clearing the screen. Additionally, BFTD and SPAT testing works just fine.

There's also a multi-stage Calculate / Test button. Click it once to calculate the Proth number (provided it's a legitimate Proth formula). It morphs into a Test button, so you can pick a test and go from there!

 Basic interface.
 Calculating a number
Results of a non-verbose BFTD test. This goes up to the square root, but stops after finding just one factor.

Yes, I know it's a bit hard to read the box with the quotient (a long number) and the Quick Stats box with the square root (an equally long number). I will work on that.

Sunday, November 4, 2012

Build IsItPrime!

I have written Makefiles for IsItPrime 2.0.5 that work with a Qt project file to build the application using nmake.

This means it is currently Windows-only - specifically, Windows 7. It builds an x86 version, which is more a symptom of Qt itself.

Find the archive here and run the runBuild batch file in the IsItPrimeQT_200 folder.

Let me know if there are any problems or concerns...

Thursday, November 1, 2012

IIP 2.0.4 testing release

This version is almost done. In fact it's the closest to optimally "done" as I've yet gotten!

Still to do:
  • BFTD-Reverse testing interface and implementation
  • SPAT and BFTD threading re-work
  • figure out why things lock up
Try out this latest testing release! Don't move the DLLs out of the folder there...I'll try and bundle them but I still don't know how.

Why Qt, anyway?

adapted from the IsItPrime Wiki

Why re-write the entire application using the same basic language but a different framework?

Qt is a cross-platform application development framework by Nokia. It is great for graphically-enabled applications that need to be deployed on multiple operating systems in different environments with little to no intrinsic change.

Qt is great for applications such as IsItPrime and other NCPrime projects because it is simple, straightforward, and allows for the look and feel to stay more or less the same on different OSs. Currently, IsItPrime for OS X and Windows not only look different, but actually are different.

With the creation of a Qt codebase, this will change. Soon, IsItPrime will be consistent on many different platforms, including (eventually) Linux.

The Windows version of IsItPrime Qt (2.0.0) has been re-written from the ground up to use absolutely no Windows-specific code - that is, it no longer uses the Win32 API whatsoever.
This is both a good thing and a bit of a hurdle. Qt luckily includes functionality identical or at least similar to what can be done with the Windows API. If it doesn't, there is usually a workaround for emulation.

The OS X version, while it may still be Qt-enabled, will also include several OS X-specific features like Twitter and Facebook integration, as that exists with OS X Mountain Lion (10.8.2) and above. For backwards compatibility, a version will be released with different workarounds for these features (or with them removed).

Linux will be tricky as I haven't ever actually programmed for/on Linux. I do have a LinuxBook Pro now (read: MacBook Pro running Ubuntu), so that should definitely help. The idea is to take the current Visual Studio 2010 solution and convert the whole thing to a qmake project that can then be compiled cross-platform on any system with Qt installed.

Currently, the Qt version of IsItPrime must be distributed with two DLLs included in the application directory (and the DLLs cannot be moved); if I wanted to write an installer, that would remove the need for the DLLs to be packaged in the application directory but would also be a lot of work and an unneccesary extra step.

I really like portable applications - that is, no installation. So I intend to keep all NCPrime applications working out-of-the-box with no installation necessary.

Soon, I will also be re-writing GJSieve to use Qt. Most likely, it will be IsItPrime with a few things changed in the UI and behind the scenes (ie to calculate the Proth number). Then, in the not-too-distant-but-still-distant future, MuPuPriNT will get a nice Qt makeover as well!

For now, I suppose Windows users will just have to settle for the current versions of GJSieve and MuPuPriNT.

By the way, if you currently cannot get to the MuPuPriNT, GJSieve, or IsItPrime, it's SourceForge having some technical difficulties.

Wednesday, October 31, 2012

Quick Stats!

IsItPrime now includes a Quick Stats view to show you detailed results of tests in an easy-to-understand format.

Take a look:

Oops, now I've got to fix those buttons clipping over into the quotient view...

Tuesday, October 30, 2012

Test IIP QT - again!

This time, it will actually run. Turns out that no matter how I actually build the application, the DLLs must currently be present in the application folder. I've actually never had to link a DLL before (and didn't know I had to this time) so for now they're just kinda sitting there.

UnRAR this and go ahead!

Bear in mind that Reverse BFTD verbose testing is not at all present (which is why the option is disabled). And yes, there's a large blank box...not quite sure what to do with that!

Monday, October 29, 2012


I fixed saving and did a bunch of formatting fixes today. I had a day off (and tomorrow too) because of the hurricane.

I'll upload another testing alpha tomorrow provided we still have electricity and internet!

Sunday, October 28, 2012

Test IsItPrime 2.0.0 Qt!

I've gotten a nearly-complete version of IsItPrime 2.0.0 working, more or less. It's been a bit of a struggle, but verbose BFTD testing finally works as it should. Pretty much.

You can find this very alpha version here.

Bear in mind that saving is still a bit flawed and I don't quite know why. This is not pure Qt just yet. In fact, much of it is still using the Win32 API. That will change soon, obviously. The idea here is to make a fully cross-platform application, which is what Qt is meant for.

Tweeting works, SPAT testing works, BFTD works, and BFTDV should work pretty well. Unfortunately, the GUI gets a bit laggy during the test, and there is currently little indication in the UI of what's going on behind the scenes. That may change as well if at all possible.

Updating the GUI from another thread is done by emitting signals, which are connected to slots. The updating happens "when convenient" for the application, meaning when it's thread-safe. Perhaps that's why things might seem a bit slow. It could also just be the debugging code. I don't quite know.

Have fun testing it out!

Thursday, October 25, 2012

Progress (again)

IsItPrime 2.0.0 is underway again. I have managed to get all the QThreads "working" for the verbose BFTD tests. This does not mean the test actually runs, though. In fact, if anything, it is never initialized. It appears as though nothing is...

Oh well. At least there are no more errors and no more "Thread destroyed while still running" and no signal/slot connection problems at all. That can't be anything but a plus.

I will keep you all updated on the progress being made. So far, only normal BFTD (non-verbose) and SPAT testing actually works. Saving is giving me lots of problems, and Tweeting works perfectly. Oh yeah, so does the "Clear" button. And the GUI looks neat!

That's all for now.

Saturday, October 20, 2012

One Thread, Two Thread, Red Thread, QThread

QThreads are not actually difficult to implement at all!

In fact, according to this reference, subclassing is not only unneeded but actually discouraged, and one can simply initialize a new thread object with Qt's signal-slot "queued connections" interface. Sounds great, looks clean and simple, and conducive to code organization too!


Fact: multi-threaded applications become more and more unstable the more individual threads communicate with other threads and objects, especially those created / owned by other threads.

It almost might make more sense to finally learn how to use mutexes...or are they muteces? Mutices? Whatever they are, they could be quite useful. I just need to figure out this QThread stuff, and then head on back over to the fantasy land that is OS X and force myself to understand how Apple decided their computers should handle multi-threading with the mystical NSThread class.

Actually, it's not that QThread itself is giving me problems. It's the fact that the class member functions are "protected" and I can't seem to access them as signals. It's more than a little annoying, but I'm using the Qt Project forums and am expecting answers soon. They've already been surprisingly helpful in a surprisingly short amount of time. They're the ones who initially told me about the documentation for the new QThread class.

Thing is, I'm starting to think that perhaps I somehow don't have the right libraries installed. I have 4.8.3, which is the "latest" version available (and also currently the only version I can find with VS 2010 builds) - the documentation is for "Qt 5.0," which I can't find anywhere.

Back to waiting for answers.

Thursday, October 18, 2012

IsItPrime QT Threading

I am not a fan of difficult-to-implement class-based multi-threading, especially when it means I cannot start threads simultaneously.

I have, however, managed to get the verbose testing threading working in my test version of IsItPrime 2.0.0.

I have to say, I like the interface in general. Very clean and organized, just they way I like it, although admittedly not much has changed. If anything, the actual display boxes are smaller.

Also, that big box on the bottom right does nothing. I forgot it existed while I was was writing the code that lets the threads talk to the UI...and now I have no idea what to actually make it.

Saving works as well!

That's all on that for now. Just so you all know I have actually been doing stuff on this program despite having not made a post in longer than usual.

Thursday, October 11, 2012

IsItPrime 2.0.0 Progress Report

Today has been quite a productive day with the "new" IsItPrime.

The interface itself has changed, obviously, as I am now using the Qt API in hopes of soon (eventually) developing a fully cross-platform app that will run natively in any (or at least most) OS environment(s).

Thus far, it's actually a weird hybrid of the Windows API and Qt, meaning it will still only compile and run on Windows, since it uses Windows libraries and headers. That will change, though.

Today, and within the last few days, I have implemented and tested several features:
  • Tweeting
  • Screenshots
  • SPAT testing
  • The Instructions/Help dialog box
  • The website list/contact info dialog box
SPAT testing was easy enough. I do, however, have to change the entire threading protocol behind the testing since I am no longer passing in a handle to a window, but rather a pointer to an instance of the user interface within a specific instance of a class (phew that's a lot).

That means instead of using the CRT's _beginthread() or the Windows API's CreateThread(), I am using the QThread class. This certainly has its benefits, such as the fact that it's the only method that would work with the current layout of my source files...

Not that that's a problem. Qt has made a very good impression on me as it seems the learning curve is quite manageable. Instead of being variable-based with strong typing, it's class- and pointer-based. It reminds me of Java quite a bit, and that's totally fine.

In fact, if anything, it looks like I'm going to end up writing less code! That's mainly because I don't have to put in several hundred lines just to create the GUI, as that's all done through the automagic QtCreator program, which is integrated with VS2010 (or at least, it is in the way in which I've installed stuff, anyway).

There is the small issue of character encoding...QString is meant to be cross-platform, so it's something like utf-16, which is neither here nor there in terms of wide-character Unicode or multi-byte utf-8. That means it has built-in functions to convert it to, say, a byte array whose data can be reinterpreted as a const char*, which then needs converted to a wide-character string...blah, I'm gonna write a helper function for that!

The screenshot function works perfectly, as I mentioned earlier. It was actually considerably more straightforward than the Windows API's equivalent(s) - that is, I didn't have to use any ATL or MFC classes or even touch GDI+ (thank goodness). Trying to use GDI+ left a bad taste in my mouth last time, since even after following direct instructions on MSDN and other official documentation, it still didn't work/crashed.

But in any case, we're beyond that now. Here is a sample screenshot of a SPAT test in the "new" IsItPrime.

No, that giant LCD number has no code associated with it...yet. Working on it!

Tuesday, October 9, 2012

IsItPrime Interface Changes!

Check it out - I'm learning a new API! The Qt API, to be specific. So far, it looks like it works a bit like Cocoa. This is great because it's cross-platform and highly customizable.

Take a look:

It's just a shell at the moment - nothing is implemented except Tweeting, but that doesn't even work just yet. Almost. It'll be a simple matter of re-writing all the functions to reference the main UI instead of HWNDs and the like.

Essentially, no more Win32. :)

More on this as it develops! (read: I work on it)

Saturday, October 6, 2012

Screenshots for Everyone!

MuPuPriNT 1.2.02b includes a "screenshot" button that takes a picture of the active MuPuPriNT window and saves it automatically. I put that in IsItPrime 1.9.5 yesterday, and into GJSieve 2.0.4 today!

This latest version of GJSieve 2.0 also includes some minor formatting fixes and the window looks only slightly different. It should (and does) work exactly the same.

Find it here.

That's all!

A Proth Number is Always Odd?

The short answer is "Yes, I think so."

The long answer is "Probably, and here's why." A Proth number is any positive integer of the form k * 2^n + 1 where k is any positive, odd integer and n is a positive integer such that 2^n > k.

The example I like to use is 3 * 2^2 + 1. 3 x 4 = 12 + 1 = 13. 13 is therefore the smallest possible Proth number, and is also a prime. The next few are 25, 49, and 97, all of which are odd. 97 is also prime.

The fact is, all powers of 2 are even numbers, and any even number multiplied by any other positive integer is also even. For these purposes, an "even number" is any positive integer which is divisible by 2 with a remainder of exactly 0 - these are concepts of discrete math that any elementary school student knows!

This means that if you add 1 to any even number, the sum is always odd. Thus, a Proth number is always odd.

This begs the question - why does GJSieve need three separate threads to test numbers?

Thread 1 starts at x = 2 and divides the Proth number each time by x += 3 (that is, x increments by 3 each time). Thread 2 starts at x = 3 and thread 3 at x = 4. All of these threads will test even numbers, but they don't necessarily have to at all.

An odd number cannot be divisible by an even number - can it?

This time, the short answer is "No." An even number multiplied by any other number results in another even number. The product is always even. Divisibility is simply finding the other multiplier when you know one number and the product.

It would be difficult to make GJSieve test only odd numbers, though. It would actually take a lot longer. This would involve a thread starting at 3 and incrementing by 2 each time. Alternatively, we could use 2 threads, starting at 3 and 5 and incrementing by four each time. We could use 3 threads, starting at 3, 5, and 9 and incrementing by four each time - or six? - no wait, then we'd test the same number twice. Or more.

What a dilemma!

See, I'm trying to develop a new testing method I can call my own, but currently it's just brute-force trial division in a fancy threaded fashion. Not particularly insightful or efficient in terms of time or computing power!

I'll do more on this later, I'm sure...

Friday, October 5, 2012

IsItPrime 1.9.5 Test Beta

While waiting at an Exxon in Woodstock, VA for the thermostat on the car to be fixed, I had enough time to create a solution for IsItPrime 1.9.5 based on MuPuPriNT 1.2.02 and fully implement everything!

I wouldn't call it perfect, as anything done in under an hour rarely is, but it's certainly a start.

This version is also 64-bit only, as will be all future NCPrime releases. You can find 1.9.5 here.

Saving, Tweeting, screenshots, and all forms of testing do work. If there are any minor glitches, I'd appreciate if you could let me know!

Thanks and have fun!

MuPuPriNT 1.2.02 Released!

I have finished MuPuPriNT 1.2.02. It is definitely still a beta, although everything is fully functional.

The major changes (to the interface, etc) should be fairly obvious. Additional changes include a screenshot button, which takes a screenshot of the MuPu window, then names and saves it automatically.

The readme will have more information about the changes and how to use the "new" MuPuPriNT.

Here's the interface.

As I write this, I am at a Mariott in northern Virginia. This is naturally making it more difficult to work all day, although I did work late into the night last night (hence the screenshot works).

There are actually a lot of unnecessary things in the SVN for MuPuPriNT regarding screenshots. Oh well.

More on this later!

Thursday, October 4, 2012

The next few days

Development of NCPrime applications may temporarily be put on hold as I have family business out-of-state for at least the next four days.

Don't worry, it's nothing bad! In fact, it's anything but, although it will definitely be keeping me busy.

Currently, I need to finish one small thing in MuPuPriNT 1.2.02 and polish it up to 1.2.10 before I can officially deem it a stable beta set for release.

GJSieve 2.1 is also still in the works - it includes this mystery function of MuPuPrint as well as a few performance tweaks.

From now on, ALL NCPrime applications will be 64-bit ONLY. I will work on a stable version of IsItPrime 1.8.0 for x86 before making that x64 only as well.

It is entirely possible I may begin packaging my apps in universal packages containing two executables, but that would likely be for Mac only.

That's all for now.

Tuesday, October 2, 2012





MuPu Progress

I have nearly finished MuPuPriNT 1.2.02!

Sorry for the lack of any kind of progress report. I have actually been working on it since last week, but only recently remembered to write about it.

Currently, all testing is implemented, saving works, Tweeting works, and all the dialogs and stuff are up-to-date. There are just a few things I want to accomplish first...

Friday, September 28, 2012


我有把GJSieve翻譯到中文! 你可以在這兒下來.

它也只有64-bit也有"六縷"的考數字辦法. 不幸, 保存文件有一個比較大的問題, 也不完全好了...

Thursday, September 27, 2012

GJSieve localization + 64bit

GJSieve 2.03 is released and is officially fully 64-bit. I hope you notice a speed increase, because I sure do. Find it here.

Additionally, I'm doing this:

But it's not done yet, so that's all for now.

GJSieve (Windows) Plans

In a perfect world, GJSieve would still use trial division, but in such a way that each operation took place in a separate process that communicated with others. It would then be a true sieve, which are designed to find factors, rather than a strange hybridization that also happens to tell you if the number might (likely) be prime.

Plans for other NCPrime applications are bouncing around everywhere - MuPuPriNT 1.2 for one, now that the reverse implementation is ready to be expanded to other types of numbers - but as far as GJSieve goes, I'd like to do this:
  • localize for Chinese (Traditional) and German
  • create a true 64-bit version
  • maintain a central database of previous tests so that you can see whether or not you've tested a specific number before and/or whether or not it was prime
The latter would be quite difficult to do (initially). The localization should be fairly straightforward in terms of resource files (simply localize satellite assembly files within Visual Studio) but time-intensive for everything else (user-visible runtime strings). The approach would have to be similar to how one localizes a Mac application using runtime macros.

Making a 64-bit version would actually be the easiest thing on this list to do. It would involve removing the intrinsic assembly code that finds and displays your CPU and RAM, but as that's simply an aesthetic feature (and distinguishes program screenshots to a degree), it shouldn't be missed too much!

Additionally, expanding GJSieve's interface and functionality to become MuPuPriNT would be considerably easier in a true 64-bit environment. I won't say too much on that now, as many of my initial ideas are likely wrong or based on incomplete information at the moment.

As an aside, it'd also be kind of cool to implement a function that takes a screenshot of the window...but I think I might have a way to do that already. 64-bit first, though.

MuPuPriNT later!

GJSieve v2.0.2 Released

I have finished a somewhat cursory but nevertheless thorough test of GJSieve 2.0.2 for Windows. It passed. You can find it here.

The application is called gjsieve200 but it is actually 202; this is but a minor oversight.

Please also check out the readme file, which you can read here.

Suffice it to say, this version is still rather imperfect. I will never be satisfied with the way GJSieve works, since there is always something I'd like it to do that I don't know how to code!

At any rate, enjoy. Comments welcome as usual.

Tuesday, September 25, 2012

GJSieve 2.02 - back to basics

I have eliminated the "first factor finder" loop I had tried to implement in GJSieve 2.0. It simply makes more sense to test only up to the square root, even in verbose mode. There is no reason to go all the way up to the first quotient found, as it will return and print the quotients as it finds factors anyway.

Additionally, the dual-loop system was simply causing too many problems with communication and the like.

I am now using only four thread structures - one for info and handles used across threads, and three thread information/variable structures (one for each actual testing thread).

That all said, I am STILL having the issue where I cannot stop a test, clear out the boxes, and then start a new test.

I am, however, on the verge of figuring it out (I hope). It almost definitely has something to do with the way in which thread structures are kept in memory and the way the stop event is signaled (set) and signaled (reset). I just can't quite figure out what.

Currently, the way I have it set up is not really working either. In fact, only one thread appears to actually stop (the second one) - this makes absolutely no sense! I will admit, however, that I am not incredibly familiar with that is probably why.

Just thought I'd check in again, since lately I've either not been posting much or I've been posting about the Mac versions on which I've been focusing. Considering that as of late I've run into a pretty obnoxious localization problem, I may as well go back to the Windows apps I've let sit in their unfinished and problem-ridden state for going on three weeks!

Monday, September 24, 2012

NCPrime and the "new" OS X

With the release of OS X 10.8.2, Facebook is now an integration and sharing option in the Mac operating system, as it has been in iOS for some time now. This means that you need only click a little button in, for example, Preview in order to post a picture to Facebook directly from your desktop.

Twitter integration came with the original release of Mountain Lion, so I jumped on that with IsItPrime and, later, GJSieve. It's somewhat pointless, but fun just the same. It is also a useful thing to know how to do. With the advent and inevitable promulgation of social media, there is almost no situation in which one lacks the option to stay "plugged in."

I suppose that, in a strange way, this includes the niche of recreational mathematics, a field in which no progress is ever or can be made without communication and sharing of results and findings.

Facebook sharing from IsItPrime looks like this:

I don't believe it is possible to change where it says "via OS X" (to something like "via NullCoding" or "via IsItPrime") without either making IsItPrime a Facebook application or somehow integrating the Facebook API...

I also can't exactly figure out a way to include links/tags in the post. Links would be easy, but to what? I guess the project site, right? Seems like a decent enough idea. Twitter posts include a shortened link to the SourceForge site, after all.

I had another idea (actually, as I was writing this) to include a database-type file in the program that keeps track of numbers you have already tested. I'm imagining a drawer on the side of the window with records of previous tests where the tooltip text for each list entry (that is, each number) is something like "X is prime" or "Y has Z factors" or something cool like that.

In my work with Java lately, I have been trying to figure out the best way to dynamically append a JList (a simple list container) from a file where each item in the list is a line from the file. This is not exactly related to IsItPrime, but the concept of appending (rather than re-writing) the same file over and over is essentially the same.

I have also been working on localizing IsItPrime and GJSieve, specifically in German and traditional Chinese. The window and buttons and such are done, but the menu is not and neither are any of the internal (user-visible) strings. I know how to do it, but can't quite get it to work. Something about "genstrings..."

I'll work on it later. I believe this will officially be version 0.5b. I may possibly re-brand it as a version 1 point something if I find it stable and/or complete/feature-rich enough.

Sunday, September 23, 2012

Plans still exist!

Sorry for the relative silence lately. I do still have plans here.

Today, IsItPrime and GJSieve for Mac will likely both get upgrades to allow for Facebook sharing and the ability to stop an in-progress test.

GJSieve for Windows is still under construction for safe thread management. I will probably get back to work on that this week sometime.

Tuesday, September 18, 2012


In keeping with my strange mathematical tendencies, I decided that it would be a good idea to draw a heptagon in Java for a (would-be) simple homework assignment.

Seeing as I've obviously already worked with Java graphics and drawing (see NCSpiral!), this should be no problem, right?

It's actually a real pain since I forgot most of my trig...

But, in any case, here you go!

It ought to look at least something like this:

Friday, September 14, 2012

Multi-threading on Mac

I just took a look at the NSThread class in Objective C and successfully implemented it for testing large numbers in IsItPrime. It supports stopping the test, but not pausing/resuming.

From what I understand, it is unsafe to sleep and resume a thread in Objective-C. The way to do it would be using a thread pool with worker threads and a central delegate which would provide them with functions containing different testing ranges.

That would be a lot of work. A lot of work. But that's not to say I will never get to it. The year is still quite young.

The next step is to implement the same practice in GJSieve for Mac.

After that, I can finally begin work on MuPuPriNT 0.7a for Mac. This will include GJSieve for Proth, Cullen, Woodall, and Pythagorean numbers. This will also forgo the "chooser" window in favor of a series of check boxes and stuff like that.

And it's Friday, meaning I should hopefully be able to work a lot this weekend!

Thursday, September 13, 2012

NCSpiral 0.4.C5

I fixed up NCSpiral a bit. You can now simply find the JAR executable here.

Find some neat images of the program here.

It ought to be fairly easy to figure out how this program works. Simply enter a dimension (even multiples of 10 greater than 100 recommended) and choose two colors - first the background and then the dot color.

It can still take some time to generate the spiral, so be patient. On slower systems, it will take a lot longer.

This program may not work if you are running a version of Java prior to SE 1.6.*.

Tuesday, September 11, 2012

GJSieve for Mac 0.55b released

I have finished a cursory testing process and have deemed GJSieve for Mac to be fully operational - if not even somewhat stable!

You can find it here. Bear in mind that yes, OSX 10.8.0 or later (Mountain Lion) is in fact required. I still do not know for sure if this will run on previous versions of OSX.

In other news, GJSieve 2.0 for Windows is coming no longer fails to test multiple times in a row, but I am hitting a weird problem where subsequent tests after a cancelled test simply stop at the first factor regardless of verbose mode being enabled or not.

Monday, September 10, 2012

GJSieve Woes

I gave up on the threading implementation I tried in GJSieve 2.0 for Windows. It was far too cumbersome and (as it turns out) incredibly unstable. So I am trying a new method using a single giant class. Hopefully it works better.

This involves two separate structures which pass pointers to each other. I sincerely hope that following this advice will help alleviate the serious stability issues I found.

At the same time, GJSieve for Mac is in progress. This will be version 0.5, technically. It will look a lot like IsItPrime 0.2, though not identical. One of the (few) perks of an automagic IDE such as XCode is the ability to use the exact same graphical layout across multiple applications simply by copying and pasting and changing a few important parameters.

It has been a strange day. I spent most of the last hour waiting for webpages to load on the junky old laptop I bring to class with me. I really ought to buy a new one - thinking of an ASUS K53, but any suggestions on inexpensive (as in less than $400) but not-terribly-quality laptops are welcome!

Sunday, September 9, 2012

IsItPrime for Mac 0.2 Released

After much fussing with the file-saving mechanism in IsItPrime for Mac, I have finally completed a relatively satisfying release candidate!

For those of you keeping score at home, I was using deprecated methods to create files and folders - by which I mean they went obsolete around 2008 - and thus was consistently trying to access memory registers that don't really exist. Oops! Well, at any rate, it's fixed now and there ought to be no problems.

Indeed, there are no serious issues with IsItPrime for Mac. It is in fact considerably faster than its Windows complement (and I am still unsure of exactly why) and uses much less memory and CPU time.

It is still CPU-intensive, though - just not for as long. IsItPrime for Mac is also not multi-threaded, meaning that if you enter a particularly large number that just so happens to be prime, the interface may lock up (though hopefully not for long).

You can find a (hopefully) attractively laid-out disk image here. Alternatively, check out the main project site if you haven't already.

Wiki and documentation updates are forthcoming.

Bear in mind that this version of IsItPrime for Mac, along with all other forthcoming NCPrime applications for Mac require at least OSX 10.8.0 (that is, Mountain Lion) on a 64-bit (native or emulative) CPU.

I have not tested this application on any previous version of OSX, as I do not exactly have access to a slew of testing machines. However, I can tell you that since I used the 10.8 SDK as the base architecture for this build, it may not even open on previous versions of OSX and, if it does, may exhibit unusual or undefined behavior.

That sure sounds intimidating! Don't let it stop you from checking out IsItPrime for Mac.

App Store, here we come...?

Friday, September 7, 2012

Aaand I misjudged (IsItPrime Mac PR)

XCode is not nearly as much of a pain in the ass as I thought. Turns out, I'm the pain in the ass, what with my constant questions and apparent inability to learn quickly/on the fly (joke).

At any rate, IsItPrime for Mac now looks and feels like a real, full-featured Cocoa program, complete with Twitter integration and the ability to save detailed text files with results, etc.

Now all I need to do is figure out why the latter throws bad access exceptions all of a sudden, as well as finish working on the verbose mode implementation.

Here have a picture.

Spoke too soon

I originally said I had finalized the threading procedure for GJSieve 2.0.

I have, but lately uncovered a major stability/memory management issue, meaning a major setback in development.

I'm currently working on implementing a solution that will likely result in expanding the threading procedure itself to allow for better communication between threads, but we'll see.

Thursday, September 6, 2012

GJSieve 2.0 and NCPrime progress report

I have finalized the threading procedure for GJSieve 2.0, which will later be implemented in every NCPrime application. First and foremost, I will polish GJS 2.0, and then begin work on what will eventually become MuPuPriNT 1.2b.

This next version of MuPuPriNT will ultimately forgo the "chooser" window in favor of a GJSieve-like interface where you will have the ability to select Proth, Cullen, Woodall, or Pythagorean tests using radio buttons. This will involve the removal of the CPU/RAM display window. It was originally there just for fun, anyway.

As I have mentioned before, this also allows for the creation of a fully 64-bit version of NCPrime applications, since inline assembly code using the _asm intrinsic is only available in 32-bit (for now). Perhaps VS2012 will change that, but I don't really know. I will find out, however.

Additionally, I have been thinking about doing translations of my applications. Partially, this would also be "just for fun" (as with most of what I do with programming to begin with), but would also serve the purpose of giving me a practical outlet for my linguistic studies.

I have also been working on updating IsItPrime for Mac, which will also allow for the eventual re-writing of other NCPrime applications for Mac. I am currently seeking support/help for and with XCode and other programming methods, since my main problems stem not from my applications themselves, but rather the IDEs I use to design them!

Strongly considering switching to Notepad++ and a command line...

Also, I can't figure out SVN or Git to save my life. It's a problem.

Tuesday, September 4, 2012

Mac woes

XCode 4.4 is so unbelievably annoying.

I don't understand anything about how the new IB interface (that's somewhat redundant) works and I can't figure out how to properly add references and outlets.

To make matters worse, I realized that none of the applications I've previously written for Mac will actually run on the current machine I'm using for testing (a brand new iMac running Mountain Lion).

This means that I've essentially accomplished nothing.

On the flip side, I do have a pretty decent setup.

I just can't for the life of me figure out how to actually get this stuff connected properly!

It runs, sure, but it's a useless window with buttons and stuff that do nothing!

Well hey. At the very least, I got the library linked (twice, apparently, if you look closely).

It's been a long shift, that's for sure. Each of my paragraphs is only a sentence or two long...

IsItPrime Mac redux

I decided that IsItPrime for Mac simply needs to catch up with the pack. So, I'm rewriting it.

First things first, though - gotta make a GUI.

There, done.

Now to connect some outlets, allow for "verbose" mode (that'll be fun!) and keep on keepin' on.

Also, I should probably get dinner!

MuPuPriNT Roadmap

About time for this.

MuPuPriNT 1.2 will essentially be GJSieve 2.0 with buttons to select the type of number you wish to test as opposed to having to open an entirely different window.

Additionally, I think I may remove the box using Assembly code to retrieve and display your CPU and RAM. Formatting of this string is different on practically every machine I have tested - sometimes there are no spaces, and other times there are far too many! It was a nice idea. But, that space could be reclaimed and put to better use.

GJSieve 2.0 is still under development. I have some serious issues with thread management at the moment, so I must fix that up before I even consider expanding the already-huge project to include what is essentially (and have previously been) three separate applications.

Monday, September 3, 2012

GJSieve 2.0 Calculations

I decided (about two hours ago) that GJSieve 2.0 was going to calculate the Proth number in a separate thread.

So, I implemented that. In retrospect, I don't really know why. Turns out that the reason GJSieve (for Windows, at least) took so long to "calculate" huge numbers was not due to the calculation at all - it was the printing of the number to the box!

So now, I am faced with a choice - find a way to incrementally print the calculated number to the box that does not involve a single giant string, or else severely limit the size of the numbers the user can test (rendering the application essentially useless).

Currently, if I were to calculate a number 3 million digits in length, it takes 0.003 seconds. However, the time taken to print it to the display box is seemingly (and inconveniently) infinite. I cannot quite tell if the thread is actually hanging or working (as CPU and memory usage remain quite high), but I'm willing to bet that writing a 3 million digit number to what is essentially an array with 3 million slots, followed by performing the necessary conversion to a wide-character array (also 3 million in length) is a generally terrible idea.

In C++, array length is virtually unlimited, yet physically highly limited. The first limit is obviously stack size, which I increased all the way to 25MB (which is admittedly small) before stopping to head off to work. I wasn't getting overflows...yet. The second limit is physically installed memory, of which I must rather hesitantly admit I have only 4GB - yes, even on my custom-built, highly optimized NCS Northwave machine.

The solution which first came to mind is using a vector to cycle through the number's digits and essentially print them one at a time, pushing and popping Assembly-style as necessary. This is not exactly possible, nor would it be much fun to write.

The other idea I had is to use gmp_snprintf() instead of mpz_get_str(). This should fill up, but not exceed, the buffer initialized with the size of the Proth number. sprintf() has no protection against this. Oops!

At any rate, I will have to try all that at some other time... 

Thread Management Woes

I posted about this here...

The basic idea with the experimental six-thread testing method is to speed up the overall testing process. But how?

Well, I started on it last night when I randomly got the idea, and drew out a schematic whilst bored in class earlier today. I call it "Reverse," which is probably a bad name, but does describe what half of the threads do.

Threads 1, 2, and 3 each look for the first factor of the Proth number. Upon finding it, they test like this:
  • first factor + 1 up to sqrt(Proth)/2 with first factor += 3
  • first factor + 2 up to sqrt(Proth)/2 with first factor += 3
  • first factor + 3 up to sqrt(Proth)/2 with first factor += 3
Threads 4, 5, and 6 don't care about the first factor, but they do care about the square root. They care a lot. They set the variable mpTrial to sqrt(Proth) and test like this:
  • mpTrial -1 down to sqrt(Proth)/2 with mpTrial -= 3
  • mpTrial -2 down to sqrt(Proth)/2 with mpTrial -= 3
  • mpTrial -3 down to sqrt(Proth)/2 with mpTrial -= 3 
This effectively cuts the testing range (from 2 to the square root) in half.

However, it does not work properly. Not at all. In fact, it only does some of what it's meant to do. That's why I was posting about thread management (of the SAFE variety) and why GJSieve 2.0 is not available to download!

Naturally, now that I know how to multi-thread my application, I have found excuses to do it just about everywhere. Yet to come is a separate thread for calculating (as opposed to testing) the number, so that the application doesn't seize up when you tell it to calculate a million+ digit number. That ought not be too difficult.

More on GJSieve's crazy threading later. 

Sunday, September 2, 2012

MuPuPriNT's Future

With GJSieve 2.0 being well on its way to "completion," I've taken another look at MuPuPriNT for Windows 1.1 and decided to scrap it.

Currently, it contains GJSieveP, GJSieveC, GJSieveW, and GJSievePy version 1.9.0 and IsItPrime version 1.5.6. Within the next week or so, I should be able to write GJSieveC, W, and Py versions 2.0 based on the triple-threaded testing method seen in GJSieve (Proth) version 2.0.

IsItPrime is currently on version 1.7.0 (which can be found on SourceForge).

MuPuPriNT for Mac, meanwhile, is terribly outdated, although multi-threading appears unnecessary at the moment.

In the near future, I will create a separate project for MuPuPriNT on SourceForge as well as subprojects for the various flavors of GJSieve.

The next release of MuPuPriNT will likely still be 1.1, although I will probably append a sub-release number.

The versioning of my applications may seem random and/or like the steps are too large. For instance, IsItPrime went from 1.5.6 to 1.6.0 to 1.7.0 in a matter of two weeks or so. But this makes sense. Major coding changes, coupled with overhauls of the graphical interface and overall changes to the way it actually tests numbers necessitated an increase in sub-version numbers.

Generally speaking, I name things 0.* if they are considered an alpha or testing release, meaning I am not entirely sure they do what I want or everything I want them to do in exactly the way I wish for them to do it.

Versions 1.* are considered stable betas at this point. That means they do everything they're meant to in a stable and efficient manner, although there are definitely still changes and things yet to be implemented.

GJSieve (Proth), where it all began, is on version 2.0 after months of development. It has a rich history of evolution, and I'm proud of the progress I've made even after becoming essentially the sole developer.

More on this later. For now, expect MuPuPriNT to become the focus of NCPrime projects for at least the foreseeable future. After all, what's the point of intensively developing and updating various standalones whilst their implementations in MuPuPriNT lag a version or two behind?

Here's an idea that literally just came to me.

Instead of a main "Chooser" window from which you select an application to run using boring buttons, imagine a window that simply looks like GJSieve 2.0, only with the addition of radio buttons or something to that effect labelled "Proth," "Cullen," "Woodall," "Pythagorean," and "Any number." Obviously "Any number" would be IsItPrime.

The trick is the entry box for k, as that is only used in the Proth number tester.

I suppose I could just have it become disabled upon selecting a test that is not Proth, but that could look a bit ugly. If it was easier (using the Win32 API) to simply hide and show things like edit controls and buttons, I would do it.

I will definitely look into that. MuPuPriNT for Mac will likely be where I'll prototype this unified implementation, so also be on the lookout for that!