James Michael Hare

...hare-brained ideas from the realm of software development...
posts - 149 , comments - 1242 , trackbacks - 0

My Links

News

Welcome to my blog! I'm a Sr. Software Development Engineer who has been performing C++/C#/Java development for over 20 years, but have definitely learned that there is always more to learn!

All thoughts and opinions expressed in my blog and my comments are my own and do not represent the thoughts of my employer.

Blogs I Read

Follow BlkRabbitCoder on Twitter

Tag Cloud

Archives

.NET

CSharp

Little Wonders

Little Wonders

vNext

Tuesday, May 19, 2015

Little Puzzlers–Validate a Sudoku Board

I like to keep my brain sharp by working on programming puzzlers. On off weeks I'm going to start posting programming puzzlers I've collected over the years. Hopefully you'll find them as entertaining as I do.

This one is a more straight-forward puzzler.  There’s no gotcha or “ah-hah” moment in solving this, it’s just an exercise in coding.  I’ll try to vary up the difficulty level of problems so they’re not all easy and not all brain-busters…

The Problem

Given a 2d 9 x 9 array of char representing an in-progress Sudoku board, validate that the board currently has no errors.  The​ board may be partially filled and may be unsolvable, the challenge is to simply determine if there are any errors with the solution so far.​

A Sudoku board has no errors if there are no numbers duplicated in the same row, or in the same column, or in the same 3x3 cube (as shown below by the heavy lines dividing the board into 9 equal 3x3 cubes).

Empty cells will be represented by a space (' ') otherwise, the cells will have the character representation of the numbers '1' thru '9'.

For example, this board:

250px-Sudoku-by-L2G-20050714_svg

Would be represented by the 2d array:

   1: var board = new char[9,9] 
   2:  {
   3:   {'5', '3', ' ', ' ', '7', ' ', ' ', ' ', ' '},
   4:   {'6', ' ', ' ', '1', '9', '5', ' ', ' ', ' '},
   5:   {' ', '9', '8', ' ', ' ', ' ', ' ', '6', ' '},
   6:   {'8', ' ', ' ', ' ', '6', ' ', ' ', ' ', '3'},
   7:   {'4', ' ', ' ', '8', ' ', '3', ' ', ' ', '1'},
   8:   {'7', ' ', ' ', ' ', '2', ' ', ' ', ' ', '6'},
   9:   {' ', '6', ' ', ' ', ' ', ' ', '2', '8', ' '},
  10:   {' ', ' ', ' ', '4', '1', '9', ' ', ' ', '5'},
  11:   {' ', ' ', ' ', ' ', '8', ' ', ' ', '7', '9'},
  12:  };
Again, the goal is to simply state if there are any errors in the Sudoku board as it stands, not to determine if the puzzle has a solution or is solvable.

Spoiler Alert!

Fair Warning: there may be discussion of the problem and potential solutions posted in the comments below. Read at your own risk.

Posted On Tuesday, May 19, 2015 7:23 PM | Comments (3) |

Thursday, May 14, 2015

C#/.NET Little Wonders: Expression-Bodied Members in C# 6

Once again, in this series of posts I look at the parts of the .NET Framework that may seem trivial, but can help improve your code by making it easier to write and maintain. The index of all my past little wonders posts can be found here.

Visual Studio 2015 is on the horizon!  In fact, some of you may already have played with the preview and seen some of the many neat new things to come – both in the IDE and in the C# language.

Note: All of the C# 6 features mentioned are current with the latest CTP of VS2015 as of the time of this writing.  The syntax and exact feature behaviors may be subject to change in the final released version.

Reducing syntax for trivial tasks

As we’ve seen in my previous posts on C#, a lot of the focus has been on simplifying syntax to remove some of the burden of common code and syntax for mundane activities.

One of the areas where we see a lot of syntax for something that should be fairly simple is in writing those somewhat trivial members that simply return trivial values or expressions.

