Edit: After getting five downvotes but no comments saying anything about why, I’ve tried to reformulate the question. I can only assume the votes are because people see a lot of text and maybe think there isn’t even a question in here.
I’ve written code that (mis)behaves rather strangely. It seems the code doesn’t run the same way on other’s computers, so please don’t get mad at me if you can’t reproduce the problem.
I had a look, just for fun, at the frequencies with which different bytes occur in GUIDs. I had noticed that the string representations of guids always contained “4”. Rather than read about it on Wikipedia I tried to think about what it might be, as it can be fun to do a little “original research” and do your own thinking once in a while. (And then read the wiki afterwards!)
The strange issue on my machine happens when I try to use the “burst” feature. Provided it is reproducible in your environment, you can re-create it by running the app and hitting B. This is supposed to result in a burst of 100 steps (i.e. make 100 new guids, updating the displayed frequencies only at the end of the burst, because writing to the console is so ridiculously slow). But it actually results in just a single step!
I set a breakpoint in ProcessKey() where the burst variable is assigned. When I step out of the method, I notice in Debug Output that a thread exits. This is not a coincidence; it happens reliably every time. Then my watches show me the burst variable that was just assigned to 1000 in the previous step… has value 0.
Why does this happen? Did I do something wrong? I notice there is no attribute anywhere specifying STA, but I’ve never really had a clue what these things are anyway and I haven’t removed anything from the console application template I used (with VS-2011 developer preview, though unlike Redmond I live in 2012 now)…
Finally: The app moves the cursor back and overwrites the text again and again. This doesn’t work well if you can’t make the console window high enough to show all the output at once, so you may want to fiddle with the console font (or change the width of the console, the app should change accordingly though I haven’t tested). The pattern becomes completely regular (on my machine at least!) with a 4-column output (if your console is 80 chars wide you’ll get 4 columns).
Code to reproduce (or not, as the case may be):
using System;
using System.Diagnostics;
using System.Threading;
namespace ConsoleApplication1
{
class Program
{
static bool running, exit;
static int burst;
static long guidCount = 0;
static long[] counts = new long[256];
static DateTime nextReport = DateTime.MinValue;
static readonly TimeSpan reportInterval = TimeSpan.FromSeconds(0.25);
static void Main(string[] args)
{
Console.WindowHeight = (int)(0.8*Console.LargestWindowHeight);
WriteLine(ConsoleColor.White, "X - Exit | P - Pause | S - Step (hold for Slow) | B - Burst\r\n");
WriteLine("Auto-reporting interval = {0}.", reportInterval);
Guid guid;
byte[] bytes;
var cursorPos = new CursorLocation();
while (!exit)
{
if (Console.KeyAvailable)
{
ProcessKey(Console.ReadKey(true));
}
if (running || burst > 0)
{
guid = Guid.NewGuid();
bytes = guid.ToByteArray();
++guidCount;
for (int i = 0; i < 16; i++)
{
var b = bytes[i];
++counts[b];
}
if (burst > 0) --burst;
if (burst == 0 || DateTime.Now > nextReport)
{
burst = -1;
cursorPos.MoveCursor();
ReportFrequencies();
}
}
else
Thread.Sleep(20);
}
}
static void ProcessKey(ConsoleKeyInfo keyInfo)
{
switch (keyInfo.Key)
{
case ConsoleKey.P:
running = !running;
break;
case ConsoleKey.B:
burst = 100;
break;
case ConsoleKey.S:
burst = 1;
break;
case ConsoleKey.X:
exit = true;
break;
}
}
static void ReportFrequencies()
{
Write("\r\n{0} GUIDs generated. Frequencies:\r\n\r\n", guidCount);
const int itemWidth = 9;
int colCount = Console.WindowWidth / (itemWidth*2);
for (int i = 0; i < 256; i++)
{
var f = (double)counts[i] / (16 * guidCount);
Write(RightAdjust(itemWidth, "{0:x}", i));
Write(GetFrequencyColor(f), " {0:p}".PadRight(itemWidth), f);
if ((i + 1) % colCount == 0) Write("\r\n");
}
nextReport = DateTime.Now + reportInterval;
}
static ConsoleColor GetFrequencyColor(double f)
{
if (f < 0.003) return ConsoleColor.DarkRed;
if (f < 0.004) return ConsoleColor.Green;
if (f < 0.005) return ConsoleColor.Yellow;
return ConsoleColor.White;
}
static string RightAdjust(int w, string s, params object[] args)
{
if (args.Length > 0)
s = string.Format(s, args);
return s.PadLeft(w);
}
#region From my library, so I need not include that here...
class CursorLocation
{
public int X, Y;
public CursorLocation()
{
X = Console.CursorLeft;
Y = Console.CursorTop;
}
public void MoveCursor()
{
Console.CursorLeft = X;
Console.CursorTop = Y;
}
}
static public void Write(string s, params object[] args)
{
if (args.Length > 0) s = string.Format(s, args);
Console.Write(s);
}
static public void Write(ConsoleColor c, string s, params object[] args)
{
var old = Console.ForegroundColor;
Console.ForegroundColor = c;
Write(s, args);
Console.ForegroundColor = old;
}
static public void WriteNewline(int count = 1)
{
while (count-- > 0) Console.WriteLine();
}
static public void WriteLine(string s, params object[] args)
{
Write(s, args);
Console.Write(Environment.NewLine);
}
static public void WriteLine(ConsoleColor c, string s, params object[] args)
{
Write(c, s, args);
Console.Write(Environment.NewLine);
}
#endregion
}
}
Ehem. I tried running the code at my HTPC, a different computer from the one I coded this on, and now I cannot reproduce the problem. That is, I do observe the burst leading to just a step, but that is due to a logical error in my code (when the report interval is reached it sets burst to -1). It’s hard to believe I did not set my breakpoint, stepped through, and saw the variable get destroyed, because I know how weird that would be and tried several times to be sure I saw what I thought I saw. But it’s also hard to believe I had stumbled upon such a weird and deep bug in the framework/clr, especially considering that my code had a bug that causes the thing that got me attaching the debugger in the first place..
In any case, I’ll mark it as closed. And post the revised code here if anyone wants to play with it. I’ve fixed the bug and made the output a bit more compact so it works better on less generous screens than the 22″ full-HD_one I did this on. It now uses 8 columns regardless of the console width, on the probably safe assumption that most people use standard 80-char width, into which 8 columns now fit.
If anyone would care run this and post their findings (just press P to quickly get stable frequencies, the step/burst thing is for silly stuff like seeing what the distribution looks like after fewer generations). On my HTPC, I get this result:
This means: Bytes 0x00 to 0x3f each made up 0.34% of all the bytes in all the guids generated (509,194 in this particular case, but I get this result every time with more than 100,000 guids or so). There are 3 very distinct groups, and maybe if I now go and read about Guids on wikipedia I will understand why that is. But it wouldn’t be as much fun to do this if my “discovery” was something I knew before I began. 🙂
Post your results, ladies and gentlemen. 🙂