Why does wavefunction collapse violate SR? SR prohibits information traveling faster than light. The no-communication theorem http://en.wikipedia.org/wiki/No-communication_theorem (I'd always called this the no-signaling theorem) leads to the no-cloning theorem http://en.wikipedia.org/wiki/No_cloning_theorem so if you like, SR "explains" the no-cloning theorem. (The no-cloning theorem still allows a cloning fidelity of 5/6. Last I saw, fidelities of 0.81 had been achieved)
Back to the topic at hand, the interesting thing with special relativity is that while it was created based on the results of the Michelson-Morley experiment, it doesn't actually "explain" that experiment.
Maxwell's equations (see sig) predict that light will propagate with a speed c independent of frame. Einstein had a choice, Newton was wrong or Maxwell was wrong. A non-null result from the MM experiment would invalidate Maxwell's equations.
So, if you like, Maxwell's equations "explain" the null MM result.
Can't make that work for me. I don't get the import wizard either way. In my case it's not leading zeros that are the problem but trailing zeros on numbers that look like decimals. (e.g. 1.10, 1.100)
Even putting the numbers in double quotes in the csv file and Excel STILL converts them to numbers and drops the trailing zeros.
But now you've said it is possible I've done a search and I can do Data->ImportExternalData and get the wizard.
Not only does it change things but, AFAICT, there are certain things that is is impossible to export and import via CSV from excel.
Strings that look like decimals are one. I cannot work out how to import strings like 1.10, 1.100 into Excel using CSV without it changing it to the number 1.1
I want this because I generate csv files for information about CVS versions. OOo you can say the column is text and it leaves it unchanges. Maybe there's a hidden option in Excel but I can't find it. (Excel 2003)
There are, of course, disadvantages as well. In particular, HVDC doesn't really work well for a grid, only for point to point links. So if you want to move power from one AC grid to another then HVDC makes sense (8GW link under the English Channel for example - note that England and France use the same frequency but different phase - and the angle (presumably) isn't constant - so you'd probably have to use a DC link although that could be just a few metres but once you've got both DC and AC it's cheaper to move power using DC than AC)
Imagine a new type of flash ram that can be in a low power, read only state or a high power read/write state per cell.
It also has the property that the low or high power state is initially selected based on the first access. Once the low or high power state is chosen it can only be changed again by going though a complicated procedure.
The compiler/system is allowed to assume that if it returns a block of memory from malloc etc that the first access will be a write. If you do make a read first then you will switch the memory into it's low power, read only state.
Or say the memory is paged. The first write operation causes a new page to be allocated from the swap file but if you start with a read then that causes the paging mecanism to always return 0xFF for that memory.
I'm not saying these are likely setups, but the C standard allows them.
No, it's not a bug. In C, if someone you passes you a buffer of a stated minimum size, there's nothing wrong with you reading from it. There's no such thing as "write only" memory.
Reading uninitialized memory invokes undefined behavior. Once you do that the compiler is allowed to do anything.
* Undefined behavior --- behavior, upon use of a nonportable or
erroneous program construct, of erroneous data, or of indeterminately-valued objects, for which the Standard imposes no
requirements. Permissible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving during
translation or program execution in a documented manner characteristic
of the environment (with or without the issuance of a diagnostic
message), to terminating a translation or execution (with the issuance
of a diagnostic message).
How a cascade of small failings lead to a major disaster.
OpenSSL leave in an "uninitialized memory read" because it "doesn't matter and might help". This is a bug. It does matter. The fact that all compilers will deal with this bug in a way that is OK is not sufficient in security critical code. Once you reach this point _anything_ can happen. If the compiler decides to flag this memory as read only and never modify it again then that is allowed. I can't imagine why a compiler or system would do something like this but it's allowed to. The OpenSSL code is non-portable and fragile.
And many people will be using this library in places where the memory is guaranteed to be initialized a particular way. Either this doesn't matter (in which case it doesn't matter if the uninitialized memory is initialized to a known state at the start) or it does matter in which case OpenSSL is broken on platforms where this memory is not random.
Debian spots this uninitialized read and tries to fix it. The proposed update is passed upstream but the email is ambiguous as to what exactly is required.
OpenSSL team do not jump on this. If the email went to the wrong address then the right address should have been provided (and the email forwarded as a courtesy). If this was an update to sensitive, critical code (which it was) then someone should have said "hold on there, this is sensitive code and introducing bugs here is really serious. We need a precise patch, we need time to evaluate the patch, we need time to work out how to fix the underlying uninitialized memory bug."
I haven't looked but has the underlying bug in OpenSSL been fixed even now? We've got an "undefined behaviour" bug in what we now know to be a critical path in OpenSSL. IMO Debian are doing the correct thing in fixing this bug if upstream hasn't fixed it.
Have Debian logged a bug with upstream? (Unfortunately, I suspect if they did this now it would "go political" - but I hope I'm wrong)
At the end of the day lots of people got things wrong. I feel particularly sorry for the Debian developer who appears to have done everything he reasonably could but still got caught out.
Running testing or unstable on your production servers is playing with fire. Period. That it was caught within 3 months of being moved to stable helps to put realistic damages in perspective, but I'd still think this should cause serious review of the package maintenance process at Debian.
Still running sarge on production servers here and I had a weak key with root access (added in the last week when I got an eeepc) and another with non-root access that was added over a year ago when I reinstalled my laptop with testing when etch was in testing.
The problem here is that people might be using "bleeding edge" software on their clients that they are using as terminals to maintain production boxes.
Standard practice is to generate the ssh key locally so that the private key never leaves the machine.
One of the things I will start doing now is including the date when an ssh key is generated in the public key comment. Putty does this anyway.
At home I've got certificates for imap which are probably weak. I also have smtp TLS certs that are probably weak including some on production servers. They are due to expire on 1st June anyway and it's a minor issue for me.
If this was just ssh using a weak session key then it's no big deal. But what are places like sourceforge going to do now? My key there is ok but are they going to check every key? Are they going to remove all the authorized_keys files? How are they going to stop people unknowingly re-uploading existing weak keys?
According to Wikipedia, http://en.wikipedia.org/wiki/Memristor M is a function of q. In the case where it's the zeroth power of q an memristor is the same as a resistor.
Instantaneously, a memristor behaves exactly like a resistor.
Galileo is intended to provide more precise measurements to all users than available through GPS or GLONASS, better positioning services at high latitudes...
It probably isn't obvious to Americans (continent, not just country) but I think this will be a good selling point in Europe provided the receivers are no more (or marginally) more expensive than GPS (something I think is unlikely because economies of scale won't kick in until there are lots of users and lots of people will be happy with GPS unless the extra logic can be added to GPS receivers for minimal extra cost)
Despite American (country) skyscraper image, the vast majority of America is open. Even in the middle of Manhattan the city is very open to the sky compared to the middle of London. Older GPS systems (I've got an old eTrex Summit) struggle to track a position at all in the City (I've never tried in Manhattan). I've got a newer Legend HCx which is better if it already has a position fix before you enter the City but not brilliant at acquiring a position fix if you turn it on in the middle of the city after moving it a significant distance while it is off. Also our roads are much narrower and closer together, and turnings tend to be much more complicated and not just right angles, making GPS inaccuracies more of an issue when navigating.
Europe is very much futher North that many people appreciate. Even Gibraltar, which is about as far south as you can get in Western Europe (Turkey goes a bit further South), is only about as far south as San Francisco. I think all of mainland Britain is North of the America-Canada border (49th parallel?). Anchorage is slightly further North than major cities like St Petersburg. The GPS satellite orbits are optimized to give a good position fix "close" to the equator (where close means south of the Canadian border).
I've never owned a TV but my partner's mother has one. It's a wide screen thing that, to me, seems excessively large for the size of room. Occasionally I see it when it's on and the picture is distorted (I presume that this is deliberate to fit 4:3 transmission) but worse, the distortion is non linear. So if someone walks off screen they accelerate as they move towards the edge of the screen. In true general relativity style, their nose starts accelerating first.
But none of this seems to cause any problems to the people who do watch this telly.
I much prefer a narrower column when reading. Infact, when lying in bed reading, which tends to mean that I'm not looking at the page square on, I find my eyes don't correctly return to the start of the next line if the page is wider than about A5. psnup or pdfnup are my friends here - I can easily read the same page printed at half the size.
I have the same problem reading a laptop screen in bed although I don't do that very often. Shrinking the window (although by choice I use a virtual terminal rather than X) doesn't help here because screens don't have a fine enough pixel density
(Note that a change of 1K only equals a change of 1C to the limits of experiment. They are not required to be the same. One is 1/273.16 of the temperature difference between absolute zero and the triple point of water, the other 1/100 of the temperature difference between melting ice and boiling water.)
Actually that's wrong.
Reading further 1 degree Celcius is defined to be identical to 1 degree centigrade and the triple point of water is defined to be 0.01C. So it's actually the melting point and boiling point that are not necessarily exactly 0C and 100C.
0 degrees C is defined as 273.15 degrees K (exactly).
No. The triple point of water is defined to be 273.16K
(Which is what the page you've linked to says now I look at it!)
The triple point of water is at 0.01C to the limits of experiment. Hence 0C = 273.15K to the limits of experiment.
(Note that a change of 1K only equals a change of 1C to the limits of experiment. They are not required to be the same. One is 1/273.16 of the temperature difference between absolute zero and the triple point of water, the other 1/100 of the temperature difference between melting ice and boiling water.)
And that quote just proves that the problem was insufficiently specified.
I make the assumption that the game show host wants me to _lose_.
Therefore, the only reason the game show host opened a door with a goat behind it is because I chose correctly the first time. Therefore I should NOT swap.
Now, Monty gives you the chance to switch envelopes. (Assume Monty always gives you the chance to switch.) Logically, since your envelope contains X, the other envelope can contain either 0.5X or 2X, with 50% probability... So the expected value of switching envelopes is 50% (0.5X + 2X), or 1.25X. So, you should switch.
This is wrong.
To avoid problems with infinities (which is a perfectly good solution) I set up the problem as follows.
In one envelope I have written A on a sheet of paper. I then tossed a perfectly fair coin. If it came up heads I wrote 2A on another piece of paper, otherwise I've written A/2. That went in envelope 2.
You now pick an envelope.
There are four cases all equiprobable:
You Other envelope A 2A A A/2 2A A A/2 A
So your expectation value if you don't swap is 9A/8
If you do swap your new expectation value is 1/4*2A + 1/4*A/2 + 1/4*A +1/4*A which, by some remarkable symmetry of mathematics, also comes out at 9A/8.
Your problem comes because you say "Assume the amount in the envelope is X" but X is not a constant. In one case when you double your money you gain an extra A while in another case when you double your money you only gain A/2. Likewise you lose A in one case and lose A/2 in another. You've said you gain X in two cases and lose X/2 in two cases
If we do assume the amount in the envelope is X then our expected gain is 1/4*X - 1/8*X - 1/4*X + 1/8*X = 0. i.e. as expected, there is no benefit in switching.
The percentages were a joke. But I do mean in all seriousness to suggest that psychology researchers are often averse to math and tolerate math errors in papers.
It's not just psychologists.
It's statisticians as well. People decide what they want to prove and then stop when they get a result they like.
A response to a paper by two statisticians showing that they've made a trivial error in their paper. And when the maths is done correctly it's obvious that the result is meaningless.
You've completely misunderstood the problem that ISPs are having.
The vast majority of their customers don't want to use their maximum available bandwidth all the time. I, for example, average something less than 2GB/month download on a 2Mb connection. So, in effect I'm using just three hours of what you would call my 720 hours per month of quota.
But an 8kb connection just wouldn't cut it for me. I could still download that 2Gb in a month but the web would be all but unusable. I'd be waiting minutes for the main page of slashdot to display.
There actually isn't really a problem with some people using a lot of their potential bandwidth except that if you've got two people with 2Mb connections sharing a line with 2008kb connection where one _averages_ 8kb and the other averages 2Mb the light user is effectively prevented from using the internet at all.
[car analogy] Consider a road that can carry 3600 vehicles per hour. You sell access to that road at a maximum of 3000 vehicles per hour. Now a whole load of people want to use the road and normally it all works fine. But now imagine if someone permanently tried to send their maximum vehicles. Once you're on the road you've grabbed that slot (similar to a P2P connection) so effectively they're limiting everyone else to 600 vehicles per hour because most of the time other people are not trying to access the road so the hog gets the 3000 vehicles/hour and has already filled up most of the slots. Someone who is as per
P2P works much like this. As soon as there is any available capacity the P2P client will grab it so others who want to use the internet in a bursty manner have to battle to get on in the first place and then, when they finish that burst, the small bit of bandwidth they've managed to get is immediately snapped up again by the P2P client.
So what IS the cost, per barrel, of pulling it out of the ground?
At current oil prices:
I think it's around five to six barrels of oil for each barrel of oil energy equivalent at the moment worldwide - meaning a lower bound of about $20 on average.
http://www.abelard.org/briefings/energy-economics.asp says tar sands are around 3:2 making a lower bound of around $66 (Note I have no idea of the reliability of that site - It was just the first hit on google on a search for "EROEI tar sands")
I WILL USE PREVIEW NEXT TIME I PROMISE (ok, not really ;-)
No. If you throw a ball mass m at velocity v relative to yourself (and v<<c) then you can still use 1/2*m*v^2 to calculate its speed relative to you.
But other (inertial) observers who think you are moving will not see the ball go v faster than you.
http://math.ucr.edu/home/baez/physics/Relativity/SR/velocity.html
I've not actually read through that page but given who's name is in the URL I'm confident it's correct:
Tim.
No. If you throw a ball mass m at velocity v relative to yourself (and vhttp://math.ucr.edu/home/baez/physics/Relativity/SR/velocity.html
I've not actually read through that page but given who's name is in the URL I'm confident it's correct:
Tim.
Why does wavefunction collapse violate SR? SR prohibits information traveling faster than light. The no-communication theorem http://en.wikipedia.org/wiki/No-communication_theorem (I'd always called this the no-signaling theorem) leads to the no-cloning theorem http://en.wikipedia.org/wiki/No_cloning_theorem so if you like, SR "explains" the no-cloning theorem. (The no-cloning theorem still allows a cloning fidelity of 5/6. Last I saw, fidelities of 0.81 had been achieved)
Back to the topic at hand, the interesting thing with special relativity is that while it was created based on the results of the Michelson-Morley experiment, it doesn't actually "explain" that experiment.
Maxwell's equations (see sig) predict that light will propagate with a speed c independent of frame. Einstein had a choice, Newton was wrong or Maxwell was wrong. A non-null result from the MM experiment would invalidate Maxwell's equations.
So, if you like, Maxwell's equations "explain" the null MM result.
Tim.
Can't make that work for me. I don't get the import wizard either way. In my case it's not leading zeros that are the problem but trailing zeros on numbers that look like decimals. (e.g. 1.10, 1.100)
Even putting the numbers in double quotes in the csv file and Excel STILL converts them to numbers and drops the trailing zeros.
But now you've said it is possible I've done a search and I can do Data->ImportExternalData and get the wizard.
Tim.
Tim.
Not only does it change things but, AFAICT, there are certain things that is is impossible to export and import via CSV from excel.
Strings that look like decimals are one. I cannot work out how to import strings like 1.10, 1.100 into Excel using CSV without it changing it to the number 1.1
I want this because I generate csv files for information about CVS versions. OOo you can say the column is text and it leaves it unchanges. Maybe there's a hidden option in Excel but I can't find it. (Excel 2003)
Tim.
Absolutely. And if you provide you DNA as part of a general hunt (for exclusion purposes) it STILL goes on the database and cannot[1] be deleted.
Tim.
[1] OK I think there has been about 3 instances in 3 million where someone managed to get it deleted.
http://en.wikipedia.org/wiki/HVDC#Advantages_of_HVDC_over_AC_transmission
There are, of course, disadvantages as well. In particular, HVDC doesn't really work well for a grid, only for point to point links. So if you want to move power from one AC grid to another then HVDC makes sense (8GW link under the English Channel for example - note that England and France use the same frequency but different phase - and the angle (presumably) isn't constant - so you'd probably have to use a DC link although that could be just a few metres but once you've got both DC and AC it's cheaper to move power using DC than AC)
Tim.
From the link in the FA:
...
http://blog.icann.org/?p=227
It is expected that the old address will continue to work for at least six months after the transition, but will ultimately be retired from service.
1st November 2007 -> 1st May 2008 is 6 months. So they left it a few days over 6 months
Tim.
It doesn't have to be the compiler.
Imagine a new type of flash ram that can be in a low power, read only state or a high power read/write state per cell.
It also has the property that the low or high power state is initially selected based on the first access. Once the low or high power state is chosen it can only be changed again by going though a complicated procedure.
The compiler/system is allowed to assume that if it returns a block of memory from malloc etc that the first access will be a write. If you do make a read first then you will switch the memory into it's low power, read only state.
Or say the memory is paged. The first write operation causes a new page to be allocated from the swap file but if you start with a read then that causes the paging mecanism to always return 0xFF for that memory.
I'm not saying these are likely setups, but the C standard allows them.
Tim.
No, it's not a bug. In C, if someone you passes you a buffer of a stated minimum size, there's nothing wrong with you reading from it. There's no such thing as "write only" memory.
Reading uninitialized memory invokes undefined behavior. Once you do that the compiler is allowed to do anything.
* Undefined behavior --- behavior, upon use of a nonportable or
erroneous program construct, of erroneous data, or of
indeterminately-valued objects, for which the Standard imposes no
requirements. Permissible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving during
translation or program execution in a documented manner characteristic
of the environment (with or without the issuance of a diagnostic
message), to terminating a translation or execution (with the issuance
of a diagnostic message).
Emphasis mine.
Tim.
In the old ANSI C standard (sorry I don't have the new one on my desk) it's in section A.6.2
Undefined behavior:
The behavior in the following circumstances is undefined:
* The value of an uninitialized object that has automatic storage
duration is used before a value is assigned ($3.5.7).
Tim.
How a cascade of small failings lead to a major disaster.
OpenSSL leave in an "uninitialized memory read" because it "doesn't matter and might help". This is a bug. It does matter. The fact that all compilers will deal with this bug in a way that is OK is not sufficient in security critical code. Once you reach this point _anything_ can happen. If the compiler decides to flag this memory as read only and never modify it again then that is allowed. I can't imagine why a compiler or system would do something like this but it's allowed to. The OpenSSL code is non-portable and fragile.
And many people will be using this library in places where the memory is guaranteed to be initialized a particular way. Either this doesn't matter (in which case it doesn't matter if the uninitialized memory is initialized to a known state at the start) or it does matter in which case OpenSSL is broken on platforms where this memory is not random.
Debian spots this uninitialized read and tries to fix it. The proposed update is passed upstream but the email is ambiguous as to what exactly is required.
OpenSSL team do not jump on this. If the email went to the wrong address then the right address should have been provided (and the email forwarded as a courtesy). If this was an update to sensitive, critical code (which it was) then someone should have said "hold on there, this is sensitive code and introducing bugs here is really serious. We need a precise patch, we need time to evaluate the patch, we need time to work out how to fix the underlying uninitialized memory bug."
I haven't looked but has the underlying bug in OpenSSL been fixed even now? We've got an "undefined behaviour" bug in what we now know to be a critical path in OpenSSL. IMO Debian are doing the correct thing in fixing this bug if upstream hasn't fixed it.
Have Debian logged a bug with upstream? (Unfortunately, I suspect if they did this now it would "go political" - but I hope I'm wrong)
At the end of the day lots of people got things wrong. I feel particularly sorry for the Debian developer who appears to have done everything he reasonably could but still got caught out.
YMMV.
Tim.
Running testing or unstable on your production servers is playing with fire. Period. That it was caught within 3 months of being moved to stable helps to put realistic damages in perspective, but I'd still think this should cause serious review of the package maintenance process at Debian.
Still running sarge on production servers here and I had a weak key with root access (added in the last week when I got an eeepc) and another with non-root access that was added over a year ago when I reinstalled my laptop with testing when etch was in testing.
The problem here is that people might be using "bleeding edge" software on their clients that they are using as terminals to maintain production boxes.
Standard practice is to generate the ssh key locally so that the private key never leaves the machine.
One of the things I will start doing now is including the date when an ssh key is generated in the public key comment. Putty does this anyway.
At home I've got certificates for imap which are probably weak. I also have smtp TLS certs that are probably weak including some on production servers. They are due to expire on 1st June anyway and it's a minor issue for me.
If this was just ssh using a weak session key then it's no big deal. But what are places like sourceforge going to do now? My key there is ok but are they going to check every key? Are they going to remove all the authorized_keys files? How are they going to stop people unknowingly re-uploading existing weak keys?
Tim.
According to Wikipedia, http://en.wikipedia.org/wiki/Memristor M is a function of q. In the case where it's the zeroth power of q an memristor is the same as a resistor.
Instantaneously, a memristor behaves exactly like a resistor.
Tim.
IIRC ECN caused similar problems for routers that didn't follow the specs.
Some sites because unreachable for some users over that one.
Tim.
Galileo is intended to provide more precise measurements to all users than available through GPS or GLONASS, better positioning services at high latitudes...
It probably isn't obvious to Americans (continent, not just country) but I think this will be a good selling point in Europe provided the receivers are no more (or marginally) more expensive than GPS (something I think is unlikely because economies of scale won't kick in until there are lots of users and lots of people will be happy with GPS unless the extra logic can be added to GPS receivers for minimal extra cost)
Despite American (country) skyscraper image, the vast majority of America is open. Even in the middle of Manhattan the city is very open to the sky compared to the middle of London. Older GPS systems (I've got an old eTrex Summit) struggle to track a position at all in the City (I've never tried in Manhattan). I've got a newer Legend HCx which is better if it already has a position fix before you enter the City but not brilliant at acquiring a position fix if you turn it on in the middle of the city after moving it a significant distance while it is off. Also our roads are much narrower and closer together, and turnings tend to be much more complicated and not just right angles, making GPS inaccuracies more of an issue when navigating.
Europe is very much futher North that many people appreciate. Even Gibraltar, which is about as far south as you can get in Western Europe (Turkey goes a bit further South), is only about as far south as San Francisco. I think all of mainland Britain is North of the America-Canada border (49th parallel?). Anchorage is slightly further North than major cities like St Petersburg. The GPS satellite orbits are optimized to give a good position fix "close" to the equator (where close means south of the Canadian border).
Tim.
Some people get used to anything.
I've never owned a TV but my partner's mother has one. It's a wide screen thing that, to me, seems excessively large for the size of room. Occasionally I see it when it's on and the picture is distorted (I presume that this is deliberate to fit 4:3 transmission) but worse, the distortion is non linear. So if someone walks off screen they accelerate as they move towards the edge of the screen. In true general relativity style, their nose starts accelerating first.
But none of this seems to cause any problems to the people who do watch this telly.
I much prefer a narrower column when reading. Infact, when lying in bed reading, which tends to mean that I'm not looking at the page square on, I find my eyes don't correctly return to the start of the next line if the page is wider than about A5. psnup or pdfnup are my friends here - I can easily read the same page printed at half the size.
I have the same problem reading a laptop screen in bed although I don't do that very often. Shrinking the window (although by choice I use a virtual terminal rather than X) doesn't help here because screens don't have a fine enough pixel density
Tim.
(Note that a change of 1K only equals a change of 1C to the limits of experiment. They are not required to be the same. One is 1/273.16 of the temperature difference between absolute zero and the triple point of water, the other 1/100 of the temperature difference between melting ice and boiling water.)
Actually that's wrong.
Reading further 1 degree Celcius is defined to be identical to 1 degree centigrade and the triple point of water is defined to be 0.01C. So it's actually the melting point and boiling point that are not necessarily exactly 0C and 100C.
Tim.
0 degrees C is defined as 273.15 degrees K (exactly).
No. The triple point of water is defined to be 273.16K
(Which is what the page you've linked to says now I look at it!)
The triple point of water is at 0.01C to the limits of experiment. Hence 0C = 273.15K to the limits of experiment.
(Note that a change of 1K only equals a change of 1C to the limits of experiment. They are not required to be the same. One is 1/273.16 of the temperature difference between absolute zero and the triple point of water, the other 1/100 of the temperature difference between melting ice and boiling water.)
Tim.
The definition of the kelvin scale is 0K is absolute zero and 273.16K is the triple point of water. These two points are by definition.
Now the triple point of water is 0.01C
Hence the melting point of ice is 273.15K
Note, therefore, that a change of 1K only equals a change of 1C to the limit of experimental error.
Tim.
And that quote just proves that the problem was insufficiently specified.
I make the assumption that the game show host wants me to _lose_.
Therefore, the only reason the game show host opened a door with a goat behind it is because I chose correctly the first time. Therefore I should NOT swap.
Tim.
Now, Monty gives you the chance to switch envelopes. (Assume Monty always gives you the chance to switch.) Logically, since your envelope contains X, the other envelope can contain either 0.5X or 2X, with 50% probability... So the expected value of switching envelopes is 50% (0.5X + 2X), or 1.25X. So, you should switch.
This is wrong.
To avoid problems with infinities (which is a perfectly good solution) I set up the problem as follows.
In one envelope I have written A on a sheet of paper.
I then tossed a perfectly fair coin. If it came up heads I wrote 2A on another piece of paper, otherwise I've written A/2. That went in envelope 2.
You now pick an envelope.
There are four cases all equiprobable:
You Other envelope
A 2A
A A/2
2A A
A/2 A
So your expectation value if you don't swap is 9A/8
If you do swap your new expectation value is 1/4*2A + 1/4*A/2 + 1/4*A +1/4*A which, by some remarkable symmetry of mathematics, also comes out at 9A/8.
Your problem comes because you say "Assume the amount in the envelope is X" but X is not a constant. In one case when you double your money you gain an extra A while in another case when you double your money you only gain A/2. Likewise you lose A in one case and lose A/2 in another. You've said you gain X in two cases and lose X/2 in two cases
If we do assume the amount in the envelope is X then our expected gain is 1/4*X - 1/8*X - 1/4*X + 1/8*X = 0. i.e. as expected, there is no benefit in switching.
Tim.
The percentages were a joke. But I do mean in all seriousness to suggest that psychology researchers are often averse to math and tolerate math errors in papers.
It's not just psychologists.
It's statisticians as well. People decide what they want to prove and then stop when they get a result they like.
http://injuryprevention.bmj.com/cgi/eletters/9/3/266#59
A response to a paper by two statisticians showing that they've made a trivial error in their paper. And when the maths is done correctly it's obvious that the result is meaningless.
Tim.
You've completely misunderstood the problem that ISPs are having.
The vast majority of their customers don't want to use their maximum available bandwidth all the time. I, for example, average something less than 2GB/month download on a 2Mb connection. So, in effect I'm using just three hours of what you would call my 720 hours per month of quota.
But an 8kb connection just wouldn't cut it for me. I could still download that 2Gb in a month but the web would be all but unusable. I'd be waiting minutes for the main page of slashdot to display.
There actually isn't really a problem with some people using a lot of their potential bandwidth except that if you've got two people with 2Mb connections sharing a line with 2008kb connection where one _averages_ 8kb and the other averages 2Mb the light user is effectively prevented from using the internet at all.
[car analogy]
Consider a road that can carry 3600 vehicles per hour. You sell access to that road at a maximum of 3000 vehicles per hour. Now a whole load of people want to use the road and normally it all works fine. But now imagine if someone permanently tried to send their maximum vehicles. Once you're on the road you've grabbed that slot (similar to a P2P connection) so effectively they're limiting everyone else to 600 vehicles per hour because most of the time other people are not trying to access the road so the hog gets the 3000 vehicles/hour and has already filled up most of the slots. Someone who is as per
P2P works much like this. As soon as there is any available capacity the P2P client will grab it so others who want to use the internet in a bursty manner have to battle to get on in the first place and then, when they finish that burst, the small bit of bandwidth they've managed to get is immediately snapped up again by the P2P client.
Tim.
So what IS the cost, per barrel, of pulling it out of the ground?
At current oil prices:
I think it's around five to six barrels of oil for each barrel of oil energy equivalent at the moment worldwide - meaning a lower bound of about $20 on average.
In the US, according to http://en.wikipedia.org/wiki/EROEI it's closer to 3:1 making a lower bound of around $33.
http://www.abelard.org/briefings/energy-economics.asp says tar sands are around 3:2 making a lower bound of around $66 (Note I have no idea of the reliability of that site - It was just the first hit on google on a search for "EROEI tar sands")
Tim.