It's the All Star break, which makes it a good time to take stock
of the season so far. Here are the standings after Sunday night's
games:
2005 American League Standings |
|
EAST | W | L | PCT | GB |
RS | RA |
Boston | 49 | 38 | 0.56322 |
0.0 | 473 | 429 |
Baltimore | 47 | 40 | 0.54023 |
2.0 | 431 | 409 |
NY Yankees | 46 | 40 | 0.53488 |
2.5 | 478 | 431 |
Toronto | 44 | 44 | 0.50000 |
5.5 | 428 | 381 |
Tampa Bay | 28 | 61 | 0.31461 |
22.0 | 399 | 553 |
|
CENTRAL | W | L | PCT | GB |
RS | RA |
Chicago Sox | 57 | 29 | 0.66279 |
0.0 | 413 | 339 |
Minnesota | 48 | 38 | 0.55814 |
9.0 | 396 | 360 |
Cleveland | 47 | 41 | 0.53409 |
11.0 | 406 | 365 |
Detroit | 42 | 44 | 0.48837 |
15.0 | 387 | 375 |
Kansas City | 30 | 57 | 0.34483 |
27.5 | 376 | 485 |
|
WEST | W | L | PCT | GB |
RS | RA |
LA Angels | 52 | 36 | 0.59091 |
0.0 | 420 | 355 |
Texas | 46 | 40 | 0.53488 |
5.0 | 476 | 430 |
Oakland | 44 | 43 | 0.50575 |
7.5 | 400 | 386 |
Seattle | 39 | 48 | 0.44828 |
12.5 | 377 | 388 |
|
2005 National League Standings |
EAST | W | L | PCT | GB |
RS | RA |
Washington | 52 | 36 | 0.59091 |
0.0 | 357 | 361 |
Atlanta | 50 | 39 | 0.56180 |
2.5 | 428 | 348 |
Florida | 44 | 42 | 0.51163 |
7.0 | 383 | 368 |
Philadelphia | 45 | 44 | 0.50562 |
7.5 | 410 | 417 |
NY Mets | 44 | 44 | 0.50000 |
8.0 | 387 | 381 |
|
CENTRAL | W | L | PCT | GB |
RS | RA |
St. Louis | 56 | 32 | 0.63636 |
0.0 | 447 | 340 |
Houston | 44 | 43 | 0.50575 |
11.5 | 365 | 362 |
Chicago Cubs | 43 | 44 | 0.49425 |
12.5 | 394 | 394 |
Milwaukee | 42 | 46 | 0.47727 |
14.0 | 392 | 374 |
Pittsburgh | 39 | 48 | 0.44828 |
16.5 | 365 | 403 |
Cincinnati | 35 | 53 | 0.39773 |
21.0 | 434 | 518 |
|
WEST | W | L | PCT | GB |
RS | RA |
San Diego | 48 | 41 | 0.53933 |
0.0 | 406 | 385 |
Arizona | 43 | 47 | 0.47778 |
5.5 | 394 | 479 |
LA Dodgers | 40 | 48 | 0.45455 |
7.5 | 384 | 422 |
San Francisco | 37 | 50 | 0.42529 |
10.0 | 393 | 457 |
Colorado | 31 | 56 | 0.35632 |
16.0 | 389 | 493 |
In the above table, "RS" and "RA" stand for "Runs Scored" and
"Runs Allowed," respectively. More on that later.
From the standings, we see that there isn't any contest in either
the AL or NL Central divisions, that the AL and NL West are, if not
wrapped up, at least uninteresting for the moment, and that the most
exciting baseball is being played in the AL East, closely followed
by the NL East, where the Nationals are surprisingly in first
place.
And "if the playoffs started tomorrow" we'd have Minnesota and
Atlanta as the Wild Cards, and the Yankees would be out of the
playoffs. (Yankees delenda est!)
Now one of the rules of baseball is that to win you have to score
more runs than your opponent. If we look at the above table, you'll
note that the Washington Nationals, though in first place in the NL
East, have been outscored 361-357, even though they are 16 games
over 0.500. What this means is that the Nationals are winning close
games (except this last week) and losing blowouts. This is Not a Good
Thing for Nats fans, because the winner of a one-run game is
determined mostly by luck.
This is quantified by what is known as the the
Pythagorean
Method, which in its simplest form says that the fraction of
games a team should win is related to RS and RA by the formula:
Pct. = RA2 /(RA2 + RS2)
So what would the Pythagorean rule say about this season? Let's
calculate how the standings would look if each team won and lost
according the to above equation:
2005 American League Standings |
EAST | RS | RA | PW | PL |
Pct. | PGB |
Toronto | 428 | 381 | 49.0953 |
38.9047 | 0.55790 | 0.0000 |
NY Yankees | 478 | 431 | 47.4348 |
38.5652 | 0.55157 | 0.6605 |
Boston | 473 | 429 | 47.7338 |
39.2662 | 0.54866 | 0.8615 |
Baltimore | 431 | 409 | 45.7770 |
41.2230 | 0.52617 | 2.8183 |
Tampa Bay | 399 | 553 | 30.4701 |
58.5299 | 0.34236 | 19.1252 |
|
CENTRAL | RS | RA | PW | PL |
Pct. | PGB |
Chicago Sox | 413 | 339 | 51.3816 |
34.6184 | 0.59746 | 0.0000 |
Cleveland | 406 | 365 | 48.6664 |
39.3336 | 0.55303 | 3.7152 |
Minnesota | 396 | 360 | 47.0860 |
38.9140 | 0.54751 | 4.2956 |
Detroit | 387 | 375 | 44.3540 |
41.6460 | 0.51574 | 7.0276 |
Kansas City | 376 | 485 | 32.6598 |
54.3402 | 0.37540 | 19.2218 |
|
WEST | RS | RA | PW | PL |
Pct. | PGB |
LA Angels | 420 | 355 | 51.3291 |
36.6709 | 0.58329 | 0.0000 |
Texas | 476 | 430 | 47.3552 |
38.6448 | 0.55064 | 2.9739 |
Oakland | 400 | 386 | 45.0491 |
41.9509 | 0.51781 | 5.7800 |
Seattle | 377 | 388 | 42.2493 |
44.7507 | 0.48562 | 8.5798 |
|
2005 National League Standings |
EAST | RS | RA | PW | PL |
Pct. | PGB |
Atlanta | 428 | 348 | 53.5788 |
35.4212 | 0.60201 | 0.0000 |
Florida | 383 | 368 | 44.7170 |
41.2830 | 0.51997 | 7.3617 |
NY Mets | 387 | 381 | 44.6875 |
43.3125 | 0.50781 | 8.3913 |
Washington | 357 | 361 | 43.5098 |
44.4902 | 0.49443 | 9.5690 |
Philadelphia | 410 | 417 | 43.7467 |
45.2533 | 0.49154 | 9.8320 |
|
CENTRAL | RS | RA | PW | PL |
Pct. | PGB |
St. Louis | 447 | 340 | 55.7473 |
32.2527 | 0.63349 | 0.0000 |
Milwaukee | 392 | 374 | 46.0667 |
41.9333 | 0.52349 | 9.6805 |
Houston | 365 | 362 | 43.8590 |
43.1410 | 0.50413 | 11.3883 |
Chicago Cubs | 394 | 394 | 43.5000 |
43.5000 | 0.50000 | 11.7473 |
Pittsburgh | 365 | 403 | 39.2058 |
47.7942 | 0.45064 | 16.0414 |
Cincinnati | 434 | 518 | 36.2953 |
51.7047 | 0.41245 | 19.4520 |
|
WEST | RS | RA | PW | PL |
Pct. | PGB |
San Diego | 406 | 385 | 46.8612 |
42.1388 | 0.52653 | 0.0000 |
LA Dodgers | 384 | 422 | 39.8603 |
48.1397 | 0.45296 | 6.5008 |
San Francisco | 393 | 457 | 36.9863 | 50.0137 | 0.42513 | 8.8748 |
Arizona | 394 | 479 | 36.3194 |
53.6806 | 0.40355 | 11.0418 |
Colorado | 389 | 493 | 33.3822 |
53.6178 | 0.38370 | 12.4790 |
Here "PW" and "PL" are the wins and losses as predicted by they
Pythagorean rule, and yes, I've kept way to many decimal places.
(You'll note that the total number of wins in this table isn't equal
to the total number of losses. That's because the Pythagorean rule
is applied on a per-team basis, so a win for one team isn't
necessarily a loss for another team.)
For the Central and Western divisions of both leagues these
results are essentially the same as the actual records. In the
Easts, however, things are drastically different. For one thing,
Toronto is actually a very good ballclub, ten games above 0.500.
The Yankees aren't doing as badly as Mr. Steinbrenner thinks,
they're in contention for the Wild Card. And in the NL, Atlanta is
in its accustomed place, and Washington is at about 0.500.
Of course, what this tells us is that the Pythagorean rule isn't
exact, and will have some discrepancies, especially over only a
portion of a season. But it does suggest that the Nationals have
been playing over their heads, as anyone who watched the games with
the Mets and the Phillies will attest, and that the AL East is going
to be very interesting.
OK, now for the fun part: Let's assume that for the rest of the
year teams will win at their current Pythagorean rate,
but, of course, keep the wins they already have. Then we get the
following standings:
2005 American League Standings |
EAST | W | L | Pct. |
GB |
Boston | 90.1499 | 71.8501 |
0.55648 | 0.0000 |
NY Yankees | 87.9191 | 74.0809 |
0.54271 | 2.2307 |
Baltimore | 86.4629 | 75.5371 |
0.53372 | 3.6869 |
Toronto | 85.2847 | 76.7153 |
0.52645 | 4.8652 |
Tampa Bay | 52.9923 | 109.0077 |
0.32711 | 37.1575 |
|
CENTRAL | W | L | Pct. |
GB |
Chicago Sox | 102.4070 | 59.5930 |
0.63214 | 0.0000 |
Minnesota | 89.6109 | 72.3891 |
0.55315 | 12.7961 |
Cleveland | 87.9241 | 74.0759 |
0.54274 | 14.4829 |
Detroit | 81.1966 | 80.8034 |
0.50121 | 21.2104 |
Kansas City | 58.1550 | 103.8450 |
0.35898 | 44.2520 |
|
WEST | W | L | Pct. |
GB |
LA Angels | 95.1631 | 66.8369 |
0.58743 | 0.0000 |
Texas | 87.8488 | 74.1512 |
0.54228 | 7.3143 |
Oakland | 82.8355 | 79.1645 |
0.51133 | 12.3276 |
Seattle | 75.4218 | 86.5782 |
0.46557 | 19.7413 |
|
2005 National League Standings |
EAST | W | L | Pct. |
GB |
Atlanta | 93.9466 | 68.0534 |
0.57992 | 0.0000 |
Washington | 88.5878 | 73.4122 |
0.54684 | 5.3589 |
Florida | 83.5174 | 78.4826 |
0.51554 | 10.4293 |
NY Mets | 81.5781 | 80.4219 |
0.50357 | 12.3685 |
Philadelphia | 80.8821 | 81.1179 |
0.49927 | 13.0645 |
|
CENTRAL | W | L | Pct. |
GB |
St. Louis | 102.8784 | 59.1216 |
0.63505 | 0.0000 |
Houston | 81.8095 | 80.1905 |
0.50500 | 21.0689 |
Milwaukee | 80.7379 | 81.2621 |
0.49838 | 22.1404 |
Chicago Cubs | 80.5000 | 81.5000 |
0.49691 | 22.3784 |
Pittsburgh | 72.7981 | 89.2019 |
0.44937 | 30.0803 |
Cincinnati | 65.5210 | 96.4790 |
0.40445 | 37.3574 |
|
WEST | W | L | Pct. |
GB |
San Diego | 86.4367 | 75.5633 |
0.53356 | 0.0000 |
LA Dodgers | 73.5189 | 88.4811 |
0.45382 | 12.9178 |
Arizona | 72.0555 | 89.9445 |
0.44479 | 14.3812 |
San Francisco | 68.8848 | 93.1152 |
0.42521 | 17.5519 |
Colorado | 59.7777 | 102.2223 |
0.36900 | 26.6590 |
Based on these predictions, Atlanta will keep its accustomed
first place in the NL East, Washington is a good shot for the Wild
Card, just because they've won so many games in the first half of
the season. And Boston and Minnesota will hold one to the AL East
and the Wild Card to (yeah!) keep the Yankees out of the
postseason.
Of course, these projections are just that, projections, and
aren't a guarantee of anything. Don't even think about using these
to place bets. At the end of the season we'll see how well these
predictions stack up.
* I could not love baseball so much, did I not hate the Yankees more.
Well, things work well when you get help:
A bit ago, I said that it seemed hard to get sound-juicer to rip CDs to MP3 format. But then, I got feedback from Ross Burton, the developer of sound-juicer, who told me to look for the gstreamer-lame plugin to handle MP3 files.
This took a bit of detective work: Mandrake has the plugin under that name in the Penguin Liberation Front archives, but the dependencies to install it weren't compatible with Fedora's shipped version of gstreamer. Eventually, I thought to look in the the list of available RPMs for Fedora Core 4. Doing
$ yum list > yum_files
and then looking at the output, I found the line:
gstreamer-plugins-mp3.i386 0.8.8-0.lvn.1.4 livna
which looked promising. (The program is in the Livna repository, which is I installed with help from Fedora Core Tips & Tricks.) So install the package via:
$ sudo yum install gstreamer-plugins-mp3
and off to the sound-juicer manual to learn how to add MP3 ripping capabilities:
- Run the program gnome-audio-profiles-properties
- Press "New" to get a create a new profile, then "Edit"
- Name it MP3
- In the box labeled "GStreamer Pipeline" enter:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc
- Fill in the "File Extension" box with "mp3"
- Click the "active" check box
- Exit
- Start up sound-juicer
- Under "Edit=>Preferences" go to Output: and select "MP3"
- Rip normally
And this works: except that I get error messages of the type
Couldn't find matching gstreamer tag for track-count
Couldn't find matching gstreamer tag for encoder
Couldn't find matching gstreamer tag for encoder-version
for every track, and at the end sound-juicer hung up and I had to kill it manually. We'll see if this problem persists.
Anyway, thanks again to Ross Burton for helping out.
Apparently, you explain to your wife that the house is going to stink for a few -- years.[*] And prepare your kids to eat tuna steak forever.
This fish was caught in the mouth of the Delaware River. I'm not sure I'd be eating it at all, but, OK, if you want to live dangerously ...
[*] If you didn't know about BugMeNot.com, now you do.
Without a doubt, the most-accessed entry in this blog is one I did on getting the rtsp aka RealPlayer protocol to work with Firefox. Don't believe me? Go to Google, enter "firefox rtsp" in the search bar, and then hit "I'm feeling lucky."
Anyway, as a result of feedback I requested on that post, I've got some new information. You don't have to edit configuration files buried three levels deep to fix this. No, you just have to do a little bit of mouse clicking to change the configuration file from your browser. This post describes the procedure for Mozilla, but the same trick works in Firefox, to wit:
- In the address bar of your browser type the string
about:config
and hit return. You'll get a long confusing list of options. Some are in bold, some aren't, but don't worry about that.
- Right-click anywhere in the display area. A box will appear. Click on the New option.
- Another box will appear. In it, type
network.protocol-handler.app.rtsp
- Yet another box will appear. In it, type
/usr/bin/realplay
or the location of whichever program you want to work.
That's it, RealPlayer should now work. You can check your work here.
Windows Users! I note that some of you have been searching for a solution to this problem as well. The problem seems to be in RealPlayer, not Firefox. If you go to Word_Whore, scroll past the politics, and look at the bottom of the post, you'll see that you should enable Real-Time Streaming Protocol by clicking on "Preferences=>Advanced=>Other Media" in RealPlayer and enable RTSP.
Hope this works, I haven't tried it myself on a Windows machine.
It looks as though Terry Pratchett's next Discworld book, Thud, will come out in October. You can already preorder on both Amazon and Amazon UK.
The US version is cheaper over here, so I'm going to buy it, but I was tempted to get the UK version. Why? Well, look:
|
UK Edition |
|
|
US Edition |
There's no comparison.
Of course, the main purpose of previous entry was to convert ogg formatted sound files to mp3 so that I could burn them to a CD and play them in my car. Why did I need the conversion? Because I was using sound-juicer to rip files from CDs, the juice defaults to ogg for compressed files, and anyway in FC4 there is no support for MP3s in there.
I thought that maybe, just maybe, I could use the same trick on sound-juicer as we did on SoX, but that turns out to be rather difficult. So the best thing to do is follow the advice in that link and use Grip to burn CDs. As long as the lame package is present, Grip will rip CDs to MP3 format if you ask. There is a small bit of configuring required, but it works very well.
Now I just have to re-rip all those CDs.
I mentioned previously that one of the things I wanted to do with Fedora Core 4 was to find an MP3-enabled version of SoX, "the Swiss Army Knife" of sound processing programs. In FC3 I found a SoX+MP3 RPM file online. I still haven't found one for FC4. Fortunately, however, I found a hint for creating such an RPM online (search for "sox").
The procedure is rather simple, if you're willing to rebuild RPM files:
- Set up your account so that you can build RPM files.
- Find a copy of sox-*.src.rpm, where the "*" is the version number. The current version is 12.17.7-3, so you'll look for sox-12.17.7-3.src.rpm. This is available in any mirror of Fedora Core 4, I found it in
ftp://ftp.linux.ncsu.edu/pub/fedora/linux/core/4/SRPMS/
- Copy sox-12.17.7-3.src.rpm to ~/rpmbuild/SRPMS.
- Make sure the packages lame, lame-devel, libmad, and libmad-devel are installed. If not, you'll need to install them. Assuming you followed Fedora Core Tips & Tricks to enable the freshrpms repository, you can do:
sudo yum install libmad libmad-devel lame lame-devel
where sudo allows selected users to run root commands. If you these packages are already installed, yum will let you know about it.
- Now create the RPM. From a terminal window:
$ cd ~/rpmbuild/SRPMS
$ sudo rpmbuild --rebuild sox*
and wait awhile.
- When the program is finished,
$ cd ~/rpmbuild/RPMS/i386
$ ls sox*
There should be three files with RPM extensions: sox*, sox-devel*, and sox-debuginfo*, where "*" hides all the version numbers and stuff. Since these RPMs were compiled with the lame and mad libraries, they contain an MP3 enabled version of SoX.
- Now for the tricky part: we have to get the non-MP3 version of SoX off the system and replace it with the MP3-enabled version. This is difficult because a) the version of SoX on your system is probably the same as the one you just complied, so the rpm database won't recognize your version as an upgrade; and b) some programs depend on SoX to run, so the dependency checker in rpm will generate an error. To get rid of the old SoX, then, we must force the uninstall:
$ rpm -e --nodeps sox sox-devel
assuming that you had sox-devel on your system.
- Now we can install the brand-new version of SoX:
$ sudo rpm -i sox-12.17.7-3.i386.rpm sox-devel-12.17.7-3.i386.rpm
- Now test the program. Run
$ sox -h
At the bottom of the output is a list of supported file formats. If you see "mp3", then SoX works.
- Use SoX as before.
Note that if freshrpms ever updates SoX, you'll lose the MP3 capability and will have to repeat all of this stuff again. :-(
If you're still running Internet Explorer under Windows (and 46% of you reading this are), then you need to take note of yet another security hole in IE.
You have to dig deep down in this advisory to figure out what the problem is. Clicking on the various buttons that hide text, it seems that the bug triggers the Java Virtual Machine to crash IE and "gain the same user rights as the local user," which in Windows usually means administrative privileges.
If you have to use IE, Microsoft has a few suggestions, but the best one is in this Washington Post article: switch browsers.
Of course, Linux & Things recommends Firefox, but there is a wide variety to choose from.
July 6: Microsoft has released a patch for this bug
Science, second only to Nature in prestige, is celebrating its 125th aniversary by publishing a list of the Top 125 Things We Don't Know. Actually, that should be The Top 125 Things We Don't Know But Which We Might Figure Out Soon, but it's still a good list, including things like:
- Are we alone in the Universe?
- What is the Universe made of?
- Why do humans have so few genes?
- How, and where, did life here arise?
- How hot will the greenhouse effect heat up Earth?
- Is Quantum Mechanics all there is?
and much more. Read it.
The Fedora Core 3 version of the vi-clone text editor vim let you use the backspace key to delete the character you just typed, just like an old-style keyboard/typewriter.
In Fedora Core 4 the default is that the backspace key is the same as Ctrl-H, like on an old style teletype. To fix this, it's necessary to edit the ~/.vimrc file, adding the line:
inoremap ^? ^H
Actually, to type that using vim, you press the keys:
inoremap Ctrl-V Ctrl-Shift-? Ctrl-V Ctrl-h
as Ctrl-V means: insert the next key I press literally, dummy.
This makes vim behave the way it should in insert mode: Pressing the backspace key (or Ctrl-H) deletes the character you just typed.
Way back in the past, even before the X window system for Unix-like operating systems was in widespread use, it was realized that sometimes a simple terminal screen wasn't enough.
So it was decided that there should be multiple terminals available to the average user. These days the default number is set at 7. So if, for example, you're logged into terminal #1, and you want to do something completely different, you can hit Alt-F2, and suddenly you're in terminal #2. You can even log into terminal #2 with a different account, so two people can work on the same terminal screen, provided that they don't beat each other silly fighting to press Alt-F1 or Alt-F2.
When X windows was added, the extra terminals were left intact. A good decision, as anyone who has watched a Windows graphic freeze up with no solution except to reboot can attest. In fact, in a default Linux system the X-window graphics module runs in terminal #7. The only difference between systems with X and systems without X is that you need an additional keypress to get to terminal #3, say, pressing Ctrl-Alt-F3 to get to terminal #3 and Ctrl-Alt-F7 to get back to X.
So if a program does hang up your X-windows system, all you have to do is hit, say Ctrl-Alt-F1, log in there, do ps xawu to find the offending process's ID number, and kill it. Most times X will come back by itself, but if it doesn't, you can log in as root and kill X. It will restart when you do Ctrl-Alt-F7.
Except with Fedora Core 4 and my Intel 82845G/GL "integrated" graphics device, it didn't work. Hitting Ctrl-Alt-F1 gave you a blank screen. I think that you could log in and Do Stuff, but I couldn't verify anything, and logging in seemed to freeze the Ctrl-Alt-F7 mechanism to get back to X.
This bug was often reported, but not fixed. Now, thanks to Fedora Weekly News, I find that there is a workaround (see Bug#2 in this link). It seems that the offending software is part of the new X distribution, specifically the library libvgahw.a. Apparently there is something in the new gcc 4 compiler that doesn't like the source code for this library. So the solution is:
Duh, use the library file from Fedora Core 3. The procedure is:
- Download the latest and greatest version of this file from
ftp://people.redhat.com/mharris/libvgahw.a
- Log in as root.
- Copy the downloaded version of the file to
/usr/X11R6/lib/modules/libvgahw.a
you might want to rename the old file first, just in case you need it around.
- Restart X and see what happens. For me, it works.
This isn't the optimal way of doing things, of course. Hopefully a real fix will arrive soon.
I've collected all of the Fedora Core 4 posts from this blog and put them, in chronological order, in (duh):
Working With Fedora Core 4
As in the past, I'll keep adding posts to the file as long as I'm using FC4.
|