lambda

They mentioned what the training input to AlphaGo was in the paper; a database of a few hundred thousand games from dan ranked players on KGS. This means mostly amateur players, though there are a few professionals who play on KGS as well.

However, this only gets you so far, and the training set is fairly small compared to what you want to really train both the policy and value networks well. So then they had it play millions of games against different versions of itself, training both a new policy network and the value network based on that.

It's unlikely that Lee Sedol's games made much if any impact on AlphaGo's training. It was bootstrapped off of high-level amateur, and some casual pro, play, but from then on it just trained against itself.

No, they did not misrepresent the strength of the program. They did not know the strength of the program. The purpose of the match with Lee Sedol was to determine that.

So far, they have tested a previous iteration of the program against a much lower level professional, as well as all of the other Go engines they could test it against. It easily defeated all other Go AIs, but no previous Go AI has been able to compete at a professional level. It also defeated Fan Hui, the lower level professional, though it made several mistakes and lost a couple of the informal games (with lower time limits) it played against.

Since then, they've had several months to tweak it, and then let it train against itself some more. The thing is, to really determine its strength, you need to have it play serious games against professional players. So there really was no good way for them to determine its strength without playing these games. It's possible that it only would have improved a little since it's games with Fan Hui; in that case, the match with Lee Sedol may have been easy for him. However, it appears that it has improved substantially.

What has happened is that your transaction has propagated through the network, and some payment processor that they contract with has seen that transaction and confirmed that it has been sent out.

Since it hasn't been included in a block, it's not considered to have really happened yet. You could send out another transaction with a higher fee, sending the coins back to a wallet you own, and a miner could see that and decide to take the transaction with the higher fee over the lower one.

One thing that is preventing that from happening too much right now is that the default bitcoin software will refuse to relay transactions of coins that it has already seen, even if they have a higher fee, so it can sometimes be hard to do this in practice. But there's nothing that says this must be the case, in fact early versions did allow later transactions with higher fees to supersede older ones, and they are planning on re-introducing this feature as it will allow people to increase fees on stuck transactions if we start hitting the block size limit and transactions with lower fees start getting dropped by miners.

Or, even without this, you could have sent out two transactions simultaneously, one to the restaurant and one to yourself. If you happen to know which node it is that the restaurant is using (or at least figure out which nodes are topologically closer), you can send one transaction in that direction, and another to the rest of the network, and have a good chance of the one that sends coins back to yourself being the one that actually gets mined.

The Bitcoin protocol has always had a design that gave 10 minute average time between blocks being mined; which means 10 minutes before you have a single confirmation. It normally considers 6 block (6 confirmations, at an average of 10 minutes each) to be enough to avoid a double spend.

People can accept more risk by allowing transactions with fewer confirmations. But you are never going to get under 10 minutes on average (actually, since the difficulty only updates occasionally, when mining power is coming online fast enough it can go under 10 minutes average for a while; or a bit over if miners go offline).

Bitcoin is not, and never has been, designed for instant authorization. You cannot get global, cryptographic consensus in seconds. Credit card authorization can work by being much more centralized.

If you want fast confirmations of small transactions, you need to use something other than Bitcoin. What Bitcoin is good for is unstoppable bulk transfers of value across potentially unfriendly jurisdictions. It's better thought of as a better alternative to a wire transfer than an alternative to credit cards.

Rust:

  fn main() {
      println!("Hello, world!");
  }

C++:

  #include <iostream>
  
  int main() {
    std::cout << "Hello, world!";
  }

Meanwhile, you can use Rust now where traits (which fill a very similar niche to concepts) have been available for a long time, and are widely used in the standard library.

Of course, once you do, you find that some of the traits you would like to be able to use aren't expressible without "higher kinded types" (https://github.com/rust-lang/rfcs/issues/324), so there are still some big features that everyone kind of hopes will happen soon but there's no current plan for. But the existing trait system gets you pretty far for a lot of what you want to do.

No, the public has to be scared into standing by while the courts force Apple to unlock a phone for the FBI, so there will be adequate precedent for doing so later in in more mundane cases, like drug dealers, gangs, and so on.

The thing that scares law enforcement is that in recent years, they've been handed piles of easy evidence that is recorded permanently and easy to access. While before you actually had to do an active man-in-the-middle attack, known as "wiretapping", and that required a court order with good evidence, now there's a ton of communication that is already recorded on persistent media, and all they have to do is find some excuse for taking a look at it to get a lot of extra information without much trouble.

