HN user

pieguy

163 karma
Posts0
Comments28
View on HN
No posts found.

In statistics, "average" often means "expected value". No time frame is specified (although you could consider it an infinite time frame). With a small sample size your actual average might not be 10 minutes, but as your sample size grows, it will tend toward 10 minutes.

Let me say it again in a different way. My resolution of the paradox is that the prisoner incorrectly negates "x will happen" as "x won't happen" instead of negating "x definitely will happen" as "x might not happen". Thus,the prisoner cannot conclude that the hanging won't be a surprise. The prisoner can only conclude that the hanging might not be a surprise.

he believes he wouldn't be hanged at all

he assumes what the judge said is true

The judge says he will be hanged. Your comments are inconsistent.

He cannot logically conclude that. He can only conclude that either he won't be hanged or his hanging might not be a surprise.

No, it would not have been a surprise if he were hanged on Friday. The prisoner disproves the existence of a strategy for the judge that guarantees surprise, but does not disprove the existence of a strategy that gives the possibility of surprise.

Here's my take. The prisoner considers the statement "I will be hanged, and it will be a surprise", and after "proving" it false, takes its negation "Either I won't be hanged, or it won't be a surprise". But this is not correct. The prisoner actually disproves the statement "I will be hanged, and it will be a surprise no matter which day it happens". When you negate this statement, you obtain "Either I won't be hanged, or there is a day that it would not be a surprise", which is consistent with the outcome.

   (c(mod p)) (mod 2) = (p * q + 2 * r + m (mod p)) (mod 2) = 2r + m (mod 2) = m
This breaks if 2*r > p. Even if you choose r to be small during encryption, the r values accumulate with each homomorphic operation and will eventually be too big. The only restriction stated is that r is "from a different interval than the private key one". This should be made more clear.

I used to answer secret questions with bogus answers that I deemed unguessable. Then I discovered that when my bank asks me the questions back it does multiple choice, displaying the answer I gave along with 4 other possible options! Sometimes my answer would not be shown and the correct answer is "none of the above", but otherwise my answer sticks out like a sore thumb.

"(long)pow(a, len_s - (i+1))" is both inefficient and inaccurate. You should store the current power in a variable which you multiply by 'a' and reduce by 'm' on each iteration.

Also, your double hashing scheme has a bug. You identified that it's problematic if hash_b returns 0, but adding 1 to the result doesn't actually solve anything, because now you have the same problem if hash_b returns num_buckets-1.

I prefer the approximation (4+832/N), which gives its result in months. Not as easy to do in your head but it's quite accurate.

A couple years ago I saw a 3.5x improvement migrating a lockfree skiplist from hazard pointers to epochs. The problem with hazard pointers is that they require memory barriers after every assignment, whereas epochs only require one at the start.

IPSC 2014 problem E looks like a machine learning problem, but the intended solution was to make multiple submissions and use the judge feedback to reverse-engineer the test data. The winning team needed only 6 submissions to hit 95% accuracy. It was one of my favourite problems from the contest.

http://ipsc.ksp.sk/2014/real/problems/e.html

What many descriptions of the problem leave out is that it is critical that Monty knowingly picks a door with a goat. If Monty chooses at random, then the winning odds do indeed increase to 50% if he happens to open a door with a goat behind it.

The randomized variant, by the way, tends to garner roughly the same degree of "you're completely wrong" responses when given to people who know just enough about the normal Monty-hall problem not to be fooled by it.

Here's an iterative solution which is shorter and 3 times as fast:

  void iterative(int n)
  {
      int from[2][3] = {{0,1,2},{0,2,1}};
      int   to[2][3] = {{1,2,0},{2,1,0}};
      for(int i=1; i<1<<n; i++)
      {
          int disk = __builtin_ctz(i);
          int count = (i>>(1+disk))%3;
          int parity = (disk^n)&1;
          move(from[parity][count], to[parity][count]);
      }
  }

I participated in this contest, and solved this problem. The problem with the post is that it's basically saying "This correct ruby program is way slower than this incorrect go program, therefore ruby is bad for programming competitions". Obviously not a valid argument.