First, the good news: I've made a new release of WinROTT. It was a difficult release, involving multiple files. I ported the actor and action table functions to cpp.

Second, the bad news: I've been morbidly watching the economic reports and the stock market. I'm wondering where all of this will end up. I am amazed at the number of so called investors that think they can all wait for the stock markets to react rationally and start going back up. I don't think it will work this way.

If 90% of investors are waiting gleefully for capitulation so that the market will go back up, then we have not reached capitulation. In fact we are not close to true capitulation in the real sense of the word. The market will not allow 90% of investors to be winners and 10% to be losers. Investors watching patiently don’t realize they are simply marking time until they too, reach a state of panic. In an expanding market, it's not a zero sum game; in a contracting market, it rapidly approaches a zero sum game. (I wish I had paid more attention to my one and only course in game theory so I could explain this a little better.)

If every investor is using the same playbook, executing the same strategy and expecting the textbook outcome, then the outcome will be different. I am not too sure of the math, but I am pretty sure that the greater the population adhering to actions that should cause a particular outcome, the less likely that outcome will be obtained. In a zero sum game, you are not likely to have an outcome where 90% of the players "win".

In this market, the only thing we know is that it is not like anything any of us have seen in our lives.

I've run into an interesting problem with the WinROTT port. WinROTT using structures similar to the following to control single user enemies:

When moving to C++, you need to be aware that the following assignments are allowed in C, but not in C++:

The way I changed the code is to cast everything to a void pointer, and then make sure a cast exists in the function to correct the variable pointer type. There are about 160 of these functions. It turned out to be quite tedious and error prone. If you get on a roll with cut and paste, you are likely to create more problems that you solve.

Thank goodness for the weekend. This was a long work week. No horse shows this weekend, but my wife's bell choir is playing at church, so it means an early rise this Sunday. My daughter's been busy with 4H and homework. I basically have avoided all work, watched football, worked on WinROTT and generally lead an unhealthy lifestyle of fatty foods and no exercise - felt good to goof off. I cheered Alabama's victory over Mississipi state. I cheered for Troy, but LSU came back.

I have some good news on the WinROTT port. It looks like I only have 18 .c files to complete. I'm looking forward to being able to get started on some C++ housekeeping chores after the port of all the component files are complete. The old C code interchanged pointers and integers in most parts of the code. There are a lot of places where an integer is used to hold a pointer to the screen buffer. When I ported rt_game.c, the conversion logic doesn't work correctly and the status bars appear garbled in some instances. I decided to hold off repairing the status bar code until all of the .C files are ported and I can get rid of all the extern "C" declarations. I made this decision due to a variable initialization problem I've run into when mixing blocks of variable declarations and initializations around extern "C" blocks. I'll try to post what I have tonight.

I managed to get my bugs cleaned up in beta_rcomp. There's a new release for download here.

I'll publish some notes on the problem I had with beta_rcomp. My daughter had a horse show this weekend and I am just gassed this evening. I'll try to publish my findings in the next day or so. What I found while trying to get rid of some goto statements may aid future program ports.

I made a heartbreaking discovery last night. I've been working on a new release of dcdflib, with significant rearrangement of several routines to remove labels and goto statments. I had been performing limited testing and I was also checking in often. It's a slow process, it's easy to make a mistake and when you're tired, shortcuts are tempting. I took a testing shortcut after modifying beta_rcomp. I only tested a couple of subroutines in the demonstration program, thinking I had covered all routes that depended on beta_rcomp. I missed a dependency.

I was in the process of cleaning up the code when I ran a complete test set in order to review the entire output.  Right off the bat, I noticed two errors in routines I knew I had not touched. A little manual checking and I saw the dependency to the function beta_frac, which calls beta_rcomp. Drat.

Fortunately, I was able to review the source check-ins and located the problem. I was able to paste in the unchanged version of beta_rcomp and the program produced the proper output. beta_rcomp is fairly complex, and it was disappointing to lose my changes.

The moral of this story is:

Don't skimp or shortcut your testing and check in your source code often. I could have lost several days worth of changes with this bug. Instead, I only lost one routine, which I should be able to trace through and repair.

Update

Even if you are working on public code, you need to have a test plan. It's hard to maintain discipline 100% of the time, but you still need a plan. When things go a little wrong, like they did for me, the plan can help you get back on track.

You also need to check in often. I can't tell you how much more secure you will be in changing your source code if you practice good version control technique. I always check in after a full test. I don't like going days without checking in. It takes time, but it also enables other people using your software to trust your work more than if you are just cowboy coding.

This has been an interesting week. I've been working on the implementation of IDataReader and IEnumerable for a couple of classes in C#. The classes parse some complicated text files using regular expressions.

I've learned more about the .Net class that implements regex than I would care to know. (I am happy to have learned about the class.) I've also run into some minor cases where a regex I worked out in perl didn't work the same way in the Microsoft component. However, the MS component has many strong points that made implementing the parsing method simpler. This isn't a Microsoft bash, it's just there are some minor differences when it comes to handling /r/n sequences. (I was able to work around them without issue.) I can say that learning regular expressions is a requirement for programming. You can accomplish your parsing task without using regex, but you can't do it in six or seven lines of code. My advice is to obtain a regex editor and start learning.

More...

I made a small update to WinROTT. I've completed the intermediate port of the direct input routines to C++. (Intermediate means I am still using extern "C" since some of the source files are still in C, not C++ code.) Follow this link to the latest download.

I've decided to return to using the WinROTT page in my wiki to post the latest code.