The term "closure" is used in Rust for that syntax, regardless of whether it actually closes over its environment. You need some term for the syntax, and closure is used even if it doesn't necessarily close over anything; because much of the time, you do use it because you want it to close over its environment.

And, you can pass a pointer to a function just fine:

  fn call_twice<F>(f: F) where F: Fn() {
      f();
      f();
  }

  fn hello() {
      println!("Hello");
  }

  fn main() {
      call_twice(|| println!("Hi!"));
      call_twice(hello);
      let x = 5;
      call_twice(|| println!("{}", x));
  }

And all of this optimizes down just fine; if the environment being closed over is empty, it will just be an anonymous function with no extra overhead. Heck, if you try it out yourself on the playpen in release mode, and take a look at the asm, all of these just get inlined right into main: http://is.gd/p9Kd9y

Should really use "git filter-branch", not "git rebase -i", for automated history modifications. "git rebase -i" is good for interactive usage, not scripting.

  A digital clock is a type of clock that displays the time
  digitally (i.e. in numerals or other symbols), as opposed 
  to an analog clock, where the time is indicated by the 
  positions of rotating hands.

https://en.wikipedia.org/wiki/Digital_clock

Don't use it day to day; we use Google Docs at my company, so that's what I happen to use for most of that kind of stuff.

But one day Google Docs happened to be down while I was doing a phone screen using Google Docs as a whiteboard for the candidate, and I'd heard about Sandstorm's Etherpad, so I signed up, launched that, and shared it with the candidate. Was quick and easy and we were able to go on with the phone screen.

When talking about a publicly traded company, "most valuable" generally means "market cap", and indeed, that's what it means in this case.

Of course, now that increasingly more work is being done on the client side, or by communicating with microservices, Rust makes more sense for a pure API backend. There's a lot less ecosystem needed there; mostly just bindings to whatever database you need to talk to, possibly some other stuff.

So if you're just going to be exposing a RESTful API backend for a JavaScript based frontend, or even for a Rails app frontend to talk to, Rust makes a lot more sense.

Also, the only way an ecosystem gets bootstrapped up is by people scratching their own itches. By starting to write web services in Rust now, and implementing those things that aren't yet implemented, you can help to bootstrap it up. Of course, that only works if you have the extra time to spare to do so, but for those things that only need one or two extra things that don't yet exist, it may pay off due to the lower chances of having to debug runtime errors, less time and complexity spent trying to make it scale out, etc.

I don't really see why it would be odd, other than the ecosystem not having quite caught up yet with some other languages. It's an expressive, high level language, which makes being explicit about error handling very easy, the type system makes it a lot easier to guarantee at compile time that a number of errors possible in dynamic languages will never happen, and it's quite efficient.

The efficiency and explicit memory ownership in Rust makes it a lot easier to avoid some of the scalability problems you run into in dynamic languages. The amount of material you can find online on people discussing hunting down memory leaks in Rails, or discussing how they just scale up by throwing gobs of RAM and extra servers at the problem or restarting their app every day or two, is all stuff that is much easier to avoid in a language like Rust. It is possible to leak memory in Rust, but due to how explicit you are about how memory is owned, it's less likely and more likely to be easier to track down if you do.

It is a bit more conceptual overhead to learn Rust than many dynamic languages, but I think that overhead is well spent as it can pay off in performance, stability, and maintainability later on.

I don't necessarily think that it's an either/or situation. I started out with dynamic languages, then did a mix of dynamic languages and C++ for a while (C++ engine with Scheme based scripting language), then went back to dynamic languages, and am now getting into Rust.

You are likely to have a mixed audience as well; even if not everyone has that mixed experience like I do, there will probably be a mix of people in the audience. So, it would probably be a good idea to have some examples and descriptions tailored towards those with a C++ background, and some towards those with dynamic language backgrounds.

He's a professional 2 Dan in the Chinese Weiqi (Go) Association (source: http://gobase.org/information/players/?pp=Fan%20Hui).

EGF and AGA have only just in the last couple of years started giving professional rankings, so most professionals in Europe and the US still have their professional rankings from China, Japan, or Korea, rather than European and American associations.

When someone calls that, they wouldn't expect the input to be consumed.

  >>> list = [1,2,3]
  >>> sum(list)/len(list)
  >>> Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  ZeroDivisionError: integer division or modulo by zero

> first neural network

https://en.wikipedia.org/wiki/Stochastic_neural_analog_reinf...

Like the difference between crossbows and longbows, they were superior in some ways and inferior in others.

Since they were composite, they were dependent on glue and cord holding them together; they were somewhat more susceptible to weather. They were also more expensive to produce. However, as recurves they had better power with less stacking (force required to hold them at a full draw), and they were also shorter so could be used from horseback, a huge advantage for a nomadic people on the steppes.

Your point is well taken, however, that the paper is really only comparing a very limited portion of Europe over a fairly limited amount of time. It's an interesting analysis, but I don't think it has enough data or broad enough application to make it definitive.

According to Wikipedia (https://en.wikipedia.org/wiki/Battle_of_Cr%C3%A9cy#The_Frenc..., and of course take with the same grain of salt applied to anything on Wikipedia, I don't have the sources on hand to cross check):

  The French army moved forward late in the afternoon, around 
  4pm after it had formed up. As it advanced, a sudden 
  rainstorm broke over the field of battle. The English 
  archers de-strung their bows to avoid the strings becoming 
  damaged; the Genoese with their crossbows could take no 
  such precautions, resulting in damage to their weapons.[26] 
  The crossbowmen began their advance, however they had left 
  their pavises back in the baggage train, and thus had no 
  means of protection as they loaded their weapons.[27][28] 
  The Genoese moved within range and discharged their 
  weapons. Damaged by the rain, the slackened crossbows had 
  little effect on the English line. The English archers shot 
  their bows in retaliation, inflicting heavy casualties on 
  the Genoese, causing them to retreat. The knights and 
  nobles following in Alençon's division, seeing the routed 
  mercenaries, hacked them down as they retreated. Froissart 
  writes of the event:

    The English, who were drawn up in three divisions and 
    seated on the ground, on seeing their enemies advance, 
    arose boldly and fell into their ranks... You must know 
    that these kings, earls, barons, and lords of France did 
    not advance in any regular order... There were about 
    fifteen thousand Genoese crossbowmen; but they were quite 
    fatigued, having marched on foot that day six leagues, 
    completely armed, and with their wet crossbows. They told 
    the constable that they were not in a fit condition to do 
    any great things that day in battle. The Count of 
    Alençon, hearing this, was reported to say, "This is what 
    one gets by employing such scoundrels, who fail when 
    there is any need for them."[29]

So, it doesn't sound like the crossbows were in pristine condition. Rather, their range was limited by the fact that their strings had gotten wet, while the relatively simpler (and easier to string) longbows were able to be protected from the rainstorm.

Hmm. I'd be interested in seeing your source for that. Yes, the power imparted to the arrow is the integral of the poundage supplied by the bow or prod, over the distance that it is propelling the arrow, and that distance is shorter on a crossbow than a longbow. But you can have a much higher poundage and still be usable with a crossbow; you have two arms to draw together, and are supporting none of the draw weight while aiming. I've seen the analysis of draw weights of longbows on the Mary Rose; do you know where there are sources for that of crossbows?

And yeah, sorry, I didn't mean to make it sound like they were just handing out longbows. Longbows do require significantly more training. In part, the tradeoff for longbows is that you have cheaper weapons but need to put more into training the archers.

First, this research paper is about a game theory analysis about a political situation that may have made the French and Scots leery of being vulnerable to usurpation by arming a large population. The material on pages 691-693 is all background material, not the actual research material of this paper.

I did read 691-693. I am not contradicting any of the information in it; merely saying that I think they are overstating the direct superiority of the longbow. Strategically and tactically, it's clear that arming a large number of archers and using them in the early battle is superior, and the cost and simplicity of the longbow makes that much easier; but it's not because a single longbow is better than a single crossbow. I think that the longbow was a superior weapon, in the sense that the armies that adopted the longbow strategy clearly beat those that relied on crossbows, but I think that the way that the paper couches its introduction makes it sound like, side by side, a longbow was a superior weapon to a crossbow.

I'm not talking about modern crossbows, I'm talking about reproduction medieval crossbows. I do medieval recreation as a hobby, I shoot longbow, I know people who shoot crossbow. The longbow is faster, though as I mention, I know people who can reload and shoot from the hip and get 6 accurate shots off in 30 seconds. And the crossbow is more accurate, gets better range, delivers more power, and is easier to shoot.

Now, I don't shoot a 160 pound warbow, I don't have the strength for it. If I did, I would get some more power and range out of it, at the expense of accuracy and speed, as I would fatigue much more quickly. With a crossbow, you can use both arms and brace against your hip to draw, so even without any stirrup or crank, you can shoot a much heavier crossbow than you could a longbow. That extra power means more penetrating power and a flatter quicker flight (or more range if you increase your angle), and the fact that your muscles are not straining to hold the bow drawn means you can aim more accurately.

I think that the way this paper discusses on the longbow as being the superior weapon may obscure a key fact here. Man for man, a crossbow is a superior weapon; requires less skill to operate, has longer range, much easier to aim, better penetrating power. The main advantage of a longbow is how simple and cheap it is.

Speed of reloading is another advantage the longbow has, but I think this article overstates it. While some crossbows do require using a stirrup or crank to load them, there are others that you can reload against your hips, and shoot from there, to increase your speed considerably, at some cost to accuracy. I know people who have managed to get 6 bullseyes at 20 yards on a crossbow in 30 seconds. Meanwhile, archers would not be firing at the maximum possible rate in battle; ammunition is a limited resource, and with the draw weights of warbows fatigue would set in quickly. Overall, with the archers they had and bows they had at the time, it is likely that the longbows were able to be a little faster than the crossbows, but it's not a night and day thing; and the range, accuracy, and penetrating power on the crossbows were better.

The simplicity became an advantage in a few battles, which came after substantial rainstorms that caused problems with crossbows more complicated mechanisms. But the main advantage was how cheap and fast to produce they were; you could easily arm a large populace quite quickly. In order to take advantage of the longbow, you had to do that; you needed a very large number of archers to effectively take advantage of longbows, while you needed fewer archers to be effective with crossbows. But because it was cheap and simple, it was feasible to do that.

I think that cost and simplicity of the longbows were their biggest advantage; speed perhaps a secondary factor, but the sheer numbers were likely to be more important.

There is, of course, an interesting parallel here with some trends in modern military spending. The Joint Strike Fighter is a technological marvel; one of the most advanced pieces of military equipment ever. However, they are staggeringly expensive, and not actually the best dogfighters in the sky. You wonder how much more effective spending that money on more and simpler weaponry might have been.

From the comment history, I don't think they are the same djb.

I've seen a few articles on it recently, and know of at least one couple in my social network that does separate beds.

It seems like my grandparents' generation slept in separate beds a lot, my parents' generation swung to the single bed model, and in my generation single bed is still more common but awareness of sleep issues is leading to some people starting to try out separate beds again.

The guidelines say:

  Please don't do things to make titles stand out, like 
  using uppercase or exclamation points

and:

  Otherwise please use the original title, unless it is 
  misleading or linkbait.

I think the idea behind this change in title is because the original is perceived as being linkbait; it has an explanation point, is very opinionated. The kind of thing that really tempts you to click through, or come and post a scathing rebuttal, because of how strongly worded it is.

Not saying I necessarily agree with the new title, but it is milder, and I think that in general moving away from clickbait titles is a good thing. There's enough clickbait junk going around the rest of the internet, having at least some standards at HN is fine.

I love how he says that it's not throttling, while comparing it to economy mode on a car. Which is, well, literal throttling to give you less performance but better economy.

I would not mind them offering the feature if they were honest up front about what it is. It is throttling; it is reducing the bandwidth available for particular downloads, in order to use less or none of your data plan. Now, there are still some net neutrality problems with the fact that certain service providers use none of your data allowance while others do still count against it.

But anyhow, why try to sell this as not throttling when that's exactly what it is; throttling, but you get some benefit in that you don't have to pay as much for those throttled streams?

  You can't make the 'necessary for terrorism' argument 
  when the surveillance directly subverts the domestic 
  government.

What prevents a member of the domestic government from being a terrorist, or having ties to terrorists?

SSN and credit card numbers should not be considered secret. Anything that must be shared with a third party in order to make some kind of transaction cannot be considered secret; compromises happen, and once compromised, there is no way to make them secret again.

Brian Krebs, as a high-profile author on security who actively antagonizes black-market groups on the internet, is a common target. He has had all of his basic personal information posted on the internet publicly for some time. The credit cards that were used for this attack were all old, disabled ones, since he disabled them after the numbers were leaked; but apparently PayPal still has them listed on the account and so you can use knowledge of them to "prove" your identity to PayPal.

Wouldn't implementing bash/zsh completions achieve the same result?