Just done some extended testing with UGSort, the latest tests used 1 to 10 million keys in 1 million key increments. So far only the Windows tests on random keys have been completed, the performace curve remains linear at about 1.4 million keys per second. Interestingly when benchmarking the native Windows sort utility against UGSort I noticed that the native Windows sort has become distinctly sluggish in the latest Windows build. In the above plot the old UGSort and Native Sort plots for 1 to 5 million keys were measured at the time and then projected for the 6 - 10 million keys data points. The old Windows environment used OS Build: 22621.1992 and the new uses OS Build: 26200.7019.
The timing for the UGSort tests have remained constant across the OS build environments U-Old and U-New (slope: 781 ms per million keys). While the native sort utility has dropped from Old (slope: 2,262 ms per million keys) to New (slope: 3,856 ms per million keys), quite a significant degredation.
The testing protocols followed were the same as used in the original UGSort performance paper.
More results and analysis to follow...

No not literally! I have started cleaning out a number of old hard drives so that they can be truly retired, if they haven't retired themselves already. In the process I have stumbled on some code and document archives that actually contains some still useful and relevant stuff.
I have created a new GitHub Repository which will hold a cleaned up version of anything that I find that I think others might find useful.
The first tranche of stuff are C++ functions for case-insensitive versions of some standard functions. stristr() is a cases-insensitive version of strstr(), there are plenty of versions available on the internet, some better than others.
I remember coming across one implementation that made me chuckle, it coerced the input search string (needle) to lower case and used strstr() to search for that, if the lower case string was not found then it coerced the string to upper case and searched for that. A very wierd implementation with very limited application, perhaps searching for Donald Trump's tweets?
I have included this one because it is complete, elegant and efficient also it is strict in following the contract for strstr(). There is also strichr() the case-insensitive version of strchr() and memichr the case insensitive version of memchr().

I hope that someone finds this stuff useful, there will be more to follow.

Take a (relatively small) simple GIF image load it into a program and proceed to perform a number of round trips of saving in JPEG encoded format and reloading it from the saved JPEG. Perform 30 round trips and see how much the image has degraded.
The program to do this has been posted to GitHub.
Below is a plot of the number of colours in the reloaded image at each iteration of encoding.
Interesting plot!
Following are the initial image and the JPEGs produced at cycles: 1, 10, 20 and 30.

	Base GIF image
	JPEG image after 1 cycle
	JPEG image after 10 cycles
	JPEG image after 20 cycles
	JPEG image after 30 cycles

The JPEG encoding parameters were set to be a medium (most common) image quality.

There was a television gameshow in the US in the 1970's called "Lets's Make A Deal", the host of the show was Monty Hall.
The show was fairly simple. A contestant is faced with three closed doors there is a car behind a random one of the doors and a goat behind the other two. The contestant, who is unaware of what lies behind each of the doors, is asked to select one of the doors and to inform Monty of his selection. Monty will then open one of the unselected doors that has a goat behind it. The contestant is then asked if he will stick with the original door he selected or switch to the other unopened door. Having changed (or not) his selected door, the remaining doors are flung open to see if the contestant has won the car (I believe that if his door had a goat behind it then he did not win the goat!).
The "problem" arose, not because of the gameshow itself but from a letter from Steve Selvin to the American Statistician in 1975 and then further discussed in Marilyn Vos Savant's "Ask Marilyn" column in Parade Magazine in 1990. The column discussed if the contestant would have a winning advantage if he stuck with his original door or switched to the other unopened door. Savant argued that the contestant should switch as that had a 2/3 probability of winning the car rather than a 1/3 probability of winning if he stuck with his original selection. Here lies the problem, an overwhelming 87% of people were in favour of sticking with the original selection leaving only 13% trusting in Savant's analysis.
See Wikipedia for a detailed discussion.
The MHProb program illustrates the problem and provides a series of scenarios that demonstrate the corectness of supporting the "switch" strategy.
The MHProb program is available on GitHub.
For more about the MHProb program see the article The Monty Hall Problem

The UGSort (an Unexpectedly Good Sorting algorithm) has been updated on GitHub. The repository contains a sample implementation of the updated algorithm (v1.15.0). the papers describing the algorithm specification and an empirical study of the performance envelope of the algorithm have been updated. The update changes the algorithm for selecting the correct partition for a new key from a linear search to a binary search. The change has shown a significant reduction in sorting time. The plot above shows the comparative performance of UGSort against the native sort. The plot above shows the performance comparison between v1.14 (linear search) and v1.15 (binary search).

The UGSort (an Unexpectedly Good Sorting algorithm) has been published on GitHub. The repository contains a sample implementation of the algorithm. It also contains papers describing the algorithm specification and an empirical study of the performance envelope of the algorithm. The plot above shows the comparative performance of UGSort against the native sort.