For example, let’s say you have the following class defined to represent a Rectangle:

   1: public class Rectangle
   2: {
   3:     public int Length { get; set; }
   4:     public int Width { get; set; }
   5:  
   6:     // that's a lot of syntax for just getting L * W
   7:     public int Area
   8:     {
   9:         get
  10:         {
  11:             return Length * Width;
  12:         }
  13:     }
  14:  
  15:     // here too...
  16:     public int Perimeter
  17:     {
  18:         get
  19:         {
  20:             return 2 * (Length + Width);
  21:         }
  22:     }
  23:  
  24:     public override string ToString()
  25:     {
  26:         return $"Rectange: Length={Length}, Width={Width}";
  27:     }
  28: }

Notice how sleek and elegant the auto-properties look?  But how much syntax we need for a simple get-only property that just returns a trivial expression?  Sure, we can inline the whitespace to somewhat reduce our “vertical bloat” headache, but it’s still a lot of syntax.

This is why the folks at Microsoft working on C# 6 decided they could help with this and reduce the syntax of members where you want to simply return an expression and eliminate some of the unnecessary syntax.

Expression-Bodied Get-Only Properties

Now, if you have a property that is get-only, you can write the body of the property using the expression syntax.  That is, you can use the lambda-expression syntax to write the body of the property. 

That is, instead of writing the { get { return your expression; } } syntax, we can simply write => your expression;

For example, if we convert our get-only properties above, we can get:

   1: public class Rectangle
   2: {
   3:     public int Length { get; set; }
   4:     public int Width { get; set; }
   5:  
   6:     // much more concise!
   7:     public int Area => Length * Width;
   8:     public int Perimeter => 2 * (Length + Width);
   9:  
  10:     public override string ToString()
  11:     {
  12:         return $"Rectange: Length={Length}, Width={Width}";
  13:     }
  14: }

This removes a lot of the standard get property syntax for trivial properties that just result in a simple expression.  Now, you may ask, does this have any performance implications at runtime?  Actually, the answer is no.  This is simply syntactical sugar that expands into the same IL as writing the full body.  It does not create a delegate, it is simply borrowing the lambda expression syntax to simplify writing simple bodies that result in an expression.

Unfortunately, at this time, there is not a simplified syntax for setters, nor can you use this syntax for the getter and specify a setter long-hand, it only works on get-only properties (and methods as we’ll see below).

Expression-Bodied Methods

So, what about our friend the ToString() method up above.  It too returns a simple expression, could we use the syntax for methods as well as for get-only properties? 

Yes, we can:

   1: public class Rectangle
   2: {
   3:     public int Length { get; set; }
   4:     public int Width { get; set; }
   5:  
   6:     public int Area => Length * Width;
   7:     public int Perimeter => 2 * (Length + Width);
   8:  
   9:     // eliminated a wee bit o'syntax here
  10:     public override string ToString() => $"Rectange: Length={Length}, Width={Width}";
  11: }

Granted, I think we’re reducing less syntax here than we did with the get-only property, but it can still be nice for very simple methods.  The new syntax is even available for void methods, for example:

   1: public class MyCache<T>
   2: {
   3:     private ConcurrentDictionary<string, T> data = new ConcurrentDictionary<string, T>();
   4:  
   5:     // simple method which simply clears the dictionary
   6:     public void Clear() => data.Clear();
   7: }

Again, there is no magic or delegates behind the scenes, it is simply borrowing the lambda expression syntax to allow you to specify a method body in a simpler form.

So, should you use this?  It all comes down to style.  My gut would be to limit this to simple expressions and statements that can clearly be understood at first glance.

Summary

So C# 6 now gives us the ability to specify get-only property and method bodies with expressions.  This can help reduce the syntax burden of very simple methods to make your code more concise.

However, with all things, use your judgment on whether it fits for any given situation.  When an expression is very long or complex, using the full body syntax may still be more readable.

Thanks for reading and stay tuned for more features of C# 6!

Posted On Thursday, May 14, 2015 7:08 PM | Comments (1) |

Monday, May 11, 2015

Solution to Little Puzzlers–Positive Integer to Roman Numerals

This is the way I went about the "Positive Integer to Roman Numerals” problem. However, keep in mind there are multiple ways to solve this, so don't worry if your solution has variations and it’s entirely possible there are more efficient ways.

Feel free to suggest your solution in the comments here or in the original post, but please be respectful of others efforts.

My Approach

My approach was fairly straight-forward.  I simply built a “table” of denominations to the symbol that represents that denomination and arranged it in descending order by denomination.  In this way, I can just loop through the denominations, and as long as the remainder is > than the denomination, add the symbol and decrement the remainder.  Rinse and repeat!

The nice thing about this approach is it is fairly straightforward and can use some fairly optimal constructs (such as array iteration and StringBuilder for constructing a string over multiple statements).

In addition, the fact that the 4s and 9s (4, 9, 40, 90, 400, 900…) helps simplify the program greatly.

   1: public class RomanNumerals
   2: {
   3:     private class Denomination
   4:     {
   5:         public int Value { get; set; }
   6:         public string Symbol { get; set; }
   7:     }
   8:  
   9:     private static readonly Denomination[] table = 
  10:         {
  11:             new Denomination { Value = 1000, Symbol = "M" },
  12:             new Denomination { Value = 900, Symbol = "CM" },
  13:             new Denomination { Value = 500, Symbol = "D" },
  14:             new Denomination { Value = 400, Symbol = "CD" },
  15:             new Denomination { Value = 100, Symbol = "C" },
  16:             new Denomination { Value = 90, Symbol = "XC" },
  17:             new Denomination { Value = 50, Symbol = "L" },
  18:             new Denomination { Value = 40, Symbol = "XL" },
  19:             new Denomination { Value = 10, Symbol = "X" },
  20:             new Denomination { Value = 9, Symbol = "IX" },
  21:             new Denomination { Value = 5, Symbol = "V" },
  22:             new Denomination { Value = 4, Symbol = "IV" },
  23:             new Denomination { Value = 1, Symbol = "I" }
  24:         };
  25:  
  26:     public static string Translate(int number)
  27:     {
  28:         var result = new StringBuilder();
  29:  
  30:         int remainder = number;
  31:  
  32:         foreach (var current in table)
  33:         {
  34:             while (remainder >= current.Value)
  35:             {
  36:                 result.Append(current.Symbol);
  37:                 remainder -= current.Value;
  38:             }
  39:         }
  40:  
  41:         return result.ToString();
  42:     }
  43: }

Check out the comments in the original post for more interesting solutions as well!

Summary

Hope you had fun with this one!  Of course, I’m sure many out there can tweak the answer for performance in various ways – but you get the point.

Have a solution that worked for you but was totally different?  I’d love to hear about it!

Stay tuned next week for the next Little Puzzler.

Posted On Monday, May 11, 2015 4:49 PM | Comments (1) |

Friday, May 8, 2015

C#/.NET Little Wonders: Indexer Initializer Syntax

Once again, in this series of posts I look at the parts of the .NET Framework that may seem trivial, but can help improve your code by making it easier to write and maintain. The index of all my past little wonders posts can be found here.

Visual Studio 2015 is on the horizon!  In fact, some of you may already have played with the preview and seen some of the many neat new things to come – both in the IDE and in the C# language.

As with many of these posts, I started off thinking this was going to be a quick one.  I mean, a new initializer syntax, how much time can I possibly spend writing on that?  However, as I dug more and researched what I wanted to say.  It really highlighted how much more there is to it than meets the eye. 

Note: All of the C# 6 features mentioned are current with the latest CTP of VS2015 as of the time of this writing.  The syntax and exact feature behaviors may be subject to change in the final released version.

Collection and Object Initializers

Some people look at the new Index Initializer syntax and seem to think the Indexer Initializer is just a new way to use the Collection Initializer so that initializing a dictionary looks cleaner, but that’s not the case.  It’s really a brand new feature of Object Initialization and not directly related to collections at all.

However, for me to describe this best, I feel I need to take a quick moment to illustrate how object and collection initializers currently work to give the full context.  So, bear with me while I dive into Object and Collection Initializers from the beginning to get the back-story.

Basically, initializers allow you to simplify the job of initializing an object or collection by reducing the boiler plate code you usually see of creating an object and then setting various properties or adding initial members to a collection.

For example, let’s consider the following class:

   1: public class Point
   2: {
   3:     public int X { get; set; }
   4:     public int Y { get; set; }
   5: }

Now, if we wanted to create a new instance of Point before initializers, we would have had to do something like this:

   1: var point = new Point();
   2: point.X = 13;
   3: point.Y = 42;

