You'll need to get serious about UPS/battery backup (or just do everything on laptops) and making backups, etc. You probably think electricity 24/7/52 is normal. My power is up a good 99% of the time--meaning I average about 24*60/100 = 15 minutes of no-electricity a day, with outages lasting from 5 seconds to 5 hours. Not unsupportable, once you accept and plan to deal with it, but a pain in the butt if you don't.
If you presently work in IT, especially in a small shop, talk to your employer. You may be surprised at how receptive they are to the idea.
Don't mention (or at least, don't get specific) about the pay cut right up front
Point out that you'd be glad to have visitors
Look for (and point out) other advantages, such as you providing swing-shift support or...?
Broadband is available in surprising places. It's also unavailable in surprising places. Do your homework.
VOIP
Research the climate for a whole year. Quantify things like "the rainy season" and make sure you know what you are getting into. Some places are really nice for six months out of the year, and...interesting...for the rest
Make sure you like the local food.
If there is a local language other than English, try to learn as much of it as you can.
It takes more discipline to work this way. Lots more.
Explore the tax consequences, work permits, etc. Many places can be sold on the notion that you are a "tourist" who happens to be being paid by your company back home--the idea being that you really are commuting, and aren't "working" in the country--just spending your money there.
--MarkusQ
P.S. My present job (which I'm taking a break from for a few minutes to cruse/.) is in the US. My house is on the side of a (dormant) volcano near the equator.
You seem to want to have the benefits of technology and yet the benefits of no technology at the same time.
You say this as if it's a dumb thing to want. As if it's silly to want cars that don't pollute or pain medicines that don't cause heart attacks.
I humbly suggest that you have picked up the wrong end of the stick. It is silly (and sometimes dangerous) to blindly assume that any downside to technology is just something we need to live with; in many cases it is reasonable and prudent to expect (even insist upon) the benefits of technology without giving up the benefits of no technology.
-- MarkusQ
P.S. (In case anyone cares): I submitted this same story with an almost identical write up (two more links, as I recall) eight hours before this one was submitted. It was rejected.
But if the link is good, why NOT share it with the audience? I believe my first priority is to the readers here. If they would enjoy a link, why should the fact that it came from a user with a negative repution make me not choose the link?
I think a good part of the problem here is the perception (and occasionally documented fact) that other, non-link-whore readers have submitted the same story, sometimes days before, and been rejected. In other cases, the stories the link whores link to are months, maybe years old, or blatantly mis-represented in the summaries.
Thus we aren't really in the situation you describe of getting good, fresh links that we would not otherwise see from these people; when the links are good, there's a fairly good chance that someone else has submitted it too (and that chance would rise if people in general thought their odds of acceptance were better). And when the links aren't that great, the loss isn't either.
I would agree with the GP that there should be some sort of rotating queue or time limit on acceptance. Perhaps putting people who have had a story accepted in the last month at the end of the slush-queue, so that all stories from non-accepted readers get considered first.
--MarkusQ
P.S. Thank you very, very much for this thread. The Beatles Pascal thing isn't a particularly hot issue with me, but I recognize and appreciate the effort that opening a thread like this entails.
The article is about President Bush signing a law making it a crime to post annoying material on a blog, which may be an unconstitutional violation of free speech. The story, in case you need it spelled out, isn't about "crank blogging" as you claim but about Bush's signing a law against it.
In this discussion, in what is arguably a blog people have been complaining about Bush, his treatment of constitutional issues in general and free speech in particular, but you claim it is an offtopic attempt to annoy.
What would you rather we talk about? How nice it is that big brother is going to protect us from annoying ideas? Would that be on-topic enough for you? Or maybe we should all gush about how nice it is that Bush just signs bills and never vetos anything?
How does that obscure the bug in that line? It makes it much more obvious because you know what they're trying to do.
Because (and this has been well tested) people tend to read the comment instead of the code. The high tech tests tracked people's eye movements and such, but you can show the same thing by timing how long it takes people to find bugs, or just quizing them afterwards.
The effect gets more pronounced for larger segments of code. In one example that I recall, half a group of programmers were given a ~10 line binary search routine (with no comments), and asked what it did. The other half were given the same code but with the comments from a shell sort routine ("why"-comments).
When asked what the routine did, the first group was almost always correct, and the second got it wrong more than half the time.
I agree, to a point. "Why" (and "how") comments are far better than "what" comments, but the fundumental problem still applies. Even "why" comments can obscure bugs:
i -= 1000 if i > 1000 # We only have room for (and only need) three digits
Good catch. I keep forgetting that. I guess that's a good demonstration of how "the Big Lie" works; they keep repeating it and after awhile you start going along with it even though you know it's false.
And yet here we are, posting here and in all those articles MarkusQ referenced... free speech is alive and well, believe it or not, and people bitching about it not being free while they freely post their rants here are too oblivious to see the irony.
The fact that some people in some cases are able to express their views does not mean that "free speech is alive and well." The point of free speech is that everybody can do it, without recrimination.
The idea is neat, though such ideas often come with their own problems--specifically, version control and change management, when the models can't be easily treated as flat text.
Another interesting trick I've seen prototyped (but not in use) is code animation; the documentation consists of a collection of sample cases (which double as test cases) and a specification of what to show (and how to show it). To see how the code works, the tool animated the samples using the actually code. IIRC the examples included a sort, a threaded message passing application, and a cryptography (or perhaps it was data compression) routine. The key point again being that the programmer was looking the same thing as the computer.
There is one problem with comments, but it is a show stopper as far as I'm concerned.
Computers never read the comments, while programmers tend to read comments rather than code. The first part is obvious, and the second is easy to demonstrate. Together, they are a recipe for disaster.
Uncommented code has a number of disadvantages, but the overriding (IMHO) advantage is that both the computer and the programmer are dealing with the same thing, the code. On the other hand, with commented code they are dealing with two similar but distinct things, that are related in exactly the same way as a fine-print contract (the code) and the car salesman's verbal promises (the comments). When push comes to shove, the salesman's words mean nothing and the contract is what matters. So why even listen to the salesman?
-- MarkusQ
P.S. This is not to say that I never comment code; only that I do so sparingly and never trust the comments.
Hmmm. You may be right, but I seem to recall being told in some class or another that a randomly transported chunk of you (or a cancer started from your cells) would be rejected due to various incompatibilities of a very mundane nature; physical stresses, unsupportable demands on blood supply, etc. are sufficient (IIRC) to start a cascade leading to rejection.
I also like the cancer analogy better since it is in fact our own cells (our "leaders") that are causing the problem; and part of the reason we aren't reacting is that we recognize them as "our own" even as they screw us over.
"a set of bundled libraries designed to be API compatible"
"designed to mimmick the behaviour of another piece of hardware or software in order to achieve the same functionality"
What's the difference?
Aren't the libraries bundled with WINE written to mimmick the responses of the equivalent Windows APIs? Sounds like emulation to me.
I've always assumed that they were making the first wife / second wife distinction.
Your second wife may provide all the services that you first wife did ("Please pass the salt" gets the salt handed to you just as before) but that is only an implementation of the same API--it doesn't mean that your second wife is "emulating" your first wife.
If, on the other hand, your second wife discovers that your first wife used to have some bizarre behaviour (say, she would occasionally wake up screaming "Now Dasher! now, Dancer! now Prancer and Vixen! On, Comet! on, Cupid!" etc. in an overly excited voice even when it was nowhere near christmas) and your second wife decided to start doing it too solely because it's what your first wife did, that would be emulation.
To give a less whimsical example: a browser such as Opera isn't "emulating" Firefox just because they both render HTML, support javascript, etc. Only if the Opera folks were to add a "Firefox quirks mode" that also attempted to duplicate all the overt behaviour of Firefox would they be "emulating" it. (And to be "simulating" they would have to be duplicating the overt behaviour by virtue of having in some sense the "same" internal structure.)
On the one hand, I am appalled at the erosion of our civil liberties and the almost-sedated non-response from the public. It reminds me of the way in which cancer kills you (the body ignores it when it's small, and as it only grows a little bit each day, the problem is put off until it's too late; a tumor that would have been actively fought if implanted full grown kills an otherwise health person because it's never that much worse than it was the day before).
But on the other hand, I'd love to see someone try to decipher my cell phone calls:
Me: Could you repeat that? Them:If...the...ine when I...ick. Me: No! Don't click on that! We need to log the error message. Them:Hog...any..sausage? Me:Not sausage. Message. Error message. Error message. Error message. Them:...ot an err...hat about...age? Me:Write it down. Write it down. Write it down. Them:Could you...that?...other...erver room...ception in here...od damn fans...! Me:Write it down. Write it down. Write it down. Them:...I just read...you? Zero zero...eff as in...apple, zero, ze...two. Got that?
Hey, maybe I could just ask the NSA for a cleaned up transcript!
The source you cite (and, it appears, your arguments, at least implicitly) are talking about how to deal with repeated rounding in calculations with a single guard digit. As the Knuth paper clearly states in the introduction to the defense of round-ties-to-even:
When floating-point operations are done with a guard digit, they are not as accurate as if they were computed exactly then rounded to the nearest floating-point number.
On the more general case, the only mention corresponds to my position:
...double-rounding only produces an incorrectly rounded result when the second rounding is determined by the round-ties-to-even rule...
For what it is worth, I agree with your points (and, of course, with Knuth) when it comes to things like dealing with the about-to-be-dropped bits in FP hardware--the case of a single binary guard bit, computed as he describes, is isomorphic with that of money; the data sample is strongly biased towards exact halves (the guard bit=1) and, since this rounding is only/always being done on the least significant bit of a floating point value, we are more concerned with fairness (see the example that he cites) than with accuracy (e.g., the second quote) which can be dealt with (bounded) by other means.
Please read the next-to-the-last paragraph of the post to which you were responding. And it might help if you pause to think a little before saying that something is "bollocks".
--MarkusQ
Re:Only with money in fractions
on
Rounding Algorithms
·
· Score: 3, Informative
I think you might be mistaken. Round to the nearest even is statisticly significantly more accurate. Rounding halves up does nothing for accuracy as you seem to imply. Large data sets of any type of data will be biased if rounding halves up, whereas rounding to the nearest even is ever more accurate with each datapoint. Your statement about rounding to even being bad makes me think you haven't fully grasped the underlying concept, I've never seen rounding halves up used for anything in a major environment simply because it is almost always the wrong thing to use.
On the contrary, I understand and have worked with this sort of thing for years. I know whereof I speak, and the situation is exactly opposite of what you claim. Specifically:
Round to the nearest even is statistically ssignificantly less accurate.
Rounding halves up is significantly more accurate.
Large data sets of almost any type of data will be biased if rounding to the nearest even, whereas rounding halves up is ever more accurate with each data point.
Note that this is basically your list, with the claims reversed. So we disagree totally. Now let me explain why I am correct. First, let's review what you do when you round to the nearest integer (without loss of generality; rounding to the nearest 1/10th, or even 1/137th, is isomorphic).
You start with a number which has a (potentially infinite) string of digits to the right of the decimal place
You drop (truncate) all but one of the unwanted digits.
You conditionally change the lowest order digit you intend to keep
For "round up" you add one to it if the remaining unwanted digit is 5,6,7,8, or 9
For "round to nearest even" you add one to it if the remaining unwanted digit is 6,7,8, or 9, or if it is odd and the remaining unwanted digit is five.
You drop the remaining unwanted digit
Note that the only difference in results between these rules comes from numbers where:
The last digit to be kept is even and
The first of the digits to be disposed of is 5
For example, the number 4.56106531 would be rounded to 4 in the "nearest even" case or to 5 in the "round up" case But clearly, the "nearest even" result is less accurate, and introduces a significant bias. 4.56106531 is closer to 5 than to 4, and should be rounded up. Always.
At this point, you may object that you aren't planning on truncating before you apply the rule (or, equivalently, you only do the even odd dance on "exact" halves). But how did you get an "exact" half? Unless you have infinite precision floating point hardware, less significant bits fell off the bottom of your number; unless they were all zero your "exact half" is the result of truncation and the above logic still applies.
The only common case where it doesn't apply is (as I stated originally) when dealing with money, where 1) your sample is biased to contain "exact halves" and 2) it is more important to be "fair" than it is to be accurate. This, in any case, is more of a convention than a fact of mathematics; we agree that money is tracted to a certain point and ignore the half pennies owed and the $0.00004537531 of interest due on them; if we didn't even money would not be an exception to the logic above.
-- MarkusQ
Re:Only with money in fractions
on
Rounding Algorithms
·
· Score: 4, Insightful
For illustration, suppose we use a floating-point format with a 10-bit mantissa. For a fixed exponent (say 0), this can represent values from 1.0 to 1 1023/1024, in 1/1024 increments. The AVERAGE of these UNROUNDED values is 1 1023/2048, which is LESS THAN 1.5. However, if all these values are rounded (with 0.5 rounding up), the AVERAGE of the ROUNDED values will be EQUAL TO 1.5, an average increase of 1/2048. Thus, this type of rounding introduces a measurable positive bias into the arithmetic.
No, the "bias" came from your choice of data (and your unrealistic expectation that the average of a set of rounded values would equal the average of the unrounded set).
Such examples are as easy to construct as they are misleading. Suppose we instead take the values {0.2, 0.3, and 0.5}. Their average is 1/3, and if we round them ".5 up" we wind up with {0,0,1} with exactly the same average. On the other hand, if we round them with ".5 to even" we wind up with {0,0,0} with the average of zero and an "error" (by your metric) of 100%.
--MarkusQ
Only with money in fractions
on
Rounding Algorithms
·
· Score: 4, Informative
"Bankers" rounding is only appropriate in a rather restricted range of problems; specifically, where you are more worried about "fairness" than about accuracy, and have a data set that is already biased towards containing exact halves (generally because you've already rounded it previously).
For pretty much all other cases it is broken, wrong, bad, very bad, and misguided. It is a kludge cut from the same cloth as using red and black ink, parenthesis, or location on the page (and all the permutations thereof) to indicate the sign of a number. Do not try to do any sort of scientific calculations, or engineering, or anything else that matters and round in this way.
Why? Because contrary to what some people think, there is no systematic bias in always rounding up. There are exactly as many values that will be rounded down as will be rounded up if you always round exact halves up. I think the trap that people fall into is forgetting that x.000... rounds down (they think of it as somehow "not rounding").
My wife doesn't read Slashdot, but she sure as hell knows when I'm on it - even from another room. Its like she's got detatchable eyes and she leaves them in the office or something - its crazy. I'll be reading and I'll hear "You've been on Slashdot for long enough!" from the living room... I don't get it.
Which one of you maintains your home network?
Slashdot Mirror
I forgot in my list:
You'll need to get serious about UPS/battery backup (or just do everything on laptops) and making backups, etc. You probably think electricity 24/7/52 is normal. My power is up a good 99% of the time--meaning I average about 24*60/100 = 15 minutes of no-electricity a day, with outages lasting from 5 seconds to 5 hours. Not unsupportable, once you accept and plan to deal with it, but a pain in the butt if you don't.
--MarkusQ
I highly recommend it. A few thoughts:
--MarkusQ
P.S. My present job (which I'm taking a break from for a few minutes to cruse /.) is in the US. My house is on the side of a (dormant) volcano near the equator.
Yeah, I'd say you're on to a good idea.
You seem to want to have the benefits of technology and yet the benefits of no technology at the same time.
You say this as if it's a dumb thing to want. As if it's silly to want cars that don't pollute or pain medicines that don't cause heart attacks.
I humbly suggest that you have picked up the wrong end of the stick. It is silly (and sometimes dangerous) to blindly assume that any downside to technology is just something we need to live with; in many cases it is reasonable and prudent to expect (even insist upon) the benefits of technology without giving up the benefits of no technology.
-- MarkusQ
P.S. (In case anyone cares): I submitted this same story with an almost identical write up (two more links, as I recall) eight hours before this one was submitted. It was rejected.
But if the link is good, why NOT share it with the audience? I believe my first priority is to the readers here. If they would enjoy a link, why should the fact that it came from a user with a negative repution make me not choose the link?
I think a good part of the problem here is the perception (and occasionally documented fact) that other, non-link-whore readers have submitted the same story, sometimes days before, and been rejected. In other cases, the stories the link whores link to are months, maybe years old, or blatantly mis-represented in the summaries.
Thus we aren't really in the situation you describe of getting good, fresh links that we would not otherwise see from these people; when the links are good, there's a fairly good chance that someone else has submitted it too (and that chance would rise if people in general thought their odds of acceptance were better). And when the links aren't that great, the loss isn't either.
I would agree with the GP that there should be some sort of rotating queue or time limit on acceptance. Perhaps putting people who have had a story accepted in the last month at the end of the slush-queue, so that all stories from non-accepted readers get considered first.
--MarkusQ
P.S. Thank you very, very much for this thread. The Beatles Pascal thing isn't a particularly hot issue with me, but I recognize and appreciate the effort that opening a thread like this entails.
The article is about President Bush signing a law making it a crime to post annoying material on a blog, which may be an unconstitutional violation of free speech. The story, in case you need it spelled out, isn't about "crank blogging" as you claim but about Bush's signing a law against it.
In this discussion, in what is arguably a blog people have been complaining about Bush, his treatment of constitutional issues in general and free speech in particular, but you claim it is an offtopic attempt to annoy.
What would you rather we talk about? How nice it is that big brother is going to protect us from annoying ideas? Would that be on-topic enough for you? Or maybe we should all gush about how nice it is that Bush just signs bills and never vetos anything?
--MarkusQ
How does that obscure the bug in that line? It makes it much more obvious because you know what they're trying to do.
Because (and this has been well tested) people tend to read the comment instead of the code. The high tech tests tracked people's eye movements and such, but you can show the same thing by timing how long it takes people to find bugs, or just quizing them afterwards.
The effect gets more pronounced for larger segments of code. In one example that I recall, half a group of programmers were given a ~10 line binary search routine (with no comments), and asked what it did. The other half were given the same code but with the comments from a shell sort routine ("why"-comments).
When asked what the routine did, the first group was almost always correct, and the second got it wrong more than half the time.
--MarkusQ
I agree, to a point. "Why" (and "how") comments are far better than "what" comments, but the fundumental problem still applies. Even "why" comments can obscure bugs:--MarkusQ
We are not at war.
Good catch. I keep forgetting that. I guess that's a good demonstration of how "the Big Lie" works; they keep repeating it and after awhile you start going along with it even though you know it's false.
--MarkusQ
And yet here we are, posting here and in all those articles MarkusQ referenced... free speech is alive and well, believe it or not, and people bitching about it not being free while they freely post their rants here are too oblivious to see the irony.
The fact that some people in some cases are able to express their views does not mean that "free speech is alive and well." The point of free speech is that everybody can do it, without recrimination.
-- MarkusQ
The idea is neat, though such ideas often come with their own problems--specifically, version control and change management, when the models can't be easily treated as flat text.
Another interesting trick I've seen prototyped (but not in use) is code animation; the documentation consists of a collection of sample cases (which double as test cases) and a specification of what to show (and how to show it). To see how the code works, the tool animated the samples using the actually code. IIRC the examples included a sort, a threaded message passing application, and a cryptography (or perhaps it was data compression) routine. The key point again being that the programmer was looking the same thing as the computer.
--MarkusQ
Good catch. My spelling goes downhill when my blood pressure goes up.
--MarkusQ
President Bush sucks
If only it were true. He seems to be able to lie us into a war, shred the constitution, hand out important government jobs like stocking stuffers to incompetent nitwits, give aid and comfort to our enemies in time of war, suppress political descent, and run up enormous debt in our name to enrich his backers, and there doesn't seem to be anything the hand wringing "opposition" party can do to stop him.
If only he sucked , he's be out of there so fast his head would spin.
--MarkusQ
There is one problem with comments, but it is a show stopper as far as I'm concerned.
Computers never read the comments, while programmers tend to read comments rather than code. The first part is obvious, and the second is easy to demonstrate. Together, they are a recipe for disaster.
Uncommented code has a number of disadvantages, but the overriding (IMHO) advantage is that both the computer and the programmer are dealing with the same thing, the code. On the other hand, with commented code they are dealing with two similar but distinct things, that are related in exactly the same way as a fine-print contract (the code) and the car salesman's verbal promises (the comments). When push comes to shove, the salesman's words mean nothing and the contract is what matters. So why even listen to the salesman?
-- MarkusQ
P.S. This is not to say that I never comment code; only that I do so sparingly and never trust the comments.
Still, it would be a good idea for your computer to guess when you're about to become mad at it.
I have an easy filter they could implement to predict this.
Just grep for /Roland Piquepaille/ in the text queued up for rendering.
-- MarkusQ
Hmmm. You may be right, but I seem to recall being told in some class or another that a randomly transported chunk of you (or a cancer started from your cells) would be rejected due to various incompatibilities of a very mundane nature; physical stresses, unsupportable demands on blood supply, etc. are sufficient (IIRC) to start a cascade leading to rejection.
I also like the cancer analogy better since it is in fact our own cells (our "leaders") that are causing the problem; and part of the reason we aren't reacting is that we recognize them as "our own" even as they screw us over.
--MarkusQ
I've always assumed that they were making the first wife / second wife distinction.
Your second wife may provide all the services that you first wife did ("Please pass the salt" gets the salt handed to you just as before) but that is only an implementation of the same API--it doesn't mean that your second wife is "emulating" your first wife.
If, on the other hand, your second wife discovers that your first wife used to have some bizarre behaviour (say, she would occasionally wake up screaming "Now Dasher! now, Dancer! now Prancer and Vixen! On, Comet! on, Cupid!" etc. in an overly excited voice even when it was nowhere near christmas) and your second wife decided to start doing it too solely because it's what your first wife did, that would be emulation.
To give a less whimsical example: a browser such as Opera isn't "emulating" Firefox just because they both render HTML, support javascript, etc. Only if the Opera folks were to add a "Firefox quirks mode" that also attempted to duplicate all the overt behaviour of Firefox would they be "emulating" it. (And to be "simulating" they would have to be duplicating the overt behaviour by virtue of having in some sense the "same" internal structure.)
-- MarkusQ
On the one hand, I am appalled at the erosion of our civil liberties and the almost-sedated non-response from the public. It reminds me of the way in which cancer kills you (the body ignores it when it's small, and as it only grows a little bit each day, the problem is put off until it's too late; a tumor that would have been actively fought if implanted full grown kills an otherwise health person because it's never that much worse than it was the day before).
But on the other hand, I'd love to see someone try to decipher my cell phone calls:
Me: Could you repeat that? ...other...erver room...ception in here...od damn fans...!
Them:If...the...ine when I...ick.
Me: No! Don't click on that! We need to log the error message.
Them:Hog...any..sausage?
Me:Not sausage. Message. Error message. Error message. Error message.
Them:...ot an err...hat about...age?
Me:Write it down. Write it down. Write it down.
Them:Could you...that?
Me:Write it down. Write it down. Write it down.
Them:...I just read...you? Zero zero...eff as in...apple, zero, ze...two. Got that?
Hey, maybe I could just ask the NSA for a cleaned up transcript!
--MarkusQ
The source you cite (and, it appears, your arguments, at least implicitly) are talking about how to deal with repeated rounding in calculations with a single guard digit. As the Knuth paper clearly states in the introduction to the defense of round-ties-to-even: On the more general case, the only mention corresponds to my position: For what it is worth, I agree with your points (and, of course, with Knuth) when it comes to things like dealing with the about-to-be-dropped bits in FP hardware--the case of a single binary guard bit, computed as he describes, is isomorphic with that of money; the data sample is strongly biased towards exact halves (the guard bit=1) and, since this rounding is only/always being done on the least significant bit of a floating point value, we are more concerned with fairness (see the example that he cites) than with accuracy (e.g., the second quote) which can be dealt with (bounded) by other means.
-- MarkusQ
--MarkusQ
I think you might be mistaken. Round to the nearest even is statisticly significantly more accurate. Rounding halves up does nothing for accuracy as you seem to imply. Large data sets of any type of data will be biased if rounding halves up, whereas rounding to the nearest even is ever more accurate with each datapoint. Your statement about rounding to even being bad makes me think you haven't fully grasped the underlying concept, I've never seen rounding halves up used for anything in a major environment simply because it is almost always the wrong thing to use.
On the contrary, I understand and have worked with this sort of thing for years. I know whereof I speak, and the situation is exactly opposite of what you claim. Specifically:
Note that this is basically your list, with the claims reversed. So we disagree totally. Now let me explain why I am correct. First, let's review what you do when you round to the nearest integer (without loss of generality; rounding to the nearest 1/10th, or even 1/137th, is isomorphic).
Note that the only difference in results between these rules comes from numbers where:
For example, the number 4.56106531 would be rounded to 4 in the "nearest even" case or to 5 in the "round up" case But clearly, the "nearest even" result is less accurate, and introduces a significant bias. 4.56106531 is closer to 5 than to 4, and should be rounded up. Always.
At this point, you may object that you aren't planning on truncating before you apply the rule (or, equivalently, you only do the even odd dance on "exact" halves). But how did you get an "exact" half? Unless you have infinite precision floating point hardware, less significant bits fell off the bottom of your number; unless they were all zero your "exact half" is the result of truncation and the above logic still applies.
The only common case where it doesn't apply is (as I stated originally) when dealing with money, where 1) your sample is biased to contain "exact halves" and 2) it is more important to be "fair" than it is to be accurate. This, in any case, is more of a convention than a fact of mathematics; we agree that money is tracted to a certain point and ignore the half pennies owed and the $0.00004537531 of interest due on them; if we didn't even money would not be an exception to the logic above.
-- MarkusQ
For illustration, suppose we use a floating-point format with a 10-bit mantissa. For a fixed exponent (say 0), this can represent values from 1.0 to 1 1023/1024, in 1/1024 increments. The AVERAGE of these UNROUNDED values is 1 1023/2048, which is LESS THAN 1.5. However, if all these values are rounded (with 0.5 rounding up), the AVERAGE of the ROUNDED values will be EQUAL TO 1.5, an average increase of 1/2048. Thus, this type of rounding introduces a measurable positive bias into the arithmetic.
No, the "bias" came from your choice of data (and your unrealistic expectation that the average of a set of rounded values would equal the average of the unrounded set).
Such examples are as easy to construct as they are misleading. Suppose we instead take the values {0.2, 0.3, and 0.5}. Their average is 1/3, and if we round them ".5 up" we wind up with {0,0,1} with exactly the same average. On the other hand, if we round them with ".5 to even" we wind up with {0,0,0} with the average of zero and an "error" (by your metric) of 100%.
--MarkusQ
For pretty much all other cases it is broken, wrong, bad, very bad, and misguided. It is a kludge cut from the same cloth as using red and black ink, parenthesis, or location on the page (and all the permutations thereof) to indicate the sign of a number. Do not try to do any sort of scientific calculations, or engineering, or anything else that matters and round in this way.
Why? Because contrary to what some people think, there is no systematic bias in always rounding up. There are exactly as many values that will be rounded down as will be rounded up if you always round exact halves up. I think the trap that people fall into is forgetting that x.000... rounds down (they think of it as somehow "not rounding").
--MarkusQ
the characteristics of animal shape and locomotion are predictable from physics
They must be using real animals only. I know for a fact that the Pegasus's shape (to cite just one famous example) isn't predictable from physics.
--MarkusQ
I'm sorry for the Chinese, I think the pornographers are going to kick their ass.
I think you misspelled "lick," unless that's in the members-only section.
--MarkusQ
My wife doesn't read Slashdot, but she sure as hell knows when I'm on it - even from another room. Its like she's got detatchable eyes and she leaves them in the office or something - its crazy. I'll be reading and I'll hear "You've been on Slashdot for long enough!" from the living room... I don't get it. Which one of you maintains your home network?
--MarkusQ