SdkTk v1.0

Sudoku Toolkit

1. Functional Requirements

• The user should be able to solve a Sudoku board at a specified level.
• The user should be able to generate a Sudoku board of a specified difficulty.
• The user should be able to convert a Sudoku board to a printable format.

2. Implementation Details

2.1 Sudoku Board

First, we begin with a simple representation of a Sudoku grid. This is a two-dimensional array of numbers, of a given size N x N, with numbers from 1 to N filling the grid.  This stores the values in the solved portion of the grid. There is also a three-dimensional array of boolean flags, of size N x N x N, pertaining to decisions about various locations on the board, called the markup board. A ‘true’ in cell (I, J, K) in the markup board means that a value of K can potentially appear in cell (I, J) of the grid. This is the foundation for the entire Sudoku program. As values in the markup board need to be concurrently maintained with the values in the grid, methods have been created to place a value in the grid, that takes markup board entries into consideration.

2.2 Sudoku Solver

The Sudoku Solver extends the Sudoku Board class, adding solving methods.  There are roughly twelve to fifteen uniquely different methods for a human to solve a Sudoku grid. Of those, the ones with the most uniqueness were chosen to be implemented by the program. The solve method takes a difficulty level, and it begins at the bottom. It attempts the most basic of strategies, and continues using those strategies until they are no longer effective. Then, the program attempts more difficult strategies. Whenever a strategy is effective, we start back at the bottom of the difficulty chain and try the most basic strategies again. When we finally reach the difficulty level that was specified to the solve routine, or, if we have completed the puzzle, we stop.

2.3 Sudoku Generator

The Sudoku Generator simply generates a filled grid (more on this in a moment), then uses a dynamic programming algorithm to remove candidates until a threshold is reached. This is the concept of generating a “unique” grid, wherein there is only one legal solution. Since the Solver routines can only solve a board if it has a unique solution (no guesswork is ever employed), the ability to solve a grid proves the uniqueness of the board. If a cell is cleared, and no solution can be reached, we replace it and try another cell. The threshold specified is the number of “givens” the generated board should have. It is conjectured that the minimum number of givens required for a Sudoku board to be unique is 17, but no formal proof exists to this effect. Nonetheless, any value less than roughly 25 for this threshold may take considerable time to generate.

A filled grid is generated by using a legal filled board (which will the refered to as the canonical solved grid), then performing elementary row, column, and element operations. The three elementary operations are:

• Any row can be switched with any other row in the same tower.
• Any column can be switched with any other column in the same tower.
• Any value can be switched with any other value, as long as all values are exchanged.

Where a tower is defined to be a group of three (in the case of 9×9 Sudoku) rows or columns in the same row- or column-group, respectively. If only these elementary operations are performed, the legality of the solved grid is not compromised. Then, removing the elements in order to create an unsolved grid is described above.

3. Source Code

The source is available on coderprofile.com: SudokuToolkit v1.0

Functional Programming in C++, Pt. 1

Today’s Topic: map()

1. Apologies

I would just like to start by apologizing for the code that I have written. It is a naive approach to beginning work on a few of the basic constructs of functional programming in C and C++. It is not pretty, and it is not necessarily perfect. It does, however, work. I created some data structures to more closely emulate the syntax I desired, and I am in no way vouching for my code as being the best possible solution.

2. Implementation

Instead of dumping code here, I will discuss just the relevant function, to make the overall lack of elegance more palatable. I will also show how one would invoke the map function.

To explain a few things before we jump into code, in an effort to beautify the hacked-together code that was sure to follow, I created a few constants and structs. Firstly, I defined a constant called LIST_SIZE that I passed around to define the size of any array used in this code.

I also created a struct called SIZED_ARRAY that takes a type and an unsigned int, and creates an array of the specified type that can hold the specified number of elements. This array is templated in such a way that the size of the array is carried with the array itself.

Simple, right? Invokation of the map function, thanks to GCC inferring template parameters from arguments, is even simpler. So we have a function called multiply_two that takes an int and returns double that value. We could simply map that function to a list of values and now we have a map function, much like one would find in Haskell, or similar languages.

3. Source Code

The entire source code is available here: map.cpp

The Servitude of Developers

1. Introduction

Recently, the Funpidgin fork of the Pidgin instant messaging client project began based on disputes related to input field resizing issues. Apprently, two groups saw two sides of the same coin and felt that this would be worth forking the project over. Funpidgin, working according to a “we work for you” idiom, felt that the user should have the choice of behavior for the client, which the Pidgin project did not agree with.

No statement is being made about the stubbornness of the Pidgin loyalists. They went through painstaking trouble to make sure that the behavior of the client is intuitive and simple. Blogs, such as obso1337.org, did get a little up-in-arms about this attitude, claiming that users are not designers, and that they don’t think that the uninitiated masses should have a say in the development of a large-scale project.

This attitude [that users are designers] takes participatory design to all-new (and very dangerous) level. You go from user-centered design: keeping users in mind while designing a product, to user-directed design: catering to every users’ whim without consideration of the consequences (at least, users who know how to use mailing lists and bug trackers, who are not representative of a broad user audience for an instant messenger client). [Author's emphasis] [1]

2. Leadership

The underlying principle behind this message is fair: users that make up the minority or the unintended demographic might not be the best candidates for directing the design and development a project. That is understandable, since the project should have direction of its own. That does not mean, however, that they should have no say.

It is the idea that users are going to inherently work in their own best interest, forgoing the betterment of the overall project, that is irksome. Allowing users with different interests to have say in development can only make the outcome more diverse; nothing dictates that the “too many chefs” metaphor will produce a proverbial Rube Goldberg machine.

3. Rules, or a Reasonable Facsimile

Being an immature field, “computer science”, by and large, does not have the easiest time prescribing or adhering to a set of rules by which to operate. Organizations such as the ACM and IEEE do have codes of ethics by which they attempt to regulate their actions.

Taking the ACM, for instance, we find the following:

3.4 Ensure that users and those who will be affected by a system have their needs clearly articulated during the assessment and design of requirements; later the system must be validated to meet requirements.

Current system users, potential users and other persons whose lives may be affected by a system must have their needs assessed and incorporated in the statement of requirements. System validation should ensure compliance with those requirements. [2]

Note that no mention is made about the majority or minority, the target audience or the outliers. Simply put, all current and potential users should have their needs met. This means that, in essence, all users are developers, because it is the job of developers to listen to and satisfy the needs of those who will be using a given system.

This is the servitude into which developers enter. Needs of users outweigh the vision of the leader, outweigh that which is easy, outweigh petty bickering about text input fields, and outweigh the ridiculous notion that users are incompetent. Designers and developers must understand that they are the minority in their own project, and that the users are the ones who will crucify those who ignore their concerns.

4. Resources

1. Paul, Celeste L. May 2008. Four Words for Funpidgin. http://weblog.obso1337.org/2008/four-words-for-funpidgin.
2. ACM. Code of Ethics. http://www.acm.org/about/code-of-ethics.