Lotteries as Investments

There has been a lot of excitement lately about the Mega Millions lottery reaching its largest-ever jackpot of $476 million. This can happen whenever a long period of time goes by without a winner, as the jackpot continues to "roll over" and accumulate. Having co-workers and friends that enjoy thinking about probabilities means that a lot of impromptu discussions have sprouted regarding the general question: "Should I play?" The answer, unless you are already a billionaire, is no.

This post is based almost solely on the information in the excellent and accessible paper by Abrams and Garibaldi entitled, "Finding Good Bets in the Lottery, and Why You Shouldn't Take Them". I will cover some of the same ground, but with a focus on working up the current Mega Millions jackpot as an example, using their paper as a starting point. I'll show, specifically for this $476 million jackpot, that Mega Millions may be a good bet this week, depending on the number tickets sold. Spoiler alert: but it's still a bad investment.

Betting Vs Investing

Abrams and Garibaldi define "good bet" to mean any wager with positive expected return. My fellow poker players are very familiar with this concept, and it's why we head straight for the poker room in a casino instead of stopping to play craps or slots (well, most of us). If you're sitting there with pocket aces, you know it's a good idea, mathematically, to get all your chips committed pre-flop. In fact, you're pretty close to an 85% favorite to win against a single opponent.

A "good investment", on the other hand takes risk of ruin into account, and is much harder to understand. Under very specific circumstances, it might be right to fold those pocket aces pre-flop! If you're on the bubble in a satellite with a hard cut-off and you see two other big stacks get all-in ahead of you, it's probably better to fold AA. For those of you that don't follow poker jargon, imagine the case of real estate auction sales: you can get properties at fractions of their worth, but there is a reasonable chance (say 25%) that one of them will be totally worthless - and you must pay cash. The auction is only a good investment if you have enough capital to absorb some bad runs of luck: 3 out of your 4 houses you bought this time around turn out to be structurally unsound and worthless, instead of the expected 1 out of 4.

That's Nice - Should I Play or Not?

OK, enough background. Let's get to the analysis! I'll save you the formulas: the probability of any randomly selected ticket in Mega Millions being a jackpot winner is 1 in 175,711,536. There are also lesser prizes with correspondingly higher probabilities, and on the downside the jackpot needs to be diluted for taxes and the probability of having to split the prize with another winner. To begin, we must calculate the simple expected rate of return (eROR), which requires knowing the ticket sales. Since we don't know that for March 30, I plugged in the numbers from the previous drawing, and then gave some projections for color on the next one. I drew heavily from Abrams to calculate these numbers:

March 27: $363M jackpot, 190,922,875 tickets sold. eROR=-3%
March 30: $476M jackpot:
    100million tickets sold: eROR=58%
    200million tickets sold: eROR=24%

    300million tickets sold: eROR=Dead Even

    400million tickets sold: eROR=-17%
(Note: all returns assume 25% taxes withheld)

Abrams converts these financialish returns into break-even curves, which I won't show here (see page 14 of his paper if you're curious). Then he uses some calculus that I also won't include here and generates an upper and lower bound for all possible break-even curves for lotteries like Mega Millions. The end result, though, is that we want the jackpot to be large relative to the number of tickets sold. But you didn't need all the math above to tell you that. What the math tells us is how much larger it needs to be.

Well it turns out that anytime the Mega Millions jackpot (lump sum, after tax) is 20% more than its ticket sales - and as I said you'll need to project this number - it's a good bet. By the way, it also has to be larger than 171million (after tax), which is the straight-up probabilistic break-even regardless of sales. Abrams predicts that this will never happen, and that the surge in ticket-buying that surrounds a big jackpot more than makes up for the improved probability-weighted return. I think he fails to see the large numbers that can happen in a roll-over jackpot like Mega Millions, which is a natural human mistake.

There is an undefined upper-bound to the public's appetite for lottery tickets regardless of mathematical edge, as well as a diminishing stimulus to ever-higher jackpots. Eventually, an extra $100million in jackpot fails to generate an extra 100million ticket sales in a few days. And that's what we're seeing right now: the jackpot has gotten so big that the habitual and some-time players have all already joined the list. Even the almost-never players are about tapped out at this point, which lets the jackpot grow without adding additional ticket sales.

Yes Yes, 300 Million Tickets - Should I Play or Not?

