You don't have to bring up examples of functions that take NULL to mean "don't care", I know of some. time() being the first one that springs to mind
Wow, I was actually thinking something along those lines, but I didn't think it was something that simple. I checked out stuff like a couple of the itimer functions, gettimeofday, but didn't see it.
I would still prefer some syntax that indicates that a value is being passed by reference.
I would too, with the caveat that it not be required at call sites for functions that take const references. (The latter I think is necessary because there are a lot of places where it's passed by const reference and it's not logically a reference parameter. In fact, I think if you required notices even at those points you'd be at the C/pointer situation, which, as I said, is hardly better. The downside is it wouldn't be perfect, as there are still mutable members, casting away const, etc.)
For instance, I'm a fan of the C# method:
void swap(ref int a, ref int b) { int t = a; a=b; b=c; }
then
int one, two;...
swap(ref one, ref two);
It even goes further with allowing you to specify just out parameters:
void assignFive(out int a) { a = 5; }
then
int one;
assignFive(one);
(Don't ask me why you'd write that, it was just the easiest demo of an out parameter I could think of.)
The latter has the benefit over making the parameter ref that the compiler would complain that you're using an uninitialized variable in the call to assignFive otherwise. (But now it would also complain if assignFive tried to use a before assigning to it, as it assumes that out parameters can be uninitialized.)
But it doesn't make it nigh impossible for the object to be invalid. Checking for input validity is not something you can skip no matter your passing method. And checking for non null is simple:
Ah, here's another point that I didn't think of before:
You're all talking about how passing by pointers is good for readability because it enforces documentation at the call site that it can be modified.
Here's one way, related to the null pointer point (no pun intended), in which passing by pointer hurts the self documentation of the code. It's not uncommon to find functions that can accept a null pointer as an argument. A lot of unix calls in particular will both set a non-null pointer argument to and return a value. (I can't think of any off the top of my head, but if you want I'll find one.) Having a reference parameter documents from the syntax of the code (the strongest documentation you can have) that null values are prohibited; having a pointer does not.
In other words, the issue of the validity of a null value goes beyond just checking for improper parameter values.
I've seen advice that addresses this point, and recommends the use of reference parameters for situations in which null is invalid and pointers for when null is valid for this very reason. Sutter and Alexandrescu give this advice for when to pass by pointer and when to pass by reference:
Prefer passing by (smart) pointer if the argument is optional (so callers can pass null as a "not available" or "don't care" value [the issue discussed above] or if the function stores a copy of the pointer or otherwise manipulates ownership of the argument
Prefer passing by reference if the argument is required and the function won't store a pointer to it or otherwise affect its ownership.
But it doesn't make it nigh impossible for the object to be invalid. Checking for input validity is not something you can skip no matter your passing method.
If the input isn't valid, nothing you can legally do will find it.
And even so, it's one less thing that you have to test for.
And checking for non null is simple [then an assertation]
You just moved to runtime what the compiler could have enforced (as much as anything can be) for you at compile time.
If the best use for references is to avoid a one line check at the expense of making the calling code more difficult to understand, then I'd say there's no use for references at all.
It also symplifies syntax in the called function. There are other places where references are "necessary" though (for instance the return value of vector::operator[]), so they couldn't be removed from the language entirely even if you didn't allow them in argument lists.
(And I posted another comment about how I don't find even the readability argument in favor of passing by pointers unconvincing.)
The rule I use, which I've heard Bjarne himself utter while simultaneously destroying with the stream operators, is that the operator should have an obvious meaning analagous to the built-in operator. E.g. adding strings and complex numbers both have obvious expected meanings.
It's good rule, and one reason why I think that the proposed someVector += 5, 6; syntax is absolutely awful.
However, I think that an exception can be made for the shifting operators and input and output partly because of the very long history that they have, and partly because (to my knowledge) the shifting operators were pretty much invented for programming. +, *, etc. all have meanings we've seen since kindergarden or before; << doesn't. It makes sense, but then it also sort of makes sense for stream operations.
That's why I still use printf().
And lose flexability and enforced type safety?;-)
(I know this is a war I can't win, but: I think that printf syntax often looks nicer, but it's harder to learn, a lot harder to understand if you don't know it, and isn't typesafe. You also have issues with how you output with classes because you can't make the printf formatting string accept new switches, and couldn't pass a non-POD type anyway. There was a language extension proposed to allow typesafe, variable length argument lists, which would have fixed some of those problems. I haven't heard anything about it for a long time though (I didn't necessarily RTFA now though), so I doubt it will come to fruition. That would have been nice though.)
However, the implementations I have used have all treated a vector of booleans as a resizable bit field.
I can't easily check to see if what I'm using does, so I'll take your word for it.
At any rate, resizable bit arrays still don't (imho) deserve special status in a language. They should be possible, but not necessarily part of the language proper
Agreed. If the standard committee drops the bool specialization (unlikely), they should add a resizable bit array. If they don't, they should consider mandating the space optimization. (It's at the cost of speed though, so who knows. Hard to say.)
C's style of things hardly makes things any better. If I have a function foo(some struct* x), why am I passing x by pointer? Is it just to save time and duplicating x on the stack, or is it because foo is actually going to change it? You can't tell that from looking at the call site either, even if C had const or in the extensions where it does. My experience is that most of the time most objects are passed by reference or pointer. That means that loss of readability from reference parameters in C++ really only show up when you're dealing with primitive types.
Not only that, but I just thought of something else:
If you don't have const in C, the situation is actually better with C++, references, and const, because the almost universal idiom is to pass by const reference to save space. If you see a reference parameter that isn't const, it's at least somewhat safe to assume it will be changed. (The other main possibility is that people were lazy with classes and didn't make them const correct, forcing them to use non constants.) You can tell if a parameter is const by the function signature. Not as good as the call site, but still better than in C where you can only tell from the method implementation (or documentation) that a parameter isn't changed.
Of course you need the entire source, instead of just the header files, but that's a minor inconvinience in my opinion.
Depends. If you're releasing a commercial (to the naysayers, fine, a proprietary) library, you could very well not want to do that.
It's not a total wash of the idea because you could still support separate files (in fact, you'd very nearly have to with the code base that's out there).
That's fine and dandy, but the fact remains that pass by reference makes it more difficult to understand code. There is no syntax at the place the function is called that indicates that it is pass by pointer (which is what pass by reference really is in C++) instead of by value, and this is by no means an insignificant difference.
I'll agree to some extent, but I have two things that I feel need to be added:
1. Pass by reference doesn't make it difficult to understand code, the lack of syntax at the call site does. For instance, C# allows reference parameters, but you need to specify that at the call site too.
2. C's style of things hardly makes things any better. If I have a function foo(some struct* x), why am I passing x by pointer? Is it just to save time and duplicating x on the stack, or is it because foo is actually going to change it? You can't tell that from looking at the call site either, even if C had const or in the extensions where it does. My experience is that most of the time most objects are passed by reference or pointer. That means that loss of readability from reference parameters in C++ really only show up when you're dealing with primitive types.
Not a joke, a research project. Thus, Stroustrup's willingness to include any "feature" that someone suggests: "Oh sure, we'll put that in and see how it works out."
Neither of these statements is true. He was at Bell Labs, but in no ways did he intend C++ to be a research project. He wrote it to solve real-world programming problems, to make real-world programming easier. How much he succeeded you can argue, but he did intend for it to become as widly used as it is.
As to your second point, follow the other fellow's advice and read D&E sometime.
It doesn't matter how fast the fish swims; that will only change how fast the water moves in relative to how long ago it was there. It will still flow back nearly instantly. Mole holes can stick around for years.
If you were to calculate the motion of a pitched baseball under Newtoinian and Einsteinin phsyics, the difference would be too small to measure, and for all practical purposes, they'd give exactly the same answer.
I'll agree that if you're using physical laws to do calculations and you use Einstein instead of Newton to calculate the flight of a baseball, you're doing way too much work.
But that doesn't make Newton right.
I'm gonna quote Feynman because he expresses my feelings very well. This is from Six Easy Pieces (p3 in my copy; you can also find it in the "atoms in motion" chapter of Lectures), but I should say that this is a thought I've had long before reading this:
We said that the laws of nature are approximate: that we first find the "wrong" ones, and then we find the "right" ones..... For example, the mass of an object never seems to change: a spinning top has the same weight as a still one. So a "law" was invented: mass is constant, independent of speed. That "law" is now found to be incorrect. Mass is found to increase with velocity, but appreciable increases require velocities near that of light. A true law is: if an object moves with a speed of less than one hundred miles per second the mass is constant to within one part in a million. In some such approximate form this is a correct law. So in practice one might think that the new law makes no significant difference. Well, yes and no. For ordinary speeds we can certainly forget it and use the simple constant-mass law as a good approximation. But for high speeds we are wrong, and the higher the speed, the more wrong we are.
Finally, and most interesting, philosophically we are completely wrong with the approximate law. Our entire picture of the world has to be altered even though the mass changes by only a little bit. This is a very peculiar thing about the philosophy, or the ideas, behind the laws. Even a very small effect sometimes requires profound changes in our ideas.
Now you could view science as a much more mature study... there may still be a lot of room for new discoveries but they are not the easy ones that can be expressed with 5 characters like "e=mc2"
Are you really that sure about that?
I'll agree that the chances of another discovery where such a profound statement (that energy and mass are convertible) can be made in so simple a form is unlikely, but by no means is it impossible. I have a suspicion that if you went to 1904 and asked someone if such a statement could be made so simply you would have gotten a reaction similar to yours.
Another possible influence on this may be that at Einstein's time, there was a world war going on.
Keep in mind that special relativity was 1905 and general 1915. At the time he published his two biggest theories (or at least the most well known, even among people who have done some physics studying) he wasn't yet anywhere near the Manhattan Project or anything like that.
It's not just a matter of that Einstein is more recent, it's that Newton is wrong. Even though from my understanding Newton's work was a much bigger jump at the time than was Einstein's at his (which is somewhat of a biased view as just yesterday I read most of Feynman's "Six Not-So-Easy Pieces" so am more familiar with the working leading up to special relativity, while I don't know much about the giants Newton stood upon), the fact that its Einstein's, and not Newton's, that marks our best understanding of the universe I think is a major factor in Einstein's fame.
This is, of course, related to the fact that Einstein is more recent, but still deserves mention.
(And on a side note, let me just say that learning about aspects of relativity, even as much as I can, has convinced me that if there is a god, He has quite the sense of humor and creativity.)
It does seem like there's a qualitative difference in how they move. You yourself argued in other threads that the motions of a bird and fish are different than a mole, because the latter digs. I would add to your distinction the observation that the holes left behind by a mole are permanent in the short term, while the "holes" behind the bird and the fish refill pretty much instantly.
You can take this point further and say that once a mole digs out a nice house, almost all his motion is constrained to the tunnels that are already dug. So while he has the capability to exercise full 3D motion, the natural state is that he does not. And more than that, even if he does keep digging just so that he can prove that he can go in any direction, he'll eventually make a cavern. At that point his 3D control has been lost, as he can't go up without refilling his home.
None of these apply to the bird or the fish. Their motion is, to a large extent, not constrained. Look at the paths of either; they don't go in the same motion. There's no loss of control once they have flown a particular route, nor is there any factor to make them fly that exact route again. And the constraints that the DO face, for instance trees in the case of a bird, have parallels in the mole universe: they can't dig through rocks for instance.
I'm not trying to argue against the specific point which is that Apple would have the same problems as Dell et. al. if they were larger (I think that if their product quality remained the same they wouldn't have the problems), but you can't necessarily just scale up what you already have. Increased numbers of people mean increased numbers of people who Apple'd need to coordinate between.
As a concrete example, think of what happens when, in 6 months, Apple releases the new iFancyToy. They need to provide support for the iFancyToy. In scenario A, Apple sells the same number of units they are selling now. In scenario B, Apple sells 10x that number. Assuming that their tech support actually gets experience with the products before they try to support it, that means that 10 times the support personel must be trained. This means one of two things: larger training session sizes, or more levels of training. (For instance, if in scenario A each training session has 100 people and there are 1000 support personel (no clue how accurate these numbers are but it hardly matters), that means 10 classes. In scenario B, there are 100 classes. But that means you either need 10 times the time to train or 10 times the number of instructors. Who then need to be trained.) It also means that aple needs to produce more prerelease units to use for training.
This is somewhat an artifical example, and may be pretty pathetic, but in reality providing the support network for an organization 10 times the size isn't just taking what you have and duplicating it 10 times unless you want chaos between the copies.
1. In general, I'd say fish have more control than most birds 2. Fish can pretty much stop if they like and move very little; almost no birds can (I think the hummingbird may be the only one able to hover) 3. Birds can dive very quickly because they have gravity to assist them; fishs' climb and descent speeds will be a lot more equal 4. A fish needs to expend energy to move forward; some birds have very very high glide ratios and can soar for quite some time while rarely beating their wings (not that sitting there with your wings outspread doesn't take energy)
And heck, if you're going to define our atmosphere and our ocean as a fluid medium, then you're saying that ALL animals are the same - name a single animal that travels through a completely SOLID medium.
You're missing the point. He's not saying they're related because they move through fluids, he's saying they're related because they have three dimensional control of where they are.
And to some extent, that is something exclusive to them. Land animals have to do a lot more work than them in order to move in anything but the "plane" of the Earth.
Okay, that's find and dandy until they move. Now, as you run, what are the various stresses that your leg endures? Is there any point at which your full weight is on just one foot? More than your full weight? Is there any point it which there is almost no weight on a foot? What is the range of weights? How 'bout for a bird's wings? How much does a bird have to flap its wings in order to hover (for birds that can) in relation to the range of fores on the wing? Fly forward? What about for a fish?
Actually, most commonly hit property is Illinois, because of it's placement two sevens away from jail and a chance card leading right to it. And actually, the most commonly hit space is jail; Illinois is 2. The square seven spaces from Go, the first chance, is actually the LEAST likely square to finish your turn on in the entire game. (Landing on would be higher quite a bit higher because of the 'go to' cards, but not enough to compensate.)
Interesting how well that "common sense" works out, huh?
This site has all the long-term probabilities (I've always thought it would be an interesting exercise to come up with the markov chain representing the board and try to duplicate the results myself, but haven't yet done it) and a number of other statistics. If you really want to play Monopoly well, instead of just for fun, you should study these charts. They can help guide you in how much and where you should invest.
If you don't want to look, the first few most common squares for finishing your turn are: 1. In Jail (this is separate from just visiting, so really there are 41 squares on the board) 2. Illinois 3. Go
Now here's where things start to get messy, and change depending on whether you try to stay in jail for as long as possible (good late in the game) or pay immediately (good eanly in the game). So the ranks are expressed as short term rank/long term rank
4. New York Ave/B&O RR 5. B&O RR/Free Parking
(If you stay in jail for as long as possible, your chances of landing on NY diminish drastically because it's 9 spaces from jail, so if you get out through doubles you can't land on it except by geting boxcars then the move back three chance card.)
(I find it interesting that reading is less-commonly landed on than B&O in either starategy despite the chance card leading right to it. I think the explanation is B&O's location 15 spaces from jail, plus the location of the chance card 12 spaces from jail and the go to nearest railroad card. The go to nearest railroad card doesn't help Reading much because to get it to advance to Reading you need to hit the chance after short line, which is soon after go to jail and has nothing going in its favor except the advance to nearest utility to go to Water Works then getting an 8. (But there is only one chance square that will send you to WW as opposed to 2 that will send you to electric company.)
9. Free Parking/St. James Place 10. Kentucky/Water Works
(Though WW being higher than EC here seems to contradict my earlier analysis.)
Slashdot Mirror
You don't have to bring up examples of functions that take NULL to mean "don't care", I know of some. time() being the first one that springs to mind
...
Wow, I was actually thinking something along those lines, but I didn't think it was something that simple. I checked out stuff like a couple of the itimer functions, gettimeofday, but didn't see it.
I would still prefer some syntax that indicates that a value is being passed by reference.
I would too, with the caveat that it not be required at call sites for functions that take const references. (The latter I think is necessary because there are a lot of places where it's passed by const reference and it's not logically a reference parameter. In fact, I think if you required notices even at those points you'd be at the C/pointer situation, which, as I said, is hardly better. The downside is it wouldn't be perfect, as there are still mutable members, casting away const, etc.)
For instance, I'm a fan of the C# method:
void swap(ref int a, ref int b) { int t = a; a=b; b=c; }
then
int one, two;
swap(ref one, ref two);
It even goes further with allowing you to specify just out parameters:
void assignFive(out int a) { a = 5; }
then
int one;
assignFive(one);
(Don't ask me why you'd write that, it was just the easiest demo of an out parameter I could think of.)
The latter has the benefit over making the parameter ref that the compiler would complain that you're using an uninitialized variable in the call to assignFive otherwise. (But now it would also complain if assignFive tried to use a before assigning to it, as it assumes that out parameters can be uninitialized.)
Ah, here's another point that I didn't think of before:
You're all talking about how passing by pointers is good for readability because it enforces documentation at the call site that it can be modified.
Here's one way, related to the null pointer point (no pun intended), in which passing by pointer hurts the self documentation of the code. It's not uncommon to find functions that can accept a null pointer as an argument. A lot of unix calls in particular will both set a non-null pointer argument to and return a value. (I can't think of any off the top of my head, but if you want I'll find one.) Having a reference parameter documents from the syntax of the code (the strongest documentation you can have) that null values are prohibited; having a pointer does not.
In other words, the issue of the validity of a null value goes beyond just checking for improper parameter values.
I've seen advice that addresses this point, and recommends the use of reference parameters for situations in which null is invalid and pointers for when null is valid for this very reason. Sutter and Alexandrescu give this advice for when to pass by pointer and when to pass by reference:
But it doesn't make it nigh impossible for the object to be invalid. Checking for input validity is not something you can skip no matter your passing method.
;-)
If the input isn't valid, nothing you can legally do will find it.
And even so, it's one less thing that you have to test for.
And checking for non null is simple [then an assertation]
You just moved to runtime what the compiler could have enforced (as much as anything can be) for you at compile time.
If the best use for references is to avoid a one line check at the expense of making the calling code more difficult to understand, then I'd say there's no use for references at all.
It also symplifies syntax in the called function. There are other places where references are "necessary" though (for instance the return value of vector::operator[]), so they couldn't be removed from the language entirely even if you didn't allow them in argument lists.
(And I posted another comment about how I don't find even the readability argument in favor of passing by pointers unconvincing.)
The rule I use, which I've heard Bjarne himself utter while simultaneously destroying with the stream operators, is that the operator should have an obvious meaning analagous to the built-in operator. E.g. adding strings and complex numbers both have obvious expected meanings.
It's good rule, and one reason why I think that the proposed someVector += 5, 6; syntax is absolutely awful.
However, I think that an exception can be made for the shifting operators and input and output partly because of the very long history that they have, and partly because (to my knowledge) the shifting operators were pretty much invented for programming. +, *, etc. all have meanings we've seen since kindergarden or before; << doesn't. It makes sense, but then it also sort of makes sense for stream operations.
That's why I still use printf().
And lose flexability and enforced type safety?
(I know this is a war I can't win, but: I think that printf syntax often looks nicer, but it's harder to learn, a lot harder to understand if you don't know it, and isn't typesafe. You also have issues with how you output with classes because you can't make the printf formatting string accept new switches, and couldn't pass a non-POD type anyway. There was a language extension proposed to allow typesafe, variable length argument lists, which would have fixed some of those problems. I haven't heard anything about it for a long time though (I didn't necessarily RTFA now though), so I doubt it will come to fruition. That would have been nice though.)
My apologies, you're correct. I was under the impression that const within C was a compiler extension and not standard.
(The point of my original post though, that you still can't tell from the call site if an argument will be modified when passed by pointer, stands.)
I had read The C++ Standard Library, by Josuttis
Good book. I've got it sitting a few feet away.
However, the implementations I have used have all treated a vector of booleans as a resizable bit field.
I can't easily check to see if what I'm using does, so I'll take your word for it.
At any rate, resizable bit arrays still don't (imho) deserve special status in a language. They should be possible, but not necessarily part of the language proper
Agreed. If the standard committee drops the bool specialization (unlikely), they should add a resizable bit array. If they don't, they should consider mandating the space optimization. (It's at the cost of speed though, so who knows. Hard to say.)
C's style of things hardly makes things any better. If I have a function foo(some struct* x), why am I passing x by pointer? Is it just to save time and duplicating x on the stack, or is it because foo is actually going to change it? You can't tell that from looking at the call site either, even if C had const or in the extensions where it does. My experience is that most of the time most objects are passed by reference or pointer. That means that loss of readability from reference parameters in C++ really only show up when you're dealing with primitive types.
Not only that, but I just thought of something else:
If you don't have const in C, the situation is actually better with C++, references, and const, because the almost universal idiom is to pass by const reference to save space. If you see a reference parameter that isn't const, it's at least somewhat safe to assume it will be changed. (The other main possibility is that people were lazy with classes and didn't make them const correct, forcing them to use non constants.) You can tell if a parameter is const by the function signature. Not as good as the call site, but still better than in C where you can only tell from the method implementation (or documentation) that a parameter isn't changed.
(std::vector is defined to be a special case of std::vector to only take one bit per entry).
No, it's not. It's defined to be a special case of std::vector with modifications that ALLOW implementers to make it take one bit per entry.
At least a couple books say that most libraries don't do that.
Of course you need the entire source, instead of just the header files, but that's a minor inconvinience in my opinion.
Depends. If you're releasing a commercial (to the naysayers, fine, a proprietary) library, you could very well not want to do that.
It's not a total wash of the idea because you could still support separate files (in fact, you'd very nearly have to with the code base that's out there).
That's fine and dandy, but the fact remains that pass by reference makes it more difficult to understand code. There is no syntax at the place the function is called that indicates that it is pass by pointer (which is what pass by reference really is in C++) instead of by value, and this is by no means an insignificant difference.
I'll agree to some extent, but I have two things that I feel need to be added:
1. Pass by reference doesn't make it difficult to understand code, the lack of syntax at the call site does. For instance, C# allows reference parameters, but you need to specify that at the call site too.
2. C's style of things hardly makes things any better. If I have a function foo(some struct* x), why am I passing x by pointer? Is it just to save time and duplicating x on the stack, or is it because foo is actually going to change it? You can't tell that from looking at the call site either, even if C had const or in the extensions where it does. My experience is that most of the time most objects are passed by reference or pointer. That means that loss of readability from reference parameters in C++ really only show up when you're dealing with primitive types.
Not a joke, a research project. Thus, Stroustrup's willingness to include any "feature" that someone suggests: "Oh sure, we'll put that in and see how it works out."
Neither of these statements is true. He was at Bell Labs, but in no ways did he intend C++ to be a research project. He wrote it to solve real-world programming problems, to make real-world programming easier. How much he succeeded you can argue, but he did intend for it to become as widly used as it is.
As to your second point, follow the other fellow's advice and read D&E sometime.
It doesn't matter how fast the fish swims; that will only change how fast the water moves in relative to how long ago it was there. It will still flow back nearly instantly. Mole holes can stick around for years.
Who sent this down? I think it's good...
BTW, that's Feynman's emphasis, not mine.
I'll agree that if you're using physical laws to do calculations and you use Einstein instead of Newton to calculate the flight of a baseball, you're doing way too much work.
But that doesn't make Newton right.
I'm gonna quote Feynman because he expresses my feelings very well. This is from Six Easy Pieces (p3 in my copy; you can also find it in the "atoms in motion" chapter of Lectures), but I should say that this is a thought I've had long before reading this:
Now you could view science as a much more mature study... there may still be a lot of room for new discoveries but they are not the easy ones that can be expressed with 5 characters like "e=mc2"
Are you really that sure about that?
I'll agree that the chances of another discovery where such a profound statement (that energy and mass are convertible) can be made in so simple a form is unlikely, but by no means is it impossible. I have a suspicion that if you went to 1904 and asked someone if such a statement could be made so simply you would have gotten a reaction similar to yours.
Another possible influence on this may be that at Einstein's time, there was a world war going on.
Keep in mind that special relativity was 1905 and general 1915. At the time he published his two biggest theories (or at least the most well known, even among people who have done some physics studying) he wasn't yet anywhere near the Manhattan Project or anything like that.
It's not just a matter of that Einstein is more recent, it's that Newton is wrong. Even though from my understanding Newton's work was a much bigger jump at the time than was Einstein's at his (which is somewhat of a biased view as just yesterday I read most of Feynman's "Six Not-So-Easy Pieces" so am more familiar with the working leading up to special relativity, while I don't know much about the giants Newton stood upon), the fact that its Einstein's, and not Newton's, that marks our best understanding of the universe I think is a major factor in Einstein's fame.
This is, of course, related to the fact that Einstein is more recent, but still deserves mention.
(And on a side note, let me just say that learning about aspects of relativity, even as much as I can, has convinced me that if there is a god, He has quite the sense of humor and creativity.)
It does seem like there's a qualitative difference in how they move. You yourself argued in other threads that the motions of a bird and fish are different than a mole, because the latter digs. I would add to your distinction the observation that the holes left behind by a mole are permanent in the short term, while the "holes" behind the bird and the fish refill pretty much instantly.
You can take this point further and say that once a mole digs out a nice house, almost all his motion is constrained to the tunnels that are already dug. So while he has the capability to exercise full 3D motion, the natural state is that he does not. And more than that, even if he does keep digging just so that he can prove that he can go in any direction, he'll eventually make a cavern. At that point his 3D control has been lost, as he can't go up without refilling his home.
None of these apply to the bird or the fish. Their motion is, to a large extent, not constrained. Look at the paths of either; they don't go in the same motion. There's no loss of control once they have flown a particular route, nor is there any factor to make them fly that exact route again. And the constraints that the DO face, for instance trees in the case of a bird, have parallels in the mole universe: they can't dig through rocks for instance.
They're the "kleenex" of MP3 players.
Hey, Kleenex *is* the best facial tissue.
I'm not trying to argue against the specific point which is that Apple would have the same problems as Dell et. al. if they were larger (I think that if their product quality remained the same they wouldn't have the problems), but you can't necessarily just scale up what you already have. Increased numbers of people mean increased numbers of people who Apple'd need to coordinate between.
As a concrete example, think of what happens when, in 6 months, Apple releases the new iFancyToy. They need to provide support for the iFancyToy. In scenario A, Apple sells the same number of units they are selling now. In scenario B, Apple sells 10x that number. Assuming that their tech support actually gets experience with the products before they try to support it, that means that 10 times the support personel must be trained. This means one of two things: larger training session sizes, or more levels of training. (For instance, if in scenario A each training session has 100 people and there are 1000 support personel (no clue how accurate these numbers are but it hardly matters), that means 10 classes. In scenario B, there are 100 classes. But that means you either need 10 times the time to train or 10 times the number of instructors. Who then need to be trained.) It also means that aple needs to produce more prerelease units to use for training.
This is somewhat an artifical example, and may be pretty pathetic, but in reality providing the support network for an organization 10 times the size isn't just taking what you have and duplicating it 10 times unless you want chaos between the copies.
My somewhat educated guesses are as follows:
1. In general, I'd say fish have more control than most birds
2. Fish can pretty much stop if they like and move very little; almost no birds can (I think the hummingbird may be the only one able to hover)
3. Birds can dive very quickly because they have gravity to assist them; fishs' climb and descent speeds will be a lot more equal
4. A fish needs to expend energy to move forward; some birds have very very high glide ratios and can soar for quite some time while rarely beating their wings (not that sitting there with your wings outspread doesn't take energy)
You need to spend less time reading topology books
And heck, if you're going to define our atmosphere and our ocean as a fluid medium, then you're saying that ALL animals are the same - name a single animal that travels through a completely SOLID medium.
You're missing the point. He's not saying they're related because they move through fluids, he's saying they're related because they have three dimensional control of where they are.
And to some extent, that is something exclusive to them. Land animals have to do a lot more work than them in order to move in anything but the "plane" of the Earth.
Okay, that's find and dandy until they move. Now, as you run, what are the various stresses that your leg endures? Is there any point at which your full weight is on just one foot? More than your full weight? Is there any point it which there is almost no weight on a foot? What is the range of weights? How 'bout for a bird's wings? How much does a bird have to flap its wings in order to hover (for birds that can) in relation to the range of fores on the wing? Fly forward? What about for a fish?
Oh, I didn't see your 'multiple of seven' bit. Well, here are the ranks for one circuit, jumping by 7s:
+7 Chance (#40)
+14 Virginia (#22)
+21 Kentucky (#10)
+28 Water Works (#11)
+35 Short Line (#25)
I stop here because if you keep going you will probably hit every property eventually.
The problem with your theory is that jail really screws up where you will land in relation to the 7's around from Go.
Actually, most commonly hit property is Illinois, because of it's placement two sevens away from jail and a chance card leading right to it. And actually, the most commonly hit space is jail; Illinois is 2. The square seven spaces from Go, the first chance, is actually the LEAST likely square to finish your turn on in the entire game. (Landing on would be higher quite a bit higher because of the 'go to' cards, but not enough to compensate.)
Interesting how well that "common sense" works out, huh?
This site has all the long-term probabilities (I've always thought it would be an interesting exercise to come up with the markov chain representing the board and try to duplicate the results myself, but haven't yet done it) and a number of other statistics. If you really want to play Monopoly well, instead of just for fun, you should study these charts. They can help guide you in how much and where you should invest.
If you don't want to look, the first few most common squares for finishing your turn are:
1. In Jail (this is separate from just visiting, so really there are 41 squares on the board)
2. Illinois
3. Go
Now here's where things start to get messy, and change depending on whether you try to stay in jail for as long as possible (good late in the game) or pay immediately (good eanly in the game). So the ranks are expressed as short term rank/long term rank
4. New York Ave/B&O RR
5. B&O RR/Free Parking
(If you stay in jail for as long as possible, your chances of landing on NY diminish drastically because it's 9 spaces from jail, so if you get out through doubles you can't land on it except by geting boxcars then the move back three chance card.)
6. Reading RR/Tenessee Ave
7. Tenessee Ave/New York Ave
8. Pennsylvania RR/Reading RR
(I find it interesting that reading is less-commonly landed on than B&O in either starategy despite the chance card leading right to it. I think the explanation is B&O's location 15 spaces from jail, plus the location of the chance card 12 spaces from jail and the go to nearest railroad card. The go to nearest railroad card doesn't help Reading much because to get it to advance to Reading you need to hit the chance after short line, which is soon after go to jail and has nothing going in its favor except the advance to nearest utility to go to Water Works then getting an 8. (But there is only one chance square that will send you to WW as opposed to 2 that will send you to electric company.)
9. Free Parking/St. James Place
10. Kentucky/Water Works
(Though WW being higher than EC here seems to contradict my earlier analysis.)