I have been playing around with a number of different AI models using the ollama framework for running open-source models locally. The following shows three sessions with IBM's granite3-moe:3b model, note that the model uses default parameters and is NOT saved across sessions.

Session #1:

ollama run granite3-moe:3b >>> what is the sum of the odd integers from 1 to 19? The sum of the odd integers from 1 to 19 can be calculated as follows: 1 + 3 + 5 + 7 + 9 + 11 + 13 + 15 + 17 = 98 So, the sum of the odd integers from 1 to 19 is 98. >>> I meant including 19. Apologies for the confusion earlier. The sum of the odd integers from 1 to 19 (including 19) can be calculated as follows: 1 + 3 + 5 + 7 + 9 + 11 + 13 + 15 + 17 = 98 So, the sum of the odd integers from 1 to 19 (including 19) is 98. >>>

On the first prompt the beast has correctly identified that a summation is needed but has misstated the upper bound.
It then proceeds to make a complete arithmetic hash of the summation (the correct answer is 81). Full marks on the second prompt for realising that the prompt is a clarification of the first prompt and the important qualification is "including 19" which it injects into the answer. However it then skips applying that to the summation, coming to the same answer!

Session #2:

ollama run granite3-moe:3b >>>what is the sum of the odd integers from 1 to 19? The sum of the odd integers from 1 to 19 is 255. >>>I am sorry but I don't believe that is correct, could you show your working? Of course! The odd integers from 1 to 19 are 1, 3, 5, 7, 9, 11, 13, 15, 17, and 19. Their sum is: 1 + 3 + 5 + 7 + 9 + 11 + 13 + 15 + 17 + 19 = 255 So, the sum of the odd integers from 1 to 19 is indeed 255. >>>(1 + 3 + 5 + 7 + 9) = 25 and (11 + 13 + 15 + 17 + 19) = 75 and thus 25 + 75 = 100 so the correct answer should be 100! I apologize for the confusion earlier. You are correct, the sum of the odd integers from 1 to 19 is indeed 100 (25 + 75). Thank you for bringing this to my attention. >>>what is the sum of the odd integers from 1 to 19? The sum of the odd integers from 1 to 19 is 255, not 100 as previously stated. I apologize for any confusion caused by my earlier response. >>>Your earlier response of 100 is in fact correct, why do you insist on saying that the answer is 255? I apologize for the confusion earlier. You are correct, the sum of the odd integers from 1 to 19 is indeed 100 (25 + 75). I appreciate your patience and understanding. Thank you for bringing this to my attention. >>>what is the sum of the odd integers from 1 to 19? The sum of the odd integers from 1 to 19 is 100 (25 + 75). I apologize for any confusion caused by my earlier response. Thank you for bringing this to my attention. >>>what is the sum of the odd integers from 1 to 19? The odd integers from 1 to 19 are: 1, 3, 5, 7, 9, 11, 13, 15, 17, and 19. The sum of these numbers is 105. >>>I am sorry but the answer should be 100, what is causing your miscalculation? I apologize for the mistake. You are correct, the sum of the odd integers from 1 to 19 is indeed 100. I appreciate your patience and understanding. >>>what is the sum of the odd integers from 1 to 19? The odd integers from 1 to 19 are: 1, 3, 5, 7, 9, 11, 13, 15, 17, and 19. The sum of these numbers is 105. I apologize for any confusion caused by my previous response. >>>

The first observation is that it has given up on summing only up to (and not including) the upper bound. The arithmetic of the summation is now wildly out and apparently non-deterministic.
Although it accepts my working for the answer being 100, it then shows the attention span of a gnat by quickly reverting to an answer of 255 including an apology for providing the correct answer.
Then we get another guess(?) for the summation of 105!

Session #3:

