1. SQL syntax doesn't look like relational algebra (see my long rant above). This clouds thinking and hides the simplicity of the underlying model.
Fair enough
2. Relations are sets. SQL allows duplicate rows, so its tables aren't sets, and therefore aren't relations. (This property alone is enough to make it "not relational" by the way).
This is true
3. Relation *attributes* (the column names) are also sets. SQL allows columns with the SAME NAME in a query result!!
Is this true (the first part)? i.e. can you (in a "pure" relational language) have a query like
SELECT (SELECT favouritecolumn FROM staff WHERE name='Smith') FROM
sometable
to select the favourite columns of people called Smith?
4. SQL has no "table equality" operator. You'd think the first operator you'd implement for a data type, especially a fundamental data type, would be equality! Imagine a programming language with no integer equality for instance.
Yes, this is a shortcoming
5. Relations require each attribute to be drawn from a single type or domain. SQL allows NULLs, which are values not drawn from the column's type. And SQL gives you very little to help you work without NULLs. To add insult to injury, the default for columns is NULLable.
Wrong, if the column is NULLable then NULL is part of the column's type—it should be treated as a value distinct from any other value in that type. What is true is that SQL's treatment of NULLs is broken (and inconsistent between implementations).
6. (related) Relational algebra requires boolean logic. SQL uses three-valued logic because of NULLs. And it uses it *inconsistently*.
Yes, NULL-handling is broken.
7. The relational model does not specify a type system, it just requires one. Yet SQL specifies it's own particular type system (integers, chars, etc). What if you want to store XML or audio in one of your columns?
Then do so:-)
8. The relational model specifies nothing about physical implementation. Yet, almost every SQL product stores the columns of tables "together" in such a way that makes joins needlessly expensive.
What's that you say? "almost every SQL product"? So you admit that this is not a flaw of SQL itself? And that it's not even something that makes SQL non-relational? The fact that some (even all) implementations are lacking in some respect does not make for a flaw in the language. (SQL has enough flaws in of itself, there's no need to make them up:-)
9. SQL distinguishes between "base tables" and "views". The relational model requires them to be indistinguishable to the end user. Specifically, most SQL implementations don't let you update views! Pretty unbelievable. Imagine a programming language that didn't let you pass arguments to any function for instance.
Your comparison just doesn't make sense. You know perfectly well why "base tables" and "views" are distinguished, and this problem exists in a pure-relational model too.
10. SQL lets you do meaningless things like multiply the primary key values of two tables or add a weight to a height. This is related to the type system issues.
There is nothing about the relational model that stops one adding a weight to a height... as you say, this is more related to the choice of type system.
11. SQL confuses KEYs (logical) with INDEXes (physical implementation).
Fair enough.
12. (This one gets me all the time) SQL has an EXISTS operator (is this statement true for at least one value of this result?) but not a FOREACH operator (is this statement true for all values in this result?).. I think this is related to lack of table equality.
This is disingenuous as well, since the EXISTS operator does not work as you suggest (it's "is this statement true for at least one tuple")—the corresponding operator would be FORALL which would involve checking a
To lower the requirement of back-and-forth posting, I'll make my choices in advance
Better still... let's not waste any time!
For the "not switch scenario", I'll take door 1. You will agree that I have a 1/100 chance of being right at this moment, before you open the 98 doors. Correct?
Correct. Well, kinda. It's 1/100 from your point of view, since you don't know where the prize is. I know, so (depending on which door the prize is hiding behind this time round), from my point of view it's either 0 or 1.
For the "switch scenario", I'll take door not-1 (meaning I picked 1, then switched to whatever door was left after you opened the 98 remaining ones). At this moment, before you open the 98 doors, you will also agree that the probability of each door is 1/100,
I'm with you so far...
so not-1 gives me 1/100 too.
... except that it doesn't. It gives you 99/100. But I guess you'll disagree with that, so let's see how the simulation runs:
First go. (Prize is behind door 84). You pick door 1. I open doors 2–83, 85–100. Switcher picks remaining door (84) and gets the prize. Non-switcher gets a goat.
Second go. (Prize is behind door 33). You pick door 1. I open doors 2–32, 34–100. Switcher picks remaining door (33) and gets the prize. Non-switcher gets a goat.
Third go. (Prize is behind door 26). You pick door 1. I open doors 2–25, 27–100. Switcher picks remaining door (26) and gets the prize. Non-switcher gets a goat.
Fourth go. (Prize is behind door 92). You pick door 1. I open doors 2–91, 93–100. Switcher picks remaining door (92). Non-switcher gets a goat.
Tired yet? I know this is a small sample, but I think I'm beginning to spot a pattern... the non-switcher is sure getting a lot of goats... perhaps there is something to this switching business after all? (If you're not convinced I'll gladly continue the simulation many more times...)
What is your point again? That if I see you opening the 98 doors I will gain knowledge?
Yes
I'll know that one of the two remaining doors have the prize? Well, I have magical powers so I already know that.
Good for you! But sometimes you'll know even more than that. In the cases where your initial guess was wrong, you'll know which of the 99 doors that you didn't pick on the first go is the right door. And since your first guess—as you've correctly stated—is wrong 99% of the time, you can be 99% certain that the remaining door hides the prize!
The only difference would be if you had GAINED some true information about the location of the prize
This is absolutely, 100% true.
which didn't happen, since you knew from the start that you would end up with two doors to choose from, one having the prize, other not.
This isn't true. I agree that we knew from the start that we'd end up with two doors to choose from. What we didn't know is which doors we'd end up with. Monty, our host, doesn't pick a door to open at random—in the case where we've initially picked a goat, he always picks the other goat.
So, in 2/3 of cases, he gives you some extra information (enough to allow you to pick the car) and in 1/3 of cases he doesn't. So it makes sense to take the action that pays off 2/3 of the time, and switch!
If you're not convinced, how come you won't take my (virtual) wager, where you get V$20 for a win, and give me V$1 for a lose? By your reasoning, the odds are 50–50, so you stand to make a lot of virtual money! I repeat: Which door (1–100) do you choose?
The odds of switching being correct are 50/50, as there are two outcomes out of 4 that are favorable.
This where the problem lies—there are two of four outcomes that are good, but some of those outcomes (the first two in your list) are less likely than the others.
I repeat my challenge: let's play a simulation of the 100-door game. I've hidden the car behind a door. Which door (1-100) do you choose?
Which means 2/3 of WINs if you switch, but the correct balance is:
you pick goat A, Monty shows goat B, switch = WIN
you pick goat B, Monty shows goat A, switch = WIN
you pick the car, Monty shows goat A, switch = LOOSE
you pick the car, Monty shows goat B, switch = LOOSE
You are right, in that it's correct to view the situation as having four outcomes. However, the outcomes don't have equal probability. Outcome 1 is as likely as outcome 2, but each of those is as likely as 3 & 4 combined - if we assume Monty picks a goat at random when he has a choice, then 3 & 4 are each half as likely as 1 & 2. (Try drawing a probability tree for the different outcomes.)
Still not convinced? Still think that the chances are 50-50 in the 100-door version? Fine by me. Let's play a game. I'll be Monty. Every time you choose the "car", I'll give you $20; every time you choose a goat, you owe me $1. I've chosen a door that holds the car. Which door (1–100) do you choose?
(To give some evidence I'm not cheating, the md5sum of the door number I've chosen, plus a password, is fcc388da803aa97fa875ecce50f14bd8. At the end of the game I'll show the word and the number, so you can verify I haven't changed it. And if you think MD5 is too broken to be convincing, I'll happily switch to a well-known hash / combination of hashes of your choice!)
You're (for some strange reason) assuming that when he reveals the door, it increases the chance that the door you did not pick is the winner.
Not at all. I'm assuming that the probability that I pick the right door out of three (before any doors are opened or anything) is 1/3 (no disgreement here, right?). Whether one door's going to get eliminated later or not, my chances of being right so far are 1/3.
If, instead of opening a door, the host were to offer "I'll open your door, but then give you a car if your door contains a goat, but give you a goat if it contains a car", would you take it? I would—in 2/3 cases I'd get the car, and in 1/3 I'd get the goat, which sounds better to me. (I explained this to my gf and she said she'd rather have a goat—go figure!)
The procedure with Monty opening a door with a goat, then letting you switch, always has exactly the same outcome as the above offer—so logically the probability of ending up with a car is the same.
Have you thought through the example with 100 doors? Where you pick one, then Monty opens all the remaining doors except one, and gives you the option to switch. Do you still think it's a 50-50 chance that the one door he's left shut (no. 73) contains the car?
Ignore (for the moment!) the fact that the host will open a door for you. Would you take someone up on the offer of exchanging a win for a lose and vice versa (thus changing your win probability from 1/3 to 2/3)? Answer yes or no—and if no, please give reasons...
If you agree with that, do you agree that the process of Monty (who knows where the prize is) revealing a goat, then you switching, is guaranteed to switch you from a goat to a car, and vice versa? (I hope you agree since you've enumerated the possibilities and ruled out the ones where this doesn't happen!).
If you agree with those two facts, you're forced to accept that switching gives you a 2/3 chance of winning the car. It seems like, after one goat is revealed, you've got a 1/2 chance, but in fact the chances stay at 1/3 (current door) and 2/3 (other door). The reason it doesn't go 50–50 is that Monty doesn't pick a door to open at random—he deliberately picks one with a goat.
As other posters have pointed out, if there are a hundred doors to start with (99 goats + 1 car), you pick one, and then Monty opens all remaining doors but one to reveal goats—would you stay with your current selection, or go for the one door that Monty has left shut? Remember, Monty knows where the prize is. 99% of the time you'll be wrong, so him opening 98 other doors will show you where the prize is. 99% of the time if you go for that door you'll get the car—because Monty knows the answer, the 99% probability of the car being in one of the doors you haven't chosen "condenses" into the door that he didn't open. (The 1% of the time when you picked the car first time—well, that's just too bad...)
It's less obvious, but it's just the same with three doors!
How is knowing information about another door going to suddenly make your door MORE likely to be a success?
Well, if he opened both the other doors to reveal goats, your door's probability would go up to 100%!
But of course you're right in this case. For anyone who doesn't believe it, it may help to think of it like this: when you first pick a door, you have a 1-in-3 chance of being right, and a 2-in-3 chance of being wrong. If someone offered you the opportunity to swap your door, guaranteeing that:
If your current door is winning, you'll replace it with a losing door
If your current door is a loser, you'll replace it with a winning door
would you take the opportunity? I hope you would, since you'd end up with a 2-in-3 chance of being right, and a 1-in-3 chance of being wrong.
The procedure of revealing a losing door achieves this—if you had a winning door, and switch, you'll get a goat, but if you had a losing door, and a goat is revealed behind another door, the remaining door must hide the prize. So, bizarre though it may seem, it's in your advantage to switch...
If you take just a single string [of length n] and rotate it against itself in a search for matches, then you've got to do n^2 byte comparisons just to find all singleton matches,...
No you don't:-)
If you want to find all singleton matches, it's enough to sort the string into ascending order (order n.log(n)), and then scan through for adjacent matches (order n). For example, sorting "the cat sat on the mat" gives "cat mat on sat the the"—where the two "the"s are now adjacent and so easily discovered.
For finding longer matches the sorting method still works, except that you sort fragments of the sentence rather than individual words. Clearly there is more work involved, but (depending on exactly what you're counting) there are still order n.log(n) comparisons to be performed.
This means that searching for substring matches can be performed relatively efficiently. I don't know about how the language-learning algorithm works, but you may be interested to know that the compression algorithm used by "bzip2" works in exactly this way (google for "Burrows-Wheeler transform" for more details!)
Unfortunately that's not true. What you say makes sense—but the term “TCP/IP” is commonly used to mean “The whole family of protocols including TCP, UDP, ICMP etc running over IP”—not just TCP running over IP (which would, admittedly, be a more logical meaning for it...).
Interesting idea about making buttons bigger the more they're used. But please don't move them around... this is enormously confusing for new users (eg they may have learnt "To reply to all I press the button on the right"), and frustrating for experienced users (who may be used to being able to click on a given button almost without looking, or be used to clicking on a button and then a button nearby...). It doesn't helpthe user learn the interface and become comfortable with it if the ground keeps shifting underneath them!
Re:ANY loss level??
on
Replacing TCP?
·
· Score: 2, Funny
They only claim to be able to "send at speeds"... I guess 0bps is a speed:-)
Re:The style of an old home computer
on
Ceefax Turns 30
·
· Score: 2, Informative
The name isn't a coincidence - the computer was originally going to be called the Proton, but the BBC were looking for a computer for their BBC Computer Literacy Project - see here for more details.
(And in fact, teletext came first - the BBC Micro came out in the early 80s, teletext in the 70s...)
No, the font isn't standardised, just the character set - and indeed, some TVs do have better fonts than others. However, most seem to use the same few character sets; I suspect there are commodity chips to produce the display, and it's cheaper/easier for manufacturers to use them than roll their own...
That way, the attacker not only has to tweak the message so that the MD5 hash is what they want, they also have to tweak it so that the SHA1 hash of that message produces a message that gives the desired MD5 hash...
Well, just shot yerself in the foot there. The fact that you feel the need to put an article (i.e. "the") before the word "Internet" is a very good indicator (in the English language) that the thing is not a proper noun.
It's not normally considered necessary to write The Moon... indeed, unless "The" was part of its name, it would be quite correct to write "I'm staying in the Crown Plaza"...
The suffix '-bility' does not come from the word 'ability'; it comes from the Latin suffix '-bilis'... the "i" comes from the vowel at the end of the verb to which the suffix is being attached. The word 'able' may ultimately derive from the same root, but that doesn't mean all words ending '-bility' must have an 'a'!
Your point is interesting (and subtle), but I think your conclusions are possibly a little overreaching...
Your argument for dismissing uncountable sets
could equally apply to geometry: where, in geometry, is my guarantee of mathematical meaning? I cannot construct a "circle" or a
"straight line" that correspond to their
geometric definitions; they may even (in a quantized universe) have no correspondence with space: as with ZFC all I can get is "a system for deriving strings in a formal language" - and yet, the study of geometry, being both interesting and useful, is a valuable part of mathematics.
I think a lot of the discussion hinges on what it means for something to "exist". Even constructive mathematics is to some extent a formalism: I cannot construct all the natural numbers - indeed, I can write (in digits) numbers up to which I could never possibly count - yet I am required to believe that the same theories apply to these numbers because I could "in principle" construct them... to some this is as great a leap of faith as any taken in accepting ZFC... how, then, do you justify that countable sets do exist and yet uncountable ones do not?
Furthermore, it is wrong to say that anything that is not a "precise, absolute" concept (however that may be defined) is not worthy of mathematical study: while it is healthy that mathematicians should feel uneasy about such ideas, it is in determining which stand up to rigorous examination, and which are flawed, that great insight is gained and advances are made; therefore, just as we should be hesitant to accept them, we should not reject them until they are proven inconsistent.
The explanation is simple - the so-called "BGP security feature" is in fact a security feature at the *TCP* level (which puts MD5 signatures on each TCP packet): it tends to get called a "BGP" feature because network operators need to enable it in their BGP configuration (not to mention the fact that BGP is the only common protocol for which this TCP option is ever used).
It's not necessarily fair to accuse the operators of laziness though; the trouble with this fix is that both ends of a BGP peering session need to know the same "secret" (password), and it needs to be configured on both ends at the same time. So if you're a "good" ISP who wants to secure their network against this attack, you can't unless all the ISPs that you peer with will co-operate... this is largely the reason why it has not been implemented up till now...
(It's also the reason why this option can't be
turned on by default in BGP...)
I'm not sure how many do - this option isn't used for anything other than BGP, as far as I know, so TCP implementations on routers will tend to have it, but others don't...
This feature is not very easy to use - both ends of the TCP connection need to know (and configure) a shared secret; this is the major reason why a lot of ISPs haven't set this up already - the router configuration is fairly trivial, what's complicated is co-ordinating with all the ISPs you peer with and arranging a different shared secret with each one (and then getting them to configure the option at exactly the same time that you do!)
Not true - the MD5 authentication in BGP4 makes use of a little-known TCP option to add an MD5 signature to each TCP packet (see RFC2385) - so the protection is at the TCP layer, and configuring MD5 auth for BGP will help:-)
(In fact, as far as I know, the MD5 option was added to TCP specifically to get round this vulnerability in BGP!)
Slashdot Mirror
Microwaves are perfect for this since they hit the resonance frequency of water
Actually that's not true: see for example
Fair enough
2. Relations are sets. SQL allows duplicate rows, so its tables aren't sets, and therefore aren't relations. (This property alone is enough to make it "not relational" by the way).
This is true
3. Relation *attributes* (the column names) are also sets. SQL allows columns with the SAME NAME in a query result!!
Is this true (the first part)? i.e. can you (in a "pure" relational language) have a query like SELECT (SELECT favouritecolumn FROM staff WHERE name='Smith') FROM sometable to select the favourite columns of people called Smith?
4. SQL has no "table equality" operator. You'd think the first operator you'd implement for a data type, especially a fundamental data type, would be equality! Imagine a programming language with no integer equality for instance.
Yes, this is a shortcoming
5. Relations require each attribute to be drawn from a single type or domain. SQL allows NULLs, which are values not drawn from the column's type. And SQL gives you very little to help you work without NULLs. To add insult to injury, the default for columns is NULLable.
Wrong, if the column is NULLable then NULL is part of the column's type—it should be treated as a value distinct from any other value in that type. What is true is that SQL's treatment of NULLs is broken (and inconsistent between implementations).
6. (related) Relational algebra requires boolean logic. SQL uses three-valued logic because of NULLs. And it uses it *inconsistently*.
Yes, NULL-handling is broken.
7. The relational model does not specify a type system, it just requires one. Yet SQL specifies it's own particular type system (integers, chars, etc). What if you want to store XML or audio in one of your columns?
Then do so :-)
8. The relational model specifies nothing about physical implementation. Yet, almost every SQL product stores the columns of tables "together" in such a way that makes joins needlessly expensive.
What's that you say? "almost every SQL product"? So you admit that this is not a flaw of SQL itself? And that it's not even something that makes SQL non-relational? The fact that some (even all) implementations are lacking in some respect does not make for a flaw in the language. (SQL has enough flaws in of itself, there's no need to make them up :-)
9. SQL distinguishes between "base tables" and "views". The relational model requires them to be indistinguishable to the end user. Specifically, most SQL implementations don't let you update views! Pretty unbelievable. Imagine a programming language that didn't let you pass arguments to any function for instance.
Your comparison just doesn't make sense. You know perfectly well why "base tables" and "views" are distinguished, and this problem exists in a pure-relational model too.
10. SQL lets you do meaningless things like multiply the primary key values of two tables or add a weight to a height. This is related to the type system issues.
There is nothing about the relational model that stops one adding a weight to a height... as you say, this is more related to the choice of type system.
11. SQL confuses KEYs (logical) with INDEXes (physical implementation).
Fair enough.
12. (This one gets me all the time) SQL has an EXISTS operator (is this statement true for at least one value of this result?) but not a FOREACH operator (is this statement true for all values in this result?) .. I think this is related to lack of table equality.
This is disingenuous as well, since the EXISTS operator does not work as you suggest (it's "is this statement true for at least one tuple")—the corresponding operator would be FORALL which would involve checking a
It's only save when they cut the risk of smoking-related diseases such as cancer and heart failure by up to 100%
It's only safe when the cut the risk of smoking-related diseases by at least 100%...
;-)
I'll take your "simulation".
Excellent :-)
To lower the requirement of back-and-forth posting, I'll make my choices in advance
Better still... let's not waste any time!
For the "not switch scenario", I'll take door 1. You will agree that I have a 1/100 chance of being right at this moment, before you open the 98 doors. Correct?
Correct. Well, kinda. It's 1/100 from your point of view, since you don't know where the prize is. I know, so (depending on which door the prize is hiding behind this time round), from my point of view it's either 0 or 1.
For the "switch scenario", I'll take door not-1 (meaning I picked 1, then switched to whatever door was left after you opened the 98 remaining ones). At this moment, before you open the 98 doors, you will also agree that the probability of each door is 1/100,
I'm with you so far...
so not-1 gives me 1/100 too.
... except that it doesn't. It gives you 99/100. But I guess you'll disagree with that, so let's see how the simulation runs:
First go. (Prize is behind door 84). You pick door 1. I open doors 2–83, 85–100. Switcher picks remaining door (84) and gets the prize. Non-switcher gets a goat.
Second go. (Prize is behind door 33). You pick door 1. I open doors 2–32, 34–100. Switcher picks remaining door (33) and gets the prize. Non-switcher gets a goat.
Third go. (Prize is behind door 26). You pick door 1. I open doors 2–25, 27–100. Switcher picks remaining door (26) and gets the prize. Non-switcher gets a goat.
Fourth go. (Prize is behind door 92). You pick door 1. I open doors 2–91, 93–100. Switcher picks remaining door (92). Non-switcher gets a goat.
Tired yet? I know this is a small sample, but I think I'm beginning to spot a pattern... the non-switcher is sure getting a lot of goats... perhaps there is something to this switching business after all? (If you're not convinced I'll gladly continue the simulation many more times...)
What is your point again? That if I see you opening the 98 doors I will gain knowledge?
Yes
I'll know that one of the two remaining doors have the prize? Well, I have magical powers so I already know that.
Good for you! But sometimes you'll know even more than that. In the cases where your initial guess was wrong, you'll know which of the 99 doors that you didn't pick on the first go is the right door. And since your first guess—as you've correctly stated—is wrong 99% of the time, you can be 99% certain that the remaining door hides the prize!
You're so close to being in agreement with me...
The only difference would be if you had GAINED some true information about the location of the prize
This is absolutely, 100% true.
which didn't happen, since you knew from the start that you would end up with two doors to choose from, one having the prize, other not.
This isn't true. I agree that we knew from the start that we'd end up with two doors to choose from. What we didn't know is which doors we'd end up with. Monty, our host, doesn't pick a door to open at random—in the case where we've initially picked a goat, he always picks the other goat.
So, in 2/3 of cases, he gives you some extra information (enough to allow you to pick the car) and in 1/3 of cases he doesn't. So it makes sense to take the action that pays off 2/3 of the time, and switch!
If you're not convinced, how come you won't take my (virtual) wager, where you get V$20 for a win, and give me V$1 for a lose? By your reasoning, the odds are 50–50, so you stand to make a lot of virtual money! I repeat: Which door (1–100) do you choose?
The odds of switching being correct are 50/50, as there are two outcomes out of 4 that are favorable.
This where the problem lies—there are two of four outcomes that are good, but some of those outcomes (the first two in your list) are less likely than the others.
I repeat my challenge: let's play a simulation of the 100-door game. I've hidden the car behind a door. Which door (1-100) do you choose?
I beg to differ:
Go ahead :-)
Which means 2/3 of WINs if you switch, but the correct balance is:
You are right, in that it's correct to view the situation as having four outcomes. However, the outcomes don't have equal probability. Outcome 1 is as likely as outcome 2, but each of those is as likely as 3 & 4 combined - if we assume Monty picks a goat at random when he has a choice, then 3 & 4 are each half as likely as 1 & 2. (Try drawing a probability tree for the different outcomes.)
Still not convinced? Still think that the chances are 50-50 in the 100-door version? Fine by me. Let's play a game. I'll be Monty. Every time you choose the "car", I'll give you $20; every time you choose a goat, you owe me $1. I've chosen a door that holds the car. Which door (1–100) do you choose?
(To give some evidence I'm not cheating, the md5sum of the door number I've chosen, plus a password, is fcc388da803aa97fa875ecce50f14bd8. At the end of the game I'll show the word and the number, so you can verify I haven't changed it. And if you think MD5 is too broken to be convincing, I'll happily switch to a well-known hash / combination of hashes of your choice!)
You're (for some strange reason) assuming that when he reveals the door, it increases the chance that the door you did not pick is the winner.
Not at all. I'm assuming that the probability that I pick the right door out of three (before any doors are opened or anything) is 1/3 (no disgreement here, right?). Whether one door's going to get eliminated later or not, my chances of being right so far are 1/3.
If, instead of opening a door, the host were to offer "I'll open your door, but then give you a car if your door contains a goat, but give you a goat if it contains a car", would you take it? I would—in 2/3 cases I'd get the car, and in 1/3 I'd get the goat, which sounds better to me. (I explained this to my gf and she said she'd rather have a goat—go figure!)
The procedure with Monty opening a door with a goat, then letting you switch, always has exactly the same outcome as the above offer—so logically the probability of ending up with a car is the same.
Have you thought through the example with 100 doors? Where you pick one, then Monty opens all the remaining doors except one, and gives you the option to switch. Do you still think it's a 50-50 chance that the one door he's left shut (no. 73) contains the car?
My logic is not flawed :-)
Ignore (for the moment!) the fact that the host will open a door for you. Would you take someone up on the offer of exchanging a win for a lose and vice versa (thus changing your win probability from 1/3 to 2/3)? Answer yes or no—and if no, please give reasons...
If you agree with that, do you agree that the process of Monty (who knows where the prize is) revealing a goat, then you switching, is guaranteed to switch you from a goat to a car, and vice versa? (I hope you agree since you've enumerated the possibilities and ruled out the ones where this doesn't happen!).
If you agree with those two facts, you're forced to accept that switching gives you a 2/3 chance of winning the car. It seems like, after one goat is revealed, you've got a 1/2 chance, but in fact the chances stay at 1/3 (current door) and 2/3 (other door). The reason it doesn't go 50–50 is that Monty doesn't pick a door to open at random—he deliberately picks one with a goat.
As other posters have pointed out, if there are a hundred doors to start with (99 goats + 1 car), you pick one, and then Monty opens all remaining doors but one to reveal goats—would you stay with your current selection, or go for the one door that Monty has left shut? Remember, Monty knows where the prize is. 99% of the time you'll be wrong, so him opening 98 other doors will show you where the prize is. 99% of the time if you go for that door you'll get the car—because Monty knows the answer, the 99% probability of the car being in one of the doors you haven't chosen "condenses" into the door that he didn't open. (The 1% of the time when you picked the car first time—well, that's just too bad...)
It's less obvious, but it's just the same with three doors!
When you arrive a son of the coworker answers the door. What is the probability that the other child is a girl?
<answer type="weasel">Zero—the co-worker must have two sons, otherwise the question would say "the son" rather than "a son" ;-)
How is knowing information about another door going to suddenly make your door MORE likely to be a success?
Well, if he opened both the other doors to reveal goats, your door's probability would go up to 100%!
But of course you're right in this case. For anyone who doesn't believe it, it may help to think of it like this: when you first pick a door, you have a 1-in-3 chance of being right, and a 2-in-3 chance of being wrong. If someone offered you the opportunity to swap your door, guaranteeing that:
- If your current door is winning, you'll replace it with a losing door
- If your current door is a loser, you'll replace it with a winning door
would you take the opportunity? I hope you would, since you'd end up with a 2-in-3 chance of being right, and a 1-in-3 chance of being wrong.The procedure of revealing a losing door achieves this—if you had a winning door, and switch, you'll get a goat, but if you had a losing door, and a goat is revealed behind another door, the remaining door must hide the prize. So, bizarre though it may seem, it's in your advantage to switch...
If you take just a single string [of length n] and rotate it against itself in a search for matches, then you've got to do n^2 byte comparisons just to find all singleton matches,...
No you don't :-)
If you want to find all singleton matches, it's enough to sort the string into ascending order (order n.log(n)), and then scan through for adjacent matches (order n). For example, sorting "the cat sat on the mat" gives "cat mat on sat the the"—where the two "the"s are now adjacent and so easily discovered.For finding longer matches the sorting method still works, except that you sort fragments of the sentence rather than individual words. Clearly there is more work involved, but (depending on exactly what you're counting) there are still order n.log(n) comparisons to be performed.
This means that searching for substring matches can be performed relatively efficiently. I don't know about how the language-learning algorithm works, but you may be interested to know that the compression algorithm used by "bzip2" works in exactly this way (google for "Burrows-Wheeler transform" for more details!)
There's nothing misleading about TCP/IP
Unfortunately that's not true. What you say makes sense—but the term “TCP/IP” is commonly used to mean “The whole family of protocols including TCP, UDP, ICMP etc running over IP”—not just TCP running over IP (which would, admittedly, be a more logical meaning for it...).
Interesting idea about making buttons bigger the more they're used. But please don't move them around... this is enormously confusing for new users (eg they may have learnt "To reply to all I press the button on the right"), and frustrating for experienced users (who may be used to being able to click on a given button almost without looking, or be used to clicking on a button and then a button nearby...). It doesn't helpthe user learn the interface and become comfortable with it if the ground keeps shifting underneath them!
They only claim to be able to "send at speeds"... I guess 0bps is a speed :-)
The name isn't a coincidence - the computer was originally going to be called the Proton, but the BBC were looking for a computer for their BBC Computer Literacy Project - see here for more details.
(And in fact, teletext came first - the BBC Micro came out in the early 80s, teletext in the 70s...)
No, the font isn't standardised, just the character set - and indeed, some TVs do have better fonts than others. However, most seem to use the same few character sets; I suspect there are commodity chips to produce the display, and it's cheaper/easier for manufacturers to use them than roll their own...
Use both!
IANAC (cryptographer) but this seems to make sense to me. It would also seem to make sense to "chain" the hashes - that is:
That way, the attacker not only has to tweak the message so that the MD5 hash is what they want, they also have to tweak it so that the SHA1 hash of that message produces a message that gives the desired MD5 hash...per parsec.
... equals roughly 400 microbits/mile:
It's not normally considered necessary to write The Moon... indeed, unless "The" was part of its name, it would be quite correct to write "I'm staying in the Crown Plaza"...
The suffix '-bility' does not come from the word 'ability'; it comes from the Latin suffix '-bilis'... the "i" comes from the vowel at the end of the verb to which the suffix is being attached. The word 'able' may ultimately derive from the same root, but that doesn't mean all words ending '-bility' must have an 'a'!
(See this if you don't believe me :-)
Your point is interesting (and subtle), but I think your conclusions are possibly a little overreaching...
Your argument for dismissing uncountable sets could equally apply to geometry: where, in geometry, is my guarantee of mathematical meaning? I cannot construct a "circle" or a "straight line" that correspond to their geometric definitions; they may even (in a quantized universe) have no correspondence with space: as with ZFC all I can get is "a system for deriving strings in a formal language" - and yet, the study of geometry, being both interesting and useful, is a valuable part of mathematics.
I think a lot of the discussion hinges on what it means for something to "exist". Even constructive mathematics is to some extent a formalism: I cannot construct all the natural numbers - indeed, I can write (in digits) numbers up to which I could never possibly count - yet I am required to believe that the same theories apply to these numbers because I could "in principle" construct them... to some this is as great a leap of faith as any taken in accepting ZFC... how, then, do you justify that countable sets do exist and yet uncountable ones do not?
Furthermore, it is wrong to say that anything that is not a "precise, absolute" concept (however that may be defined) is not worthy of mathematical study: while it is healthy that mathematicians should feel uneasy about such ideas, it is in determining which stand up to rigorous examination, and which are flawed, that great insight is gained and advances are made; therefore, just as we should be hesitant to accept them, we should not reject them until they are proven inconsistent.
It's not necessarily fair to accuse the operators of laziness though; the trouble with this fix is that both ends of a BGP peering session need to know the same "secret" (password), and it needs to be configured on both ends at the same time. So if you're a "good" ISP who wants to secure their network against this attack, you can't unless all the ISPs that you peer with will co-operate... this is largely the reason why it has not been implemented up till now...
(It's also the reason why this option can't be turned on by default in BGP...)
This feature is not very easy to use - both ends of the TCP connection need to know (and configure) a shared secret; this is the major reason why a lot of ISPs haven't set this up already - the router configuration is fairly trivial, what's complicated is co-ordinating with all the ISPs you peer with and arranging a different shared secret with each one (and then getting them to configure the option at exactly the same time that you do!)
(In fact, as far as I know, the MD5 option was added to TCP specifically to get round this vulnerability in BGP!)
Patrick