Of course, we could create a constructor that takes an X and Y, and that would work for a class like Point where both properties are (generally) required.  However what happens when you start having a more complex object with multiple properties, some defaultable and others not?  Do you make a dozen different constructors to handle all of the cases and default the others?

Fortunately, with object initializer syntax, you can set any property or field that has is visible by specifying its assignment in a list after the construction:

   1: // object initialization syntax.  
   2: var point = new Point { X = 13, Y = 42 };

Note that this is not a constructor syntax.  This is literally the same as our code example above it, it’s just syntactical sugar to allow us to write the same thing more concisely.  It simply is a short-hand way for writing the individual sets of properties and fields on the object right after construction.

Collection initializers do something similar, but with collections.  They allow you to specify items to add to the collection at the time you construct it.  For example, say we want to create a list with the first 8 powers of two before collection initializer syntax, we’d have to write:

   1: // That's a lot of redundant typing
   2: var powersOfTwo = new List<int>();
   3: powersOfTwo.Add(1);
   4: powersOfTwo.Add(2);
   5: powersOfTwo.Add(4);
   6: powersOfTwo.Add(8);
   7: powersOfTwo.Add(16);
   8: powersOfTwo.Add(32);
   9: powersOfTwo.Add(64);
  10: powersOfTwo.Add(128);

But with collection initializer syntax, this can be simplified to:

   1: // much less typing involved
   2: var powersOfTwo = new List<int> { 1, 2, 4, 8, 16, 32, 64, 128 };

Again, this is just syntactical sugar.  It is literally calling the constructor then calling the Add() method implicitly using each item in the list, just like the code above it. 

Now, while you can set any visible property or field with the Object Initializer syntax, the Collection Initializer syntax requires two things to be true with any class with which you wish use to utilize it:

  1. Your class must implement IEnumerable
  2. Your class must have an Add() method

Oddly enough, the IEnumerable interface is not utilized at all in the collection initializer syntax, it is simply used as a “verification” (of sorts) that the object is a collection.  The rationale being that many different classes can have an Add() function (such as Fraction perhaps), but that doesn’t make them a collection.  Thus, the designers of .NET felt that making the class implement IEnumerable would be a reasonable way to ensure that the type was truly a collection.

Also, note that the Add() method can take any number or type of parameters (which is why it’s not specified by an interface).  To call a version of Add() that takes more than one argument, you surround the argument lists with curly braces. 

For example, if we wanted to initialize a Dictionary<string, string> with zip codes mapped to city names:

   1: var placesByZip = new Dictionary<string, string>
   2:     {
   3:         { "63368", "Dardenne Prairie" },
   4:         { "63141", "Des Peres" },
   5:         { "63101", "St. Louis" }
   6:     };

Again, this is literally the same as creating the dictionary and calling Add(…) explicitly, like this:

   1: var placesByZip = new Dictionary<string, string>();
   2: placesByZip.Add("63368", "Dardenne Prairie");
   3: placesByZip.Add("63141", "Des Peres");
   4: placesByZip.Add("63101", "St. Louis");

As you can see, the initializer syntaxes remove the need for a lot of boilerplate code in setting up an object or a collection.

But, you already knew this, right?  So why bring it up again?

It’s important to realize not just the syntax of the initializers, but what they do behind the scene and (in the case of the collection initializer) what you need to create for your class to support that syntax.

Indexer Initializers

Indexer initializers allow you to perform initialization activities on an object in a new way: by using its indexer (if it has one).  For example, consider our dictionary of zips to city names above.  Because a Dictionary also has an indexer, we could rewrite that initializer as follows:

   1: var placesByZip = new Dictionary<string, string>
   2:     {
   3:         ["63368"] = "Dardenne Prairie",
   4:         ["63141"] = "Des Peres",
   5:         ["63101"] = "St. Louis"
   6:     };

This uses the indexer syntax to allow us to specify a value for each of the keys.  In many ways, it looks more elegant, as the indexer syntax clearly calls out what part is the key, and what the value being assigned is.

“So, big deal”, you say, “it’s just a more clear version of the collection initializer, right?” 

No, it’s actually a brand-new feature of the Object Initializer syntax, and that’s an important distinction. 

First of all, this syntax does not call the Add() method as the Collection Initializer does, it instead calls the object’s indexer.  That is, it is actually compiling into something like:

   1: var placesByZip = new Dictionary<string, string>();
   2: placesByZip["63368"] = "Dardenne Prairie";
   3: placesByZip["63141"] = "Des Peres";
   4: placesByZip["63101"] = "St. Louis";

Now, in Dictionary the net result is the same, but keep in mind this isn’t necessarily true for all classes. 

The nice part is that indexers are not limited to collections, so you do not need to implement IEnumerable or have an Add() method, all you need is a visible set indexer.  This is nice because if you want to create a collection that had an indexer before and use collection initialization, you’d have to also have an Add() method and implement IEnumerable whether it made sense or not.  Now, however, if our class has an indexer, that’s all we need to use the Indexer Initializer syntax.

For example, what if we wanted to create a class called BitFlipinator that allowed us to flip specific bits.  For example, I could say I want to flip the 1st, 2nd, and 4th bits (from least significant side) to get the value of 11 (1 + 2 + 8).

If I wanted to build this before with support for the collection initializer, I would have to do something like  this:

   1: public class BitFlipinator : IEnumerable
   2: {
   3:     public int Value { get; private set; }
   4:  
   5:     // Add doesn't make sense in this context, but needed for
   6:     // collection initialization syntax
   7:     public void Add(int bit, int value)
   8:     {
   9:         Set(bit, value);
  10:     }
  11:  
  12:     // doesn't *need* to do anything, just needs to be here to use collection initialization
  13:     public IEnumerator GetEnumerator()
  14:     {
  15:         throw new NotImplementedException();
  16:     }
  17:  
  18:     // our method to set a bit to a 1 or 0
  19:     public void Set(int bit, int value)
  20:     {
  21:         if (value < 0 || value > 1) throw new ArgumentOutOfRangeException();
  22:         if (bit < 1 || bit > 32) throw new ArgumentOutOfRangeException();
  23:     
  24:         var filterBit = 0x01 << (bit - 1);
  25:         Value = (value == 1) ? Value | filterBit
  26:             : Value & ~filterBit;
  27:      }
  28: }
In order to be able to do this:
   1: var bitinator = new BitFlipinator
   2:     {
   3:         { 1, 1 },   // set the 1s bit
   4:         { 2, 1 },   // set the 2s bit
   5:         { 4, 1 }    // set the 8s bit
   6:     };

That’s a lot of boilerplate that doesn’t make sense.  And yes, you could argue whether a collection initializer really makes sense in this example, but the main point was that previously, we only had two choices for initializers: object and collection.

However, consider how we could now write this with an indexer and index initializer syntax:

   1: public class BitFlipinator 
   2: {
   3:     public int Value { get; set; }
   4:  
   5:     public int this[int bit]
   6:     {
   7:         set { Set(bit, value); }
   8:     }
   9:     
  10:     // our method to set a bit to a 1 or 0
  11:     public void Set(int bit, int value)
  12:     {
  13:         if (value < 0 || value > 1) throw new ArgumentOutOfRangeException();
  14:         if (bit < 1 || bit > 32) throw new ArgumentOutOfRangeException();
  15:  
  16:         var filterBit = 0x01 << (bit - 1);
  17:         Value = (value == 1) ? Value | filterBit
  18:             : Value & ~filterBit;
  19:     }
  20: }

Which allows us to write this:

   1: var bitinator = new BitFlipinator
   2:     {
   3:         [1] = 1,   // set the 1s bit
   4:         [2] = 1,   // set the 2s bit
   5:         [4] = 1    // set the 8s bit
   6:     };

Which is much more clear.  Notice that we no longer had to implement an IEnumerable, nor did we have to have an Add method which didn’t really make logical sense to begin with.  All we needed was a visible, settable indexer and we can use the new syntax.

Again, I wish to reiterate that the Indexer Initializer is not a type of Collection Initializer, it’s a type of Object Initializer.  Why do I keep saying this?  Why is this distinction important?  Because you cannot mix object initializers and collection initializers in the same initialization list. 

So, we can’t initialize a collection and set a property in the same initialization list, but we can set a property, field, and indexer in the same initialization list since they are all valid Object Initializers.