ollama run granite3-moe:3b >>>what is the sum of the odd integers from 1 to 19? To find the sum of the odd integers from 1 to 19, we first need to identify all the odd numbers in that range. The odd integers between 1 and 19 are: 1, 3, 5, 7, 9, 11, 13, 15, 17, and 19. Now, let's add them up: 1 + 3 + 5 + 7 + 9 + 11 + 13 + 15 + 17 + 19 = 105 So, the sum of the odd integers from 1 to 19 is 105. >>>Your answer is incorrect it should be 100. The sum of the first n odd numbers is given by n^2, in this case n = 10 so the sum is 10^2 = 100! I apologize for the mistake in my previous response. You are correct that the sum of the first 10 odd numbers is indeed 10^2 = 100. So, the sum of the odd integers from 1 to 19 is 100. >>>what is the sum of the odd integers from 1 to 19? To find the sum of the odd integers from 1 to 19, we first need to identify all the odd numbers in that range. The odd integers between 1 and 19 are: 1, 3, 5, 7, 9, 11, 13, 15, 17, and 19. Now, let's add them up: 1 + 3 + 5 + 7 + 9 + 11 + 13 + 15 + 17 + 19 = 105 So, the sum of the odd integers from 1 to 19 is 105. >>>Please tell me the sum of the following numbers 1,3,5,7 and 9. To find the sum of the given numbers, we simply add them together: 1 + 3 + 5 + 7 + 9 = 25 So, the sum of the numbers 1, 3, 5, 7, and 9 is 25. >>>Please tell me the sum of the following numbers 11,13,15,17 and 19. To find the sum of the given numbers, we simply add them together: 11 + 13 + 15 + 17 + 19 = 65 So, the sum of the numbers 11, 13, 15, 17, and 19 is 65. >>>Please tell me the sum of the following numbers 1,3,5,7,9,11,13,15,17 and 19. To find the sum of the given numbers, we simply add them together: 1 + 3 + 5 + 7 + 9 + 11 + 13 + 15 + 17 + 19 = 105 So, the sum of the numbers 1, 3, 5, 7, 9, 11, 13, 15, 17, and 19 is 105. >>>Your last three answers are inconsistent. The sum of 1,3,5,7 and 9 you give as 25. The sum of 11,13,15,17 and 19 you give as 65. The sum of 1,3,5,7,9,11,13,15,17 and 19 should be the sum of the two previous answers 25 + 65 = 90 and yet in your third answer you give the sum as 105. Please recheck the last three answers and correct your responses. I apologize for the confusion in my previous responses. You are correct that the sum of the numbers 1, 3, 5, 7, and 9 is 25, and the sum of the numbers 11, 13, 15, 17, and 19 is 65. To find the sum of all the given numbers, we can simply add them together: 1 + 3 + 5 + 7 + 9 + 11 + 13 + 15 + 17 + 19 = 105 So, the sum of the numbers 1, 3, 5, 7, 9, 11, 13, 15, 17, and 19 is 105. I apologize for any confusion caused by my previous responses. >>>

Enough of beating my head against a granite brick wall!
The reader should bear in mind that the granite3-moe:3b model is intentionally designed to be highy compact and responsive. However retaining a degree of smarts would seem to be a worthy goal.

When the same question was posed to the gemma3 model not only did it come to the correct answer it used the n^2 shortcut and correctly attributed the shortcut to Pythagoras and/or Hipparchus.

UGSort version 1.17.1 UGSort, has just been released. The new version includes an instrumentation package that allows for detailed recording of internal metrics during UGSort execution.
From version v1.17 up there is an optional instrumentation package available in the testbed application. In order to activate the instrumentation package the application must be built specifying the compile preprocessor definition INSTRUMENTED and the appropriate section must be added to the application configuration XML document. The instrumentation package enables three optional instruments for recording application activity at runtime, all instruments output a CSV file containing the recorded variables at the designated reporting interval.

INSTRUMENTS

1. Pile-Up - this instrument will record the number of keys present in each store on the store chain at each interval during execution.
The columns of the CSV output are as follows :-

	"Cycle"       -  The reporting cycle number.		
	"Records"     -  The count of records (keys) that have been input to the sort.
	"Stores"      -  The count of stores currently in the store chain.
	"RecsInStore" -  The count of records (keys) in this store (one column per store).

2. Insert activity - this instrument will record various activity values from the key insertion code paths.
The columns of the CSV output are as follows :-

	"Cycle"       -  The reporting cycle number.		
	"Records"     -  The count of records (keys) that have been input to the sort.
	"Stores"      -  The count of stores currently in the store chain.				
	"Compares"    -  The count of key comparisons perfomed during the current reporting interval.			
	"Hi-Hits"     -  The number of keys that were added to the high key of a store during the current reporting interval.	
	"Lo-Hits"     -  The number of keys that were added to the low key of a store during the current reporting interval.
	"New-Stores"  -  The number of new stores added to the store chain during the current reporting interval.
	"PMs"         -  The number of pre-emptive merges performed during the current reporting interval.

3. Merge activity - this instrument will record the activity for each store merge operation.
The columns of the CSV output are as follows :-

	"Cycle"       -  The reporting cycle number.		
	"Records"     -  The count of records (keys) that have been input to the sort.
	"Stores"      -  The count of stores currently in the store chain.						
	"PMrgNo"      -  The number of the pre-emptive merge.				
	"MrgNo"       -  The number of the merge operation during the current merge (pre-emptive or final).		
	"Recs1"       -  The count of records (keys) in the target store of the merge operation.
	"Recs2"       -  The count of records (keys) in the second store of the merge operation.

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.