pieguy

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.

I don't think multi-algorithm is taken into account for multi-algorithm coins. Several coins have multiple independent mining algorithms each with their own difficulty, and need to be attacked simultaneously.

   (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.

Computerphile video on Chip+PIN fraud: https://www.youtube.com/watch?v=Ks0SOn8hjG8

This was the goal of The Underhanded C Contest in 2008.

http://www.underhanded-c.org/_page_id_17.html

On my machine this produces

  (STDIN)= 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8

Which is obviously not what you want. So I changed it to:

  echo -n "$password" | openssl sha1 -binary | xxd -p -u

There's a decent chance the passwords you found aren't the actual passwords either, considering how easy it is to generate collisions for the hash function.

"(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.

Not sure how you came up with 5 cents but I get $1.36: 4000 dollars/btc * 10^-8 btc/satoshi * 150 satoshi/byte * 226 bytes/transaction = $1.356 per transaction

The solution to 1.1 is incomplete - Alice can set p=1 and q=n

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.

A study published in Science in June 2014, described as "likely the most thorough and precise study that has been done on the performance of the D-Wave machine" and "the fairest comparison yet", found that the D-Wave chip "produced no quantum speedup".

https://en.wikipedia.org/wiki/D-Wave_Systems#Reception

The "quarter mile stretch of wall all to your own" reward already has over 16k backers. How are they planning to deliver when the wall is only 300 miles?

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.

I removed the free() call because it was crashing. I also added a cast to the malloc() because I was compiling in C++. Compiled with

  g++ -o hanoi hanoi.cpp -O2 -lrt

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]);
      }
  }

And what's the alternative for if(A && B){ x(); }else{ y(); }? Seems very easy to shoot yourself in the foot with this approach.

There are many interesting pages on this site. The brainfk and Intercal resources are a fun read, also the tiny executables. The Tile World downloads are a bit out-of-date though.

Congress tried this...and we got the sequester.

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.