Hacker Newsnew | past | comments | ask | show | jobs | submit | ricardoz17's commentslogin

When reading "Thinking, Fast and Slow" one of the things that struck me was that if you use the reference point for gains and losses as the point you end up at then you would have a pretty good model. For example if you have a hundred and lose 20 your loss is 20/80 but if you win 20 your gain is 20/120 [1]. The formulas is x/(x+worth)

I set up a python fiddle to mess about with this: http://pythonfiddle.com/st-petersburgh-paradox

One of the interesting things I found was that there is a power law for how much you would be willing to play the game. There are two ways to run the figures.

One is to never update your worth which produces (1,2.31)(2,5.80)(3,9.38)(4,12.78)(5,16.10)(6,19.43) - where (1,2.31) is an original worth of 10^1 and an expected value of 2.31.

The second is to update your worth after each winning bet: (1,1.94)(2,5.00)(3,8.48)(4,11.80)(5,15.11)(6,18.43)

In both instances a 10x increase in worth increase the expected value about 3.3-3.5. This may explain after you factor in the enjoyment of playing that it is rational for poorer people to play the lottery.

[1] One thing I didn't like about Prospect Theory is the steep curve for a loss this does not explain why people are so ready to buy insurance. If you use the above model if you could lose 90% of your value then -90/(-90+100) gives -9 and if you have to pay 1% then -1/(-1+100) gives -1/99 so you would do that for a 1/891 chance


Except when its an "Exception that proves the rule" - http://en.wikipedia.org/wiki/Exception_that_proves_the_rule


What I meant is you don't turn an exception into a generally applicable rule, but rules can infer exceptions.


Twitter does something similar with 3rd-party authentication. The user puts in their name and password but then the rest of the process can be done by a bot. 1. click on a button to confirm granting access 2. provide the code in an image to he App but the HTML for the code hass the following:

<span id="code-desc">Next, return to TrainerLists and enter this PIN to complete the authorization process:</span>

<kbd aria-labelledby="code-desc"><code>7996044</code>


I think the swapping two variables has a bit more going for it if they do not know the trick. Explain the concept of invertible functions. Hopefully they would be able to come up with plus and minus - even if you have to walk them through the a=f(a,b) b=g(a,b) a=g(a,b)

From there you can say that works fine with pen and paper but why might it go wrong in a program? So how do you avoid integer overflow? If the signs are the same then use subtract first else use addition first. After we have done that. After this step assume I have returned to the main flow. How do I check if I should use addition or subtraction? If a is bigger than b I must have added so use subtraction. Writing the algorithm this way is trickier than xor. The problems to be solved are to do with understanding concepts

Next you have the xor solution but more important than getting the answer to that might be to see if they can see that the two functions are like encrypt and decrypt where a is the message and b is a key and a + b is the ciphertext c - so that f(m,k) is encrypt and g(c,k) gives the message and g(c,m) gives the key. If they have had any exposure to cryptography then xor should present itself.

If they give xor straight off then you can work backwards.


You're missing the point, and this is how people end up at these "puzzlers". The point of fizzbuzz or the simple questions is to weed out people who can't code at all. If you transform it like you do above, then you're testing something else: how well people know low-level tricks like swapping variables using xor.

Those tricks might be valuable in your workplace, and may make excellent interview questions for you, but they are a very very different type of question than fizzbuzz, at least in purpose, even though they may look superficially similar. In a fizzbuzz type question, you are not looking for brilliance, you are looking to just weed out the people who can't.


Exactly. This is precisely the problem. It's not that any particular question is a "bad" choice, per se, it's that interviewers can fail to realize what they are actually testing for.


XOR trick? I'm not sure I'd want to work for someone who didn't know about the x86 xchg opcode.


I had never seen the XOR algorithm and after seeing the parent post grabbed a pencil and paper and tried to come up with something. Took a couple minutes and I consider myself a middling programmer.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: