Wednesday, December 26, 2012

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.

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

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.