For example, my BitFlipinator has a property Value and an indexer.  I could take advantage of this to seed the value with a lot of 1s, and then clear our a zero bit.  For example, what if I want the number 255 but with the 4th bit (the 8s position) turned off, I could write:

   1: // sets bits 1 thru 8, then clears bit 4
   2: var bitinator = new BitFlipinator
   3:     {
   4:         Value = 255,
   5:         [4] = 0
   6:     };

So we can mix indexer, field, and property initializers in an object initializer list, but we cannot mix indexer initializers with collection initializers:

   1: // syntax error, one is collection initializer, one is
   2: // an object initializer setting an indexer
   3: var placesByZip = new Dictionary<string, string>
   4:     { "63368", "Dardenne Prairie" },
   5:     ["63141"] = "Des Peres"
   6: };

Pitfall: Know What Your Indexer Does

Now that you know you can use Indexer Initializers, the question is whether that is always logical.  The answer is it really depends on your type and what its indexer allows.  For example, consider the following code:

   1: // I'd like to only set elements 0, 2, and 5
   2: var spottyList = new List<int>
   3:     {
   4:         [0] = 13,
   5:         [2] = 42,
   6:         [5] = 100
   7:     };

This compiles -- it’s perfectly legal syntax.  The problem is it will blow up at runtime because List<T> does not allow you to index beyond the current size.  Since the constructed list has a size of zero, we can’t even set the 0th element.

Again, this is not a collection initializer syntax, it’s an object initializer that happens to be calling the indexer, like this:

   1: var spottyList = new List<int>();
   2: // blows up
   3: spottyList[0] = 13;
   4: spottyList[2] = 42;
   5: spottyList[5] = 100;

This is a place where the collection initializer makes more sense because it calls Add() which allows the list to grow, instead of the indexer which expects the list to be large enough for the index to be valid.

So remember, you should always know what that indexer’s expected behavior is before utilizing it (though this is true with using the indexers directly as well).

Summary

Okay, so we’ve seen there’s a new object initializer syntax to allow you to set indexers in an initialization list.  This gives us a lot of power to be able to initialize indexed types in a way that is very expressive and easy to read.  As a consequence, it can clarify the intension when initializing things like dictionaries.  To use an indexer initializer, your class need only have a visible, settable indexer.

Thanks for reading and stay tuned for more features of C# 6!

Posted On Friday, May 8, 2015 12:57 AM | Comments (2) |

Tuesday, May 5, 2015

Little Puzzlers–Positive Integer to Roman Numerals

I like to keep my brain sharp by working on programming puzzlers. On off weeks I'm going to start posting programming puzzlers I've collected over the years. Hopefully you'll find them as entertaining as I do.

There’s really no “ah-hah!” moment with this problem, but it is still – I find – a good programming problem for seeing how well a candidate’s mind works in structuring logic and finding patterns.

The Problem

Given a positive integer (i.e. > 0), please return a string representation of that integer using Roman Numerals.  You may assume IV for four, though you can optionally use IIII if you prefer the standard clock representation of 4.

Interesting side note: some say that the reason IIII is used instead of IV on clocks is because IV represented the Roman god Jove, and thus was omitted from the clock face to avoid “blasphemy”.

If you’re not familiar with Roman Numerals, you can find a good primer nearly anywhere on the internet (such as here on Wikipedia), though the basics are:

  • I = 1
  • V = 5
  • X = 10
  • L = 50
  • C = 100
  • D = 500
  • M = 1000

Roman numerals are generally written from highest denominate to lowest denomination, except where the previous “unit” letter is used to create 1 of the previous “unit” less than the next. 

  • I can be placed before V and X to make 4 (IV) and 9 (IX) respectively
  • X can be placed before L and C to make 40 (XL) and 90 (XC) respectively
  • C can be placed before D and M to make 400 (CD) and 900 (CM) respectively.

Note that V, L, and D are not used to prefix the next number since this would obviously be redundant (i.e. VX is the same as V, LC is the same as L). 

Spoiler Alert!

Fair Warning: there may be discussion of the problem and potential solutions posted in the comments below. Read at your own risk.

Posted On Tuesday, May 5, 2015 2:48 AM | Comments (15) |

Powered by: