Friday, June 15, 2007

(More?) ESPN Fantasy Baseball Problems

My ESPN fantasy baseball teams have been doing very well this year. I always check them in the mornings. This morning I noticed something odd with the statistics and standings. Here's a picture of the standings sorted by WHIP:

Quick note if you're not familiar with the WHIP statistic in baseball. It stands for Walks + Hits per Inning Pitched. It's basically how many base runners a pitcher allows each inning on average. Thus a lower value is better.

So you'd expect the team with the lowest WHIP (VENEZUELA ANATOMY with a 1.143) to be at the top of the list when teams are sorted by WHIP. Having the best WHIP, they should also get 10 points contributed to the point totals used for overall standings. Instead, VENEZUELA is in third place and the team with the fourth best WHIP is in first.

Do we have another case of ESPN having problems? Well, sort of. You might have noticed that I was using the Windows Safari browser. There have been a lot of bugs with WinSafari. So it was only prudent for me to load the same page in Firefox:

Now everything looks exactly as it should! Notice that not only have the display orders changed, but the point totals as well. You might notice the my team (Campbell HGH in bold) even has two more points in Firefox than in Safari (89 vs. 87.) I tried the same page in IE7 and Opera, and it displayed correctly (just like Firefox) in both of those as well. I'll give it a try on MacSafari later, too.

So how could using Safari cause such a bizarre "bug" with Safari? Well doing a view source on the ESPN page revealed a lot. Here's a snippet:

This Sortable JavaScript class is the key. It looks like ESPN just passes in the raw data (each team plus it's cumulative statis in each category) to this JavaScript class and then uses JavaScript to do not only the sorting, but also the point calculations (since it is based on the sorting) and overall rankings.

It seems like a reasonable way to render such a page. All sorting and calculations are done client-side. JavaScript is certainly more than capable of handling such tasks. Well, at least it should be. These screen shots suggest that there is a bug with Safari's JavaScript. It would seem like a fairly severe bug, too, since it seems to be related to how it is comparing floating point values. That's just a guess. It could be a lot more subtle than that.

No comments: