How much hashpower is needed to double-spend? Is >50% a minimum? How much hashpower is needed to double-spend coins?

Some worry only about one entity getting over 50% of the hashpower, while others are complaining (at the time of writing) about an entity having more than 33%. What is the importance of 50%? Can a double-spend be done with less?
No, 50% is not a minimum to double-spend. From the Bitcoin-Wiki


  Brute force attack
  
  This attack has a chance to work even if the merchant waits for some confirmations, but requires relatively high hashrate.
  
  The attacker submits to the merchant/network a transaction which pays the merchant, while privately mining a blockchain fork in which a double-spending transaction is included instead. After waiting for n confirmations, the merchant sends the product. If the attacker happened to find more than n blocks at this point, he releases his fork and regains his coins; otherwise, he can try to continue extending his fork with the hope of being able to catch up with the network. If he never manages to do this, the attack fails and the payment to the merchant will go through.
  
  The probability of success is a function of the attacker's hashrate (as a proportion of the total network hashrate) and the number of confirmations the merchant waits for. For example, if the attacker controls 10% of the network hashrate but the merchant waits for 6 confirmations, the success probability is on the order of 0.1%


When you have more than 50% of the hashrate, the succeed chance is 100%:


  >50% attack
  
  If the attacker controls more than half of the network hashrate, the previous attack has a probability of 100% to succeed. Since the attacker can generate blocks faster than the rest of the network, he can simply persevere with his private fork until it becomes longer than the branch built by the honest network, from whatever disadvantage.
  
  No amount of confirmations can prevent this attack; however, waiting for confirmations does increase the aggregate resource cost of performing the attack, which could make it unprofitable or delay it long enough for the circumstances to change or slower-acting synchronization methods to kick in.