0.99999[repeating] don't have a last digit by virtue of being infinitely long
It's last digit is 1 (as is it's first and only digit).
I hate patents as much as anyone else, but: 1) This isn't so obvious, and requires some fairly complex math 2) It is pretty complex (in the way it functions), enough that i would actually consider this patent-worthy.
I would add that at least this patent is not solely a software patent; it has a hardware component.
I thought maybe something had corrupted my Firefox session at the time... I suspected Google was having problems, so I went to E*Trade which was failing to load just about anything except text. I don't see any references to Google or ga.js on E*Trade's pages. But, E*Trade does rely heavily on Akamai servers. If it was a DOS attack, it may have affected Akamai, too (either as the subject of a separate direct attack or an indirect victim of traffic generated by Google's problems).
Both Google and E*Trade recovered at the same time.
As someone who works with both Java and RPG ILE (and sometimes C) on an i5 (or whatever IBM's nom du jour for the system is -- I've lost track), you just end up replacing one problem with another. I've seen plenty of RPG programs run away evaluating expressions against an uninitialized value until it's hard to discover the initial source of the problem. There are times where having a program blow up with a null value makes it a lot easier to find the problem at or close to the source. The whole topic of nulls seems to lead to omphaloskepsis and I can't help but think of the example from Godel, Escher, Bach where a series of unbreakable phonographs continue to be destroyed by a matching series of records that break them. This seems to apply most readily to some other posts in this topic which refer to clearly defining the meaning of null within a particular context (or replacing it with a special Object).
I particulary like the example of "date of death" in a database: it is always unknown until it's known. I think null is the ideal (practical) way of representing it until the date is known. What would make a better substitution? A date before the day of birth? Or would that have to be more than 9 months before the date of birth? And what if the date of birth is not known. Should you enter the last known date alive? What if the person died shortly after the date was entered and you don't find out until later (this one, at least, could be useful in some applications)?
Now, if a programmer calculates the age at death and doesn't check for null, I'd rather see the program blow up right then and there rather than pass something like negative ages through the system. When I first started writing OO programs, I got so frustrated with nulls that I made sure I initialized everything to something that represented the state in a meaningful way. As a result, the programs got overly complex and difficult to debug when checks got missed (that would have caused an error with nulls). When I learned to make judicious use of final fields amd variables where appropriate many of my longstanding issues with nulls went away. I tell the programmers I work with that null is your friend if you use it appropriately.
However, incentives don't work
That is a powerful claim. You did not provide anywhere near enough evidence to back it up.
I don't have time to document the claim, but I did provide a reference for those who are interested (which in turn has footnotes to studies backing up the claims). There has been plenty of research on the subject spanning at least several decades.
Regarding garbage men and electricians, to flip the argument around, would you suggest that you could create a system that would take your average garbage man or electrician and use incentives to make him/her a great teacher, programmer, or (to the point of this topic) doctor? And as for not needing 40 million electricians, do we not have that many because of incentives to do other work or is it simply a result of supply and demand?
Kohn (author of Punished by Rewards does note that the detrimental effect of incentives is more pronounced for tasks that are complex or require creativity, but that even in assembly line work incentives have a mixed record. Here is a link from his site that gives an overview http://www.alfiekohn.org/teaching/edweek/meritpay.htm/. He mostly writes about education, but Punished by Rewards covers a much broader scope (which is why I referenced it).
As my math prof used to say, "The best way to encourage cheating on a test is as follows: start with a very large class. Announce that there is a test today and it will be graded on a curve. Pass out the test. Say you will be back in 30 minutes to collect the test and leave the room."
(I'm now thinking he was a prophet predicting the current financial mess.) An excellent book on this subject is Punished by Rewards .
And, just yesterday, a doctor I know said he finally decided to retire (well past normal retirement age), not because his skills weren't up to par, but because the pressure of being right 100% of the time was too draining -- it's something that is impossible to do, but when you aren't, a person dies. That's what I want in a doctor, someone who cares... and that's not something you can build through incentives.
After Goliath's defeat, giants ceased to command respect. - Freeman Dyson