It's come to my attention that the possible combinations of letters possible with 7 letter tiles is just shy of a million. That's just with those seven letters. It doesn't take into account the combinations with what's already on the board. Running a spell check against all of those combinations is way too costly in terms of CPU cycles. I'll have to work it another way.
Instead of starting from a list of over a million possible combinations of letters, I can start from a list of valid words. There's good news here.
From http://personal.riverusers.com/~thegrendel/software.html
Updated millennial edition of ENABLE (ENABLE2K): The Enhanced North American Benchmark LEexicon package provides a 173,000+ word standardized tournament-level master list, more carefully researched than "official" and proprietary lists. It is not restricted to words of an arbitrary length and it features all "official" updates. The ENABLE list has been placed in the Public Domain and is both free and freely distributable. This is the list used by the WORDY word study system, above, and by various online Scrabble® servers and software developers (at least two commercial word games use it as its dictionary). It is highly recommended that the (updated) ENABLE SUPPLEMENT [785K], and the ABLE SUPPLEMENT [559K], additional lists and documentation packages for ENABLE be obtained. Freeware.
...
The YAWL LIST (updated Y2K version) is a combination of the ENABLE list and all the above supplementary lists, effectively a superset of the international SOWPODS list. It contains over 264,000 words and is probably the largest and most comprehensive list of its kind. This free Public Domain list is targeted toward Linux, BSD, Be OS, and other 'nix systems and is in standard UNIX ASCII format. It may require conversion before it can be viewed, edited, or accessed by Windows or Mac users. [704K]
That shortens our starting list from over a million to just over a quarter of a million. My idea, which is currently untested, is to go through this list in a series of iterations. Each iteration through the list would delete words we can't use from the list. This could get complicated, but it still looks like it will be faster than working at it from the other direction.
I was playing Literati with Kortnee this evening. In the middle of the game, I had a Very Bad IdeaTM. I thought, how hard would it be to create a program to automatically calculate the best possible move for me? The program itself wouldn't be too bad, but I’m not sure I could make the whole thing fast enough to be usable. But I like a challenge.
So now, I’m in the process of installing Visual Studio 2005 on Wraith so I can start the project. And I’ve got a short list of preliminary design requirements and ideas.
- Preliminary Design Requirements
- Must track current state of board
- Must keep track of current letters in hand
- Must use dictionary.com spell checker or equivalent
- Must give the results as best scores possible
- Must be able to do so within 3 minutes
- Must be able to quickly enter your moves and opponents moves
- Ideas & Things That Would Be NiceTM
- A branching algorithm may be able to speed up the searches
- Combination plays should have higher priority for searching
- If possible, it should be pretty too
- Would an interface that resembles the game be the easiest and quickest way to enter your opponents moves?
- Some Things I’ll Need to Research
- Scrabble theory
- Spell checker theory
- Searching algorithms
After about an hour of working through the logic in my Payroll History program, I finally found the bug that was causing it to report the wrong goal number of hours for each employee. It was a small mistake in the code, but a huge logical mistake. Then I discovered an even bigger one. To calculate the Goal Hours, we take the number of pay periods (which are two weeks) in the year and multiply it by 80.
To calculate the number of pay periods in the year, we use this formula:
yearend = {@yearend}
// Find the number of days between yearstart and yearend and add one to the result.
// The +1 lets us count the first day, which we would otherwise be excluding. days = DateDiff("d", yearstart, yearend) + 1
// Perform an integer division on it, so we can ignore the remainder. formula = days 14
The first mistake was that I’d excluded the +1, so if you printed the report on payday, it would give you results that were too small because of the rounding involved.
To get the year end, you just have to use the current day if you’re in the year you’re printing, but otherwise, you use December 31st. Getting the year start is more difficult. This is where the big logic error came in.
yearstart = DateSerial(ToNumber({payperiod.year}), 1, 1)
// unless the employee started after the first of the year.
if ({@hiredthisyear}) Then yearstart = DateValue({employee.fdthir})
// Then find the number of days between that day and the start of a known pay period before the
// software was written.
days = DateDiff("d", DateSerial(2001,6,1), yearstart)
// Now subtract the number of days that difference is from the start of a payperiod from the
// year start day.
days = 0 - (days mod 14)
formula = DateAdd("d", days, yearstart)
When I first wrote the formula, I was adding 14 – days mod 14 to the year start date and adding 1 to the number of payperiods I calculated. It only worked right when you had a year start date in the middle of the year, which was the case I was trying to fix at the time. However, it gave a result that was always a pay period off for people who’d been there the whole year. Now it properly counts that pay period that technically started before the year did since it’s the date you get paid that matters.
Today, I'm working on fixing a bug in some software I originally wrote in 2002 that generates reports for Payroll. It was originally written using Visual Studio .NET (the first version) and has since been maintained in Visual Studio .NET 2002 and Visual Studio .NET 2003. All of my new stuff is written using the .NET 2.0 framework in Visual Studio 2005, and will soon be moving to .NET 3.0. But I have a few programs we use here at work that are written using .NET 1.1. This is the first time I've worked on one of them since I installed Vista on Dark. This morning, I had to install Visual Studio .NET 2003 to be able to work on it.
The bug I'm working on is in a report for Crystal Reports that the program uses. It's a minor error somewhere in a formula that calculates the total number of hours they should have worked based on when they started and how far into the year we are. It's off across the board by 80 hours.
While looking at the formulas, something happened that it wouldn't let me view them to edit them anymore. I decided I should install the updates for VS .NET 2003 anyway, and maybe that will fix it.
Help -> Check for Updates...
Service Pack 1 is available, would you like to install it?
Yes.
Would you like to install from the internet or from a file on your disk?
The internet.
Where do you want to put the files?
I don't know, put them here.
(It proceeds to download the service pack.)
Would you like to install Service Pack 1 for Visual Studio .NET 2003?
Yes. I just told you that.
Do you agree to give your soul to Microsoft if you violate the terms of this license?
Yes.
(It pretends to install for awhile.)
Please insert the Visual Studio .NET 2003 Enterprise Developer - English disk.
Which one? There are 3.
(No response.)
Fine. Here's disk 1.
(It goes back to installing.)
Time Remaining: 24 minutes
Go to hell.
I hate annoying installs.
Coding Horror offerend an interesting look at .NET languages by comparing the differences between C# and VB.NET to the difference between Coke & Pepsi. My first reaction was to think I hate Pepsi. I really do. I have the same reaction to VB. The syntax of the language just bugs the hell out of me.
I guess VB.NET really is like Pepsi. I hate them both.
I was working on some graphics for HolosTek, Inc. earlier today and was having trouble deciding which font I wanted to use. The idea for a quick tool to view what I wanted in all of my fonts in a list.
Fifteen minutes later, I had a working tool for doing it. It is available for download here.
I've been working on a bigger coding project off and on (more off lately) for a couple months now. As part of the project, I wrote a screenshot capture utility. Last week, I needed a quick tool for capturing screenshots on another computer, without using Print Screen and a graphic editing program, so I pulled the code out of my big project and put together a quick utility. Took about 10 minutes to put a front end on it.
After a couple of days, I decided I'd polish it a little, although it's still really rough, and toss it out there as open source. The whole thing is written in C# using the .NET 2.0 framework. It uses GDI+ for the capture functions. If this might be something you can use, you can download it here.
If I ever get bored again, or someone asks really nicely, I might even go so far as to write documentation for it. The source code is fairly well documented, but nothing else is.
In October, Microsoft released Visual Studio 2005 (which supports the .Net 2.0 framework). About two weeks ago, I got my copy.
I have a couple of work projects that were written in C# (Under Visual Studio .NET and Visual Studio .Net 2003) that need some updating. I realized that I should learn about the new features in the 2.0 framework in a seperate project before tackling my older projects. This left me with the dilemma of deciding what to work on.
I've been evaluating trouble ticket systems for the last year or so, but I've never found one I liked enough to implement at work. So i've decided to write one.
It's been two weeks (as of tomorrow morning) since I started the project (called GHelp). Originally, I'd envisioned this as being a couple of days worth of work, but to get the functionality I really want out of it (and to be able to market it as well), it's going to be a couple of months.
I've got a lot of the functionality worked out, but there's still a lot of implementation to be done.
As a teaser, I'm including a few images from the project in the full text of this article.
On the bright side of all this, I did find an official MySQL connector for .NET. Unfortunately, it's going to make me want to recode all of my apps at work to use it. At least as a way to learn it. Hopefully it will help one of my programs that is having some issues with query errors.
I've been coding lately. It feels good. I've spent the last couple days working up a new version of a piece of software I wrote a couple years ago in C#. It handles a bunch of internal stuff at the office. While working on it, it reminded me of a project I've been playing around with in my head for a couple years.
