The Big Short: Inside the Doomsday Machine is a very good book on the crisis. The Economist calls it "One of the best books on the recent crisis". I very much agree with this assessment. It's written by the former investment banker Michael Lewis who is the author of Liar's Poker and Moneyball.
You visit a family whose three children are all at the local school.
You don't know anything about the sexes of the children. While walking
clumsily round the home, you stumble through one of the three
unlabeled bedroom doors that you know belong, one each, to the three
children, and find that the bedroom contains girlie stuff in
sufficient quantities to convince you that the child who lives in that
bedroom is a girl.
Later, you sneak a look at a letter addressed to the parents, which
reads `From the Headmaster: we are sending this letter to all parents
who have male children at the school to inform them about the
following boyish matters'.
These two sources of evidence establish that at least one of the three
children is a girl, and that at least one of the children is a boy.
What are the probabilities that there are (a) two girls and one boy;
(b) two boys and one girl?
This is actually an interesting variation of the problem. If a random door opens but by chance happens to not have the prize, then the result is different.
But the GP is wrong. If a random door opens, then the odds are 1/2, just like the intuitionistic answer predicts.
There's a 1/3 chance you picked right, a 1/3 chance you picked wrong and a wrong door was revealed, and a 1/3 chance you picked wrong and the right door was revealed. Throw the last third out of your sample space and you get that the odds are 1/2.
This is what that forced Marilyn to admit the odds can be 1/2 on some readings of the problem, which was ambiguously phrased the first time it was printed. (But I think most people read the problem for the 1/3 solution and still came up with 1/2.)
That doesn't make any sense. The intentions of the host prior to opening the second door shouldn't have any impact on the odds of picking a winning door.
I could be wrong, but I think of it this way: You have a choice between picking one door, or picking two doors. If you choose to pick two doors, the host will happen to open one of them to reveal the non-prize. Irrespective of the differences between the wording of my problem and the MH problem, how are the actions different between the two?
Here's the flaw in your logic:
There's a 1/3 chance you picked right, and a 2/3 chance you picked wrong. In the 2/3 chance you picked wrong, there is a 1/2 chance of the correct door being revealed. No matter if the correct door is shown or not (in this case, it isn't shown), it doesn't change your original odds.
The intentions of the host pass you information that you can use to choose the correct door. The information is this: "There's a 2/3 chance I was forced to reveal this door; ergo, there's a 2/3 chance the other door is the correct one."
If the host is choosing randomly, no information is passed.
With regards to your last paragraph, the odds of the host picking wrong are either 1/2 or 0 depending on the intentions of the host. I'm a tiny bit annoyed that you think you're pointing out a "flaw" in my logic when you missed something so simple, but whatever.
If you don't like my explanation, direct your attention to the OP's link to Wikipedia, where there are many more variations and explanations that you might like.
Even in England it used to be commonly called Informatics. I like Informatics/Informatik/Informatique etc. much better than "Computer Science", because most applications are not really about computing, but about information.
In order to handle complexity, I split my program carefully into
modules with low coupling. I'm happy until a new feature comes along
which cannot be implemented without destroying the independence of the
existing modules. Then there are two options: Either I redesign the
system based on the new requirements or hack the new feature into the
old architecture. Both alternatives make me sad.
I recognize some repetitive pattern in my code. So I create some
straightforward abstraction that removes the redundancy. I'm happy
until the pattern appears again, but this time in some slightly
different form so that the old abstraction can't handle it. Then I
change the abstraction to include the new case. Eventually, I realize
that the abstraction has only complicated the system, because now one
has to understand both the implementation of the abstraction and the
use of it. This make me sad.
I'm working on some easy task. I know that I have solved problems like
this many times before. Unfortunately this time my brain just refuses
to solve the problem. Without solving the problem, I go home and think
about pursuing a different career.
On the next morning I solve the problem within 5 minutes and I'm glad
to be a programmer.
A good night's sleep is an essential part of my problem solving work flow. For smaller problems, I find a brisk walk can often break the mental logjam.
> Eventually, I realize that the abstraction has only complicated the system, because now one has to understand both the implementation of the abstraction and the use of it.
That's a real problem. The best abstractions are so useful, that they even help understanding when you only use them once.
E.g. functions come to my mind --- because they have clear entry and exit points (of control and communication), they can be easier to understand than the same code inlined.
(Functors and Monads also seem to enhance my understanding.)
Functions are indeed a good tool but at one point, they accumulate more and more parameters or more complex structures as parameters. Eventually, while you still understand the purpose of a function, it is difficult to understand all that it abstracts away.
I am just saying this because I totally relate to the article,it is often very hard to contain or abstract complexity. or it requires nearly equally complex mechanisms or abstractions.
Yes, a function should be short and sweet. This applies very well to functions in Haskell or Scheme (or words in Forth). Those languages (Scheme slightly less so) also have low syntactic overhead for defining a function/word.
It's OK for functions to grow more abstract. Just provide the simple things, too.
E.g. you start out with `map' and `filter', but then realize that `foldr' can express both of them and much more. One viable path is to rewrite the definitions of `map' and `filter' in terms of `foldr'. One should not use `foldr' everytime in the code where a `map' or `filter' suffice.
One can layer abstractions and then use the most specific tool possible that still has all the flexibility you need at each point.
As features accumulate over time, I find this is harder and harder to maintain. But it heavily depends on the situation (abstractions don't always hold as well as originally hoped). I guess I just remember more the times it goes wrong than the times it went right.
Oh, I often have to bang my head against the wall quite a few times, before I hit on the right abstraction.
Having more powerful abstraction techniques, like they are possible in languages like Haskell or Scheme/Lisp, tends to give less leaky abstractions for me.
I guess it means that average income (or whatever they are measuring) of X = 1/8 x Y. But is it a valid way to say this in English? In Finnish they use this sometimes in the newspapers and so, and I am thinking I need to get over it. But I still hate it.
It's kinda like "X is 8 times less expensive than Y", which I assume means X = 1/8 x X, but to me would make more sense as X = Y - 8Y = -7Y...
"Eight times poorer" is improper English and makes no sense, but is a very common usage. Most of the time multipliers are written when they should have used reciprocals. My only explanation is that it is more dramatic to say "eight" and "poor" in the sentence than "1/8" (hey, that looks like math, math is hard) and "rich" (they are emphasizing the poorness of the poor, not the richness of the rich).
Proper English, as I understand it, would be to say "they were 1/8 as rich" or "they have only 12% as much wealth", but that is much less dramatic.
Interesting. In Russian and Polish this kind of phrase is quite common. In German it's not common, and I would consider it bad style. How about English?
I think scalability and reliability are mostly orthogonal issues and
should be discussed separately.
Scalability is a farce. In my experience applications are implemented
in such hilariously inefficient ways, because it's hard to see where
the time and especially the IO is spent. But adding more machines is
not a good solution, because it becomes even more difficult to
understand the performance behavior of the system. Also, it transforms
the system into a distributed system and therefore adds a whole new
level of complexity and failure causes. Most websites don't have the
some problems as Google and Amazon.
Optimizing the application could prevent the need for scaling out to
multiple machines. Optimization is not rocket science: Find out the
bottleneck and fix it. Often it is random IO, so either load the data
into RAM or change the algorithm to use sequential IO (e.g. through
batch computation).
Reliability means that the system must work correctly all the time and
there is no way to fix it (e.g. a satellite on a mission). Thus, for
most applications availability, which is the fraction of time a system
works, is a more appropriate metric.
There are two basic strategies for achieving high availability in a
system: perfection and fault-tolerance. Perfection is the default
programming model, which assumes that every hardware and software
component of the system works as expected. Fault-tolerant systems, on
the other hand, are hard and require that the system is designed
around this idea. Also, fault-tolerance makes it harder to change the
system. An often overlooked fact is that for many systems it is
actually much easier to achieve a particular availability goal through
perfection rather than trying to build a more complex fault-tolerant
system.
Anyone has an idea if there is any way to distinguish random from sequential IO?
In my experience sequential IO is never the problem. Instead, it seems to me that random seeks are really the only performance problem nowadays. In the most extreme case throughput is only ~100Bits/s instead of ~100MB/s. Unfortunately random seeks are hidden behind abstraction layers and thus quite invisible to programmers (until the system freezes). Maybe we just need to wait for SSDs to become cheap.
Take a look at blktrace on Linux. It logs all block I/O layer activity from when an I/O request is sent to the disk to when it's serviced. It also outputs which sectors on the disk were written to service the request. People have written a few tools to read these logs and show meaningful numbers/pretty graphs -- btt is the official one, and here's another one that I like: http://oss.oracle.com/~mason/seekwatcher/.
Among other things, you can distinguish random from sequential I/O using blktrace and its accompanying set of tools by looking at the distance between subsequent I/O requests sent to the disk.
...and cheap SSDs are pathologically bad at random writes -- at least an order of magnitude worse than an mediocre hard drive on average, with regular latency spikes of several seconds!