Will March 30 be a good bet? This really comes down to your opinion of whether 300 million tickets will be sold. If I were a betting man, and I am, I would set my over-under line at just about that figure. But I'll look one drawing farther into the future, and say this: if it rolls over one more time, the jackpot will outpace demand. At that point, it will certainly be a good bet.

But will it be a good investment? The short answer is no. Abrams goes into a detailed portfolio analysis of the variance on the Texas Lottery, using the Nobel Prize-winning techniques developed by Markowitz and Sharpe in 1990. He calculates that for that particular lottery, a reasonable investor should invest nothing in any syndicate buying lottery tickets unless that syndicate buys at least 145,000 per week. These numbers are impressive, but they don't really apply to Mega Millions. To do that, I would have to retrace the rest of Abrams' work, which I leave as an exercise for the reader. But intuitively, I think we can all see that the variance on a 1-in-176million investment is crazy-high, and should be such a tiny sliver of any investment portfolio that only the largest investors would buy any tickets at all.

I am not that investor, so I won't be buying a ticket next week, regardless of the March 30 outcome.

As a post-script, as I was chasing down all the links for this post, I stumbled upon a less technical version (Word document) of the paper I wish I had found before working through the math for this post. If you want Abrams' own words, I suggest starting there. And if you want the spreadsheet I used to do the calculations, I put it into a public Google Docs file. You'll need to download it in order to play with the numbers, but help yourself.

Happy 1987

It's 1987 in the Year a Month project, and this month is shaping up to be a good one.

Black Sabbath: The Eternal Idol - Wow, what a mess Black Sabbath was in while this album was being recorded and promoted. They had massive member turnover, apathetic reviews, and poor sales numbers. Then they made the poor decision to tour apartheid-era South Africa, and saw their other European shows cancelled by promoters in revenge. They were subsequently dropped by two record labels. Strangely, despite all the drama, this is a pretty good album. I like the guitars, and Tony Martin (no, I've never heard of him either) sounds enough like Dio to make the sound work pretty well.

Anthrax: Among the Living - I have State Of Euphoria (1988) and Persistence of Time (1990) already, and always wondered what the missing link was between Fistful of Metal's (1984) sound and those albums. Well, I found it. The guitars on this album are amazing, cranking out riff after riff of "screw you" metal goodness. But the vocals are turning into the Ethel Murman belly-holler that pulled Anthrax off of my playlist in the 1990s.

Dio: Dream Evil - I swear I think Dio gets better with every album. He hits it hard right off the bat with some near-thrash guitars on the first track, Night People, which for Dio is about as hard as it gets. Something about his voice makes him the perfect medium-metal singer to represent the 1980s.

Overkill: Taking Over - Overkill has some of the most technical and entertaining guitar licks of any 80s-era band in my collection. The vocals, bass, and drums just kind of follow along like lost children. There isn't anything all that notable about this album, except the extreme level of 1980s-ness clearly apparent on the cover. It rocks, I like it, whatever.

Motorhead: Rock 'n' Roll - this album may contain some of the songs that we heard at the recent Volbeat/Motorhead/Megadeth concert in Chicago. I say "may" because when Lemmy cranked up the on-stage guitar amp and blew one of the speakers, causing the poor sound guy to have to crank everything else to compensate, it damaged our hearing so much that we had no idea what songs he was playing. It took Megadeth three songs before they finally got the mix right again, and even then I couldn't tell you what Mustaine was saying between songs. Sorry, Lemmy, but you can't reach the volume control on my MP3 player.

Random Hubble Desktop Wallpaper

As I settle into my new Arch workstation, I find myself going through all the little nesting behaviors that any user would demonstrate. Only it's a little more challenging this time around, because instead of a user-coddling operating system like Windows or Ubuntu, I'm using Arch Linux. And instead of using a familiar desktop environment like Gnome, I'm using KDE 4.8. So the most basic of things provides an opportunity for learning. For example, I spent a good 30 minutes trying to figure out how to set up the screensaver the other day. It's easy, and very similar to how every other operating system does it; but I just didn't know where to look.

One of my computing goals this year is to stop taking the features and options spoon-fed to me by the desktop environment and instead be willing to step up and exert my own will on the environment. Arch/KDE is a perfect combination for this, because they are both all about basic building blocks and customization. In my previous installation (Ubuntu 10.10), I had a little python script that I grabbed from Christian Stefanescu that will download the NASA image of the day and make it your desktop wallpaper. I still have that script, and I could use it with a few modifications for KDE instead of Gnome. But NASA's image of the day is hardly ever cool things like stars and galaxies, and instead is usually pictures of people smiling for the camera, or close-ups of a really important and boring piece of metal. I want something with some curb appeal.

I looked into a few other daily-image sites, like Alta Ski Area and National Geographic, but they just aren't designed to be wallpapers - the resolution is too small to look good at 2048x1152, and they're frequently in portrait-mode, which looks terrible on my widescreen monitor. Of course, Murphy's Law dictates that today when I go look at those sites to get the links above, they both are showing images that would look great as wallpapers. Trust me, they're the exception, not the rule. But I digress.

The official Hubble Site has a bunch of fantastic images in its gallery, but they don't pick one a day for you. There is a main page that shows thumbnails of all the images, a resolution-selection page when you click on a particular image, and finally another page that displays the image inline. I figured I could probably handle this with a Perl script, so I grabbed the HTML::Parser package from CPAN to do the heavy lifting, and did a little reading of its description page. It treats the incoming HTML document like a hierarchical tag system, just like most XML parsers do. I've never used an HTML parser before, but I wouldn't be surprised to learn that this is standard - it makes the most sense. You start by deriving your own class from HTML::Parser, and write start() and end() callbacks. Then as each tag (<div>, <a>, <img>, etc) is opened by the parser, it sends interesting info to the start() callback. When it closes, it calls the end() callback. In this way the entire tree of HTML is traversed, in a depth-first fashion.

Wallpaper Thumbnails

Resolution-selection

2048-wide image

Being a Perl newb as well as an HTML::Parser newb, I did the easiest possible thing, which was to define three different classes - each tailor-made for one of the three pages that were required for finally getting the image. There is no error-checking or customization capability - paths are all hard-coded, and if anything goes wrong the script will probably just crash. But that means my wallpaper won't change for a couple days, or until I have time to investigate -- not exactly life-threatening. This is another example of utility code that simple doesn't warrant any more attention than is necessary to get it running. I finished it in about an hour.

I have this script scheduled to run every day at 4:00 pm, because that's about the time I get home from work and turn on the computer. It makes me happy to see a new wallpaper appear out of nowhere as I'm getting my email and paying bills. And after all, isn't that the point?

Download the source code if you're interested.

Recovering an Unbootable Kernel Image

This is a quick how-to on rebuilding an Arch Linux initramfs image when both the main and fallback images are unbootable. This can happen if something goes wrong during an update to the "linux" package and the problem isn't detected and solved before a reboot. This post draws information from the Arch Wiki articles Change Root and mkinitcpio, as well as an Arch Forum post discussing a path problem causing an unbootable image. All the information necessary to recover is contained within these three links, but I felt that a cookbook would be helpful, especially in the stressful moment when a vital computer is sitting at the limited shell prior to booting the kernel.

This is intended to solve the specific problem when the Arch bootstrap claims it can't find the boot drive, and when it is very unlikely that the hardware is actually having a problem. In my case, I experienced this with regularity on a Virtual Machine, which was not having virtual hardware failure. It turned out to be exactly the problem in the forum post described above, but first I needed to recover the system.

Step 1 - Get It Booted
Your system isn't going to boot on its own: both the primary and fallback boot images are refusing to behave. So go get yourself an Arch ISO and burn it to CD or a USB. If you've already installed Arch, you know how to do this. Or read the Arch Wiki article about it if you've forgotten. Use the download and burn process as an opportunity to take a deep breath - that will help with the remaining steps.

Boot from the ISO, and choose the first option from the ISO's boot menu. But don't start Arch setup. Instead get the network running so you can update with pacman.

# aif -p partial-configuration-network

Answer the prompts. If this first step doesn't go well, don't sweat it - it just means you won't have internet access, which probably isn't required anyway.

Step 2 - Take Stock
We need to manually mount all the necessary partitions, and to do that we need to know what they are. If you remember how you partitioned your disk, that's great. But if you don't remember exactly which /dev/sdaX goes where, you'll need to do a little guessing. Luckily, fdisk can help. Note that I've trimmed the output some for brevity. I've also cheated a little and typed in some partitions from gparted because my /dev/sdb uses GPT.

# fdisk -l

Disk /dev/sda: 100.0 GB, 100030242816 bytes
   Device Boot     Start         End      Blocks   Id  System
/dev/sda1   *         63     3903794     1951866   83  Linux
/dev/sda2        3903795   195371567    95733886+  83  Linux


Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
   Device Boot     Start         End      Blocks   Id  System
/dev/sdb1             31 3871748080   3871748047   83 Linux
/dev/sdb2     3871748081 3907029134     35281054   xx Linux-Swap

On my system I have a roughly 2GB bootable ext2 partition on /dev/sda1 and the remainder of the 100GB SSD is ext4. I have a 1.8TB data partition at /dev/sdb1, and my swap file is /dev/sdb2. This is enough information for me to remember that sda2 mounts to / and sdb1 mounts to /caviar but contains the /var directory, which is sym-linked over from sda2.

If fdisk isn't enough to jog your memory, you may need to test-mount and explore a little.

Step 3 - Mount and Prep

Once you know which partitions you need to mount where, get it all mounted under /mnt/arch. Also mount the proc, sys, and dev directories so they'll be available to your chrooted sandbox.

# mount /dev/sda2 /mnt/arch

# mount /dev/sda1 /mnt/arch/boot

# mount /dev/sdb1 /mnt/arch/caviar

# mount -t proc proc /mnt/arch/proc

# mount -t sysfs sys /mnt/arch/sys

# mount -o bind /dev /mnt/arch/dev

In case you need to update with pacman, you'll want network access. If you got the network running in Step 1, copy the resolv.conf down into the chroot world.

# cp -L /etc/resolv.conf /mnt/arch/etc/resolv.conf

Step 4 - Chroot and Fix

Next, jump into your sandbox.

# chroot /mnt/arch /bin/bash

Now that you're here, feel free to poke around in logs to see what might have gone wrong. In my case, I had stupidly run pacman -Syu --noconfirm from a cron job without setting the PATH to include /sbin. As a result, the update script failed to call depmod but then blindly ran mkinitcpio on the incomplete map files, rendering the image stillborn. The depmod result should really be considered during a linux upgrade so that mkinitcpio doesn't trash the boot image, IMHO, but what do I know.

For now, let's assume you have the same problem I did. To resolve it, all I needed to do was the following:

# /sbin/depmod

# mkinitcpio -p linux

As a precaution, I also did a full update with pacman and made sure that everything went smoothly.

# pacman -Syu

All was well, and I was able to reboot into my system again. 

Happy 1986, Part 2

Last month in the Year-a-Month project, I decided to split 1986 into two installments to control costs. This month is the second installment! I was mainly disappointed in the results last month, but I'm happy to say that 1986 has been redeemed.

Accept: Russian Roulette - In December (1985), I pointed out that Accept was starting to sound too much like AC/DC. They cleaned up their act somewhat with this album, returning to a more traditional heavy metal sound for most of the tracks. There are still the occasional low points, like the first part of the title track. But by and large Accept sounds more like Overkill on this album than AC/DC.

Iron Maiden: Somewhere in Time - I'm always happy when I have a chance to add to my Iron Maiden collection, and this album is no exception. Unwilling to follow the 2nd-person romantic lyrical cliche of so many other bands, Iron Maiden uses a great deal of imagery to imply the meaning in their songs, instead of just whipping it out and laying on the table for all to see. I'm no expert, but to me, that's poetry. And it rocks. Win-win.

Megadeth: Peace Sells... But Who's Buying? - Megadeth is a much more technical guitar sound than anyone else this month. It's always nice to have a stand-out, even when the crowd is as good as these other albums are. Mustaine, at this point in his career, is still pretty annoyed with Metallica. So his rage is pretty thick, and that translates into the guitar riffs. In a good way.

Motörhead: Overkill - after trimming out the duds last month, I found myself with too much to order all in one month, but not enough for two months. I have an easy solution to that: a catch-up album with Motörhead! This one is from 1979, and let's face it: it sounds just like every other Motörhead album. If you like road-metal about drinking, drugs, groupies, and sleeping on a bus, then you'll like this album as much as I do.

Document Scanning in Linux Using Perl

I decided I wanted to take all the old bank statements, credit card bills, and paystubs that we keep in a file cabinet, and scan them into digital format - PDF, to be precise. This is more secure, because we can easily make backup copies and encrypt anything sensitive. And it's less clutter, because even a small hard drive can hold many lifetimes of statements, records, and bills. It was a pretty straightforward plan:

1. Buy a scanner
2. Scan all the documents
3. Shred all the documents

Of course, being me, I had to improve the process a little.

First off, we chose the Fujitsu ScanSnap S1500. There is also an identical S1500M, the only difference being whether the bundled software is written for Windows (S1500) or Mac (S1500M). Notice there is no S1500L (L is for Linux, boys and girls!). No big deal, though, because after only a few minutes of Googling I was able to be pretty certain there were drivers on my real operating system that would handle it. It was a bit more expensive than I would have liked, but having used it for a while now, I couldn't be happier with it. It scans fast, it scans well, and it does multiple pages and full duplex like a champ. Oh, and it opens like a frickin' Transformer. Awesome!

It uses USB, and I use Linux, so I politely ignored all the step by step instructions and software, and instead powered it on and jammed the USB cable into my machine to see what Ubuntu thought of it. Ubuntu thought it looked like a scanner, and it might like to do some scanning with it. No downloads, no crapware, no driver hell, and no problems. Nice. After a few test scans to get my resolution, orientation, and whatnot the way I liked it, I grabbed a handful of monthly bank statements and started scanning.

OK, that's tedious, and I hated having to re-type the damn file name every time. Chase_2007-01.pdf, Chase_2007-02.pdf, Chase_2007-kill-me-now.pdf. It would be nice to simply tap a key on the keyboard every time I get a document ready. I don't need a GUI, so maybe scripting is the right answer... more Googling.

To take input from a scanner and turn it into a multi-page PDF, (at least) 3 steps are necessary:

Step 1: Grab Images From the Scanner

On the Linux command-line, there's a great command called scanadf that will scan all the pages in an automatic document feeder (ADF) and store them as PNM files. The command for doing that for the May 2007 Chase bank statement is:

scanadf -o Chase_2007-02_%d.pnm --source "ADF Duplex" --mode Lineart --resolution 150

Notice the "%d" in the file name. If it's a multiple page statement, each page will be a separate PNM file, and each file name will replace the "%d" with sequential page numbers. PNM files are essentially graphics files.

Step 2: Convert the PNM Files to PostScript

This is a dumb intermediate step, in my opinion. I don't see why no one has simply written a direct PNM-to-PDF conversion utility. But whatever, another command called pnmtops gets this done:

pnmtops -noturn -rle Chase_2007-02_1.pnm > Chase_2007-02_1.eps

This command gets repeated once for each page, varying the file name like scanadf did. The result is a bunch of Encapsulated PostScript files, one for each page.

Step 3: Convert the EPS Files to a Single PDF

I had never used GhostScript before, but I had certainly heard of it. It always sounded kind of glamorous and mysterious - it's definitely mysterious. I tried to read its man-page and got lost nearly immediately (Adobe's docs always do this to me, too), so eventually I just found a recipe for doing what I wanted and stopped asking questions:

gs -q -dSAFER -dNOPAUSE -dBATCH -sOutputFile=Chase_2007-02.pdf -sDEVICE=pdfwrite Chase_2007-02_*.eps

With all these new-found powers at my disposal, I wrote a Perl script. I had it bump the month up by one and scan in all the pages every time I hit the enter key. I gave it the ability to pass in the starting month/year and the base file name ("Chase") on the command-line. Then I found I was missing the odd statement now and then, so I gave myself the ability to type "skip 1" instead of just hitting enter - this skips a month (guess what "skip 4" does) and continues scanning. Then I came across a monthly statement that was in color and on a single side of each page, so I added more command-line arguments to switch to "Photo" mode at 300dpi and to use "ADF Front" instead of duplex. Then I started scanning statements from a bank that for some reason liked to end its months on the 15th. Being a precise kind of guy, I added the ability to optionally include the day in the statement date: Chase_2007-02-15.pdf.

Then I ran into a brokerage statement that wanted to be landscape.

Step 1.5: Rotate the Damn Page 90 Degrees

Believe it or not, you need another program for this, called unpaper. This is a powerful and feature-rich utility, but I only use it to rotate the page. So the script only executes the following command if rotation is selected:

unpaper --pre-rotate -90 --no-processing 1 Chase_2007-02_1.x.pnm Chase_2007-02_1.pnm

Notice that the input file has that extra ".x." in it - I add that to the output of scanadf if rotation is selected.

What else could this amazing script possibly need? Well, I didn't like that the title displayed in my PDF Viewer was "Chase_2007-02_1.eps" - that seemed a little amateur. So the script also creates and then uses a PDFMarks (link is a PDF) file that sets the Title to "Chase_2007-02", and also sets the CreationDate property to February 15, 2007, because really, why not.

Perfect. I will never need to change this script again. Now let's scan some bi-weekly paystubs. Oops.

The Wrong Way

OK, I'm a professional developer, and I'm pretty good at what I do. I know the right thing at this point would have been to change the script to be able to specify the period. But at that moment, for some reason, I chose to copy the entire script, and change that copy into a bi-weekly one. Ugh. 

Later that same day I realized that manually scanning even the annual statements from retirement accounts and whatnot was kind of cumbersome. So of course that's when I fixed my mistake, combined the two scripts, and added annual periodicity, right? No. I cloned the script again. I'm so ashamed.

I lived with this abomination for nearly a week before its software equivalent of screamed obscenities in a silent church was finally too much for me to handle. Never mind that it was perfectly functional - that's not the point. It needed refactoring. Since it is just a little utility script, after all, I compromised on the perfection. There are still three separate scripts, but they now only do the monthly/yearly/bi-weekly work. They use a common module that does the actual scanning and common option management, so while the design is still terrible, at least I have some code reuse.

I'm publishing the full source for it right here (zip) in case anyone wants to use it, adapt it, or improve it. Let me say one thing up-front, though: I am a terrible Perl programmer. My syntax is nearly non-existent, requiring many trips to perldocs to figure out how to do the simplest things. And I realize that my Perl code looks like a C++ developer wrote it - there's a good reason for that. So if you've stumbled on this blog looking for scanning info, and you're a Perl master, have a good laugh at my expense. But please don't tell me about it.

Now if you'll excuse me, I have some quarterly (oh crap!) bills to scan.

Happy 1986, Part 1

And Happy New Year! It's 1986 in the Year-a-Month project, and there are so many albums needed to flesh out my collection that I decided to split 1986 into two separate months to control my costs. 1986 is a tough year, because so many hard-rock bands from the 1970s and early 1980s started selling out and turning into pop-rock bands (I'm looking at you, Ted Nugent).

 Black Sabbath: Seventh Star - Wikipedia says that this album was a major, intentional departure from the classic Sabbath sound. As usual, Wikipedia is absolutely right. I like the change of pace, though. The style is a lot more groove-metal than previous Sabbath albums, and by using a (yet another) different lead singer - in this case Glenn Hughes - it lets Sabbath get away with sounding like an entirely different band. Sort of a vacation from themselves.

Joe Satriani: Not of This Earth - This one was a tough decision, because some the track previews were pretty promising. But overall it was a little too electronica-ish for me, and I decided with all the other music that needed buying this month, I could afford to miss it. Does anyone else think he looks a lot like Adam Sandler in this photo?

Judas Priest: Turbo - In the spring of 1989, I was finishing up my freshman year of college, and my school had a compressed-schedule "Spring Term" in which students took only a single class, but that class was a full day every day for a month. Students in other majors went cool places like France or the Galapagos, but I opted to take a 400-level Compiler Construction class. We were using Turbo C to build our compilers, and every time I invoked the "turbo" command on my development machine, I caught myself humming the title song to this album. I did very little partying that term.

 Motorhead: Orgasmatron - This might get me blasted by die-hard Motorhead fans, but bear with me. I'm starting to notice that all Motorhead songs pretty much sound the same. Normally I would slam a band for this transgression (I'm looking at you, AC/DC). But for some reason I love the way Lemmy belts these songs out like he's just finished vomiting up the pills he popped a few minutes ago, and is thinking about popping some more.

Ozzy Osbourne: The Ultimate Sin - Ozzy is not the most exciting heavy metal act in the world, but this is a solid album. He seems to be a little more in the game than the last one, and I caught myself tapping my foot from time to time, which is more than I could say for Bark At The Moon.

Ted Nugent: Little Miss Dangerous - As alluded to above, I have very little patience for Ted these days. It only took a few samples sporting electronic drums and prominent keyboards from this album to make me move on. Nugent's next album comes in 1988, and we'll see what he's up to then.



Next month I will conclude 1986 with Accept, Iron Maiden, Megadeth, and a bonus catch-up Motorhead.