phasmantistes

Valencia (between 14th and 26th) is timed at 13mph northbound in the morning, and southbound in the evening.

Yes, the starting kernel of its learning this time was a collection of human games. This has caused the Policy Network (which says "given this board state, these moves are worth investigating in more detail") to be biased towards more human-like moves.

But they're already working on a new version of AlphaGo which isn't trained on any human data at all. It starts by making truly random moves and improves from there. This will require much more processing time and probably an order of magnitude more "self-play", but it will probably result in truly novel strategies that aren't part of the current human metagame.

Given the 78 was a "divine inspired" move, and Demis tweeted that AlphaGo's mistake was move 79, my guess is that Black 78 was not in AlphaGo's search tree at all. It had pruned that move as being too "unlike what a human pro would do", and had not considered play beyond that point. Then it had to suddenly backtrack, drop its entire search tree, and start rebuilding from scratch. It took only a couple minutes to do so, but that's still not enough time to build up the depth and breadth of a tree that it had been constructing up to that point in the game. So it ended up playing a suboptimal move simply because Lee Sedol played a move that was simultaneously brilliant/strong and novel/unexpected, and it had to respond somehow.

With the exception of two classes (Clinic and Large Software Development, which are both explicitly about learning to work in large teams), all the group work you do in the Mudd CS program is pair programming. The groups are 2 people, and you're required to take turns "driving".

While I definitely experienced an unfortunate amount of "Pareto Groups" throughout my schooling, none of them were in the CS department at HMC.

> If it's admitting women it would not otherwise in order to meet its CS quotas, then it is lowering the standards.

I disagree. Say your standard is "I will only date people that are over 6 feet tall". Statistically, there is a smaller percentage of women who meet that standard than men. However, there are more men over 6' tall than you could date in a single lifetime. There are also more women over 6' tall than you could date in a single lifetime. So if you choose to date 50% men and 50% women, you're not "lowering your standards". You're just using additional criteria -- like the idea that you might want more variety than only dating people of one gender all the time -- to weight your decision making beyond drawing random lots.

You can say that the analogy doesn't apply. "I don't want to date people over 6' tall -- I want to date the tallest people". I challenge you to apply "the best" to academic criteria that are available during the admissions process. There's simply not enough resolution available to construct an absolute ordering over all applicants, so you have to bucket people somehow. And the top bucket contains more than enough people to select from without having to lower any standards.

You're right that I can't conclusively show that standards weren't lowered using coarse statistics. I'm working with the numbers that I have, and with the knowledge that Maria Klawe and the professors of the HMC CS department are acting in good faith. Their end goal is not "get more women into our CS program". Their end goal is "make the CS profession a welcoming place for everyone", and bringing more women into HMC is a stepping stone towards that goal.

> spending something on the order of $100k per additional woman in their CS program

I would love to see that piece. It goes against my expectations, but honestly you might be right. Can you try to dig it up again for me?

> randomized experiments (who is better placed to try that than Harvey Mudd?)

Actually, Mudd isn't well-placed to do randomized experiments. The population is too small. Also, you're suggesting conducting sociological experiments on sentient populations without their express knowledge or consent. That's something I -- and the school, I expect -- would like to steer clear of.

Ugh yeah that sentence made me cringe. It doesn't do the intro courses justice at all. As someone who has both taken and graded those courses, I'll try to clarify.

The intro courses don't consist of homework like "write a function which does X", and they aren't graded like "your function produced the correct output".

Instead, the homework consists of week- to two-week-long projects in which the student produces a moderately complex piece of code. Depending on the point in the semester, this could be anything from a collection of pure mutually-recursive functions, a self-contained class with a nice api boundary, a collection of classes to draw some graphics format, or something else entirely.

The homework is always done in pairs, and you're not allowed to work on it unless your partner is present for pair programming. During official lab timeslots, students are told to trade off "driving" (using the keyboard) every 15 minutes to half hour.

Finally, the assignments are graded both on whether they produce the correct output and the clarity and efficiency of the code.

Student pairs are switched up multiple times throughout the semester, and the graders/tutors ("grutors") spend significant amounts of time working with each pair and making sure that both members understand what's going on.

> Were admission rates loosened to accomplish the goals, or were they not?

They were not. The class of 2014 (admitted in 2010) consisted of 101 women and 95 men, having more women than men for the first time in the college's history. The following year it swung back the other way, with only 42% of the incoming class being female. In both years, the same percent of admitted students were valedictorians or salutatorians at their high schools. In both years, the 75%ile SAT and ACT scores remained the same. Admittedly, I don't have access to all of the data, but the numbers I have show that there was no loosening of admission rates.

> graduating the best CS students, regardless of colour, race or gender.

I maintain two counterpoints to this argument:

* Especially when you're talking on the scale of admitting 200 students a year (only ~40 of whom will be CS majors) the difference between the best 200 men in the country and the best 200 women in the country is exceedingly small, if it exists at all. So given that the school is going to admit 200 equally qualified people no matter what, it might as well admit them in the ratio that it chooses.

* That statement has an implicit assumption that individuals are the best CS students. With a few notable exceptions, this is not true in the wider worlds of academia or professional industry. Teams with diverse skill sets, view points, knowledge, and experience perform the best in both academia and industry. So rather than trying to produce the 40 best individual computer scientists every year, Mudd tries to produce the 40 best team players who will succeed and make their chosen teams better by a multiplicative factor, rather than just an additive one.

EDIT: s/colleges/highschools/ when speaking of valedictorians

The school primarily offers only STEM majors: Physics, Chemistry, Biology, Engineering, Computer Science, Math, and combinations of the above. It is associated with 4 other neighboring schools (Scripps, Pitzer, Pomona, and Claremont-McKenna), and so some students end up doing off-campus majors in History, Dance, Linguistics, or other fields, but that is comparatively rare (1 or 2 off-campus majors per graduating class, I think).

Yep, and Mudd actually does this as well. The example that comes to mind is that a bunch of students work with local FIRST Robotics and LEGO Robotics teams, including teams consisting entirely of women or of minorities.

First, you present this statement as though all the other conversations on HN about Harvey Mudd have come to the same conclusion. This is demonstrably not true.

Second, I'd like to encourage you to not describe recruiting and admitting women as "lossening admission rates". That's the kind underhanded, unconscious sexism that we're trying to avoid here. Even if I accept as true that a higher percentage of men are qualified to be admitted to HMC's CS program (which I don't, but for the sake of argument...) the absolute number of people -- men, women, and otherwise -- who qualify is so much larger than what HMC can support that it could admit a class of 0 men and not have to worry about "lowering its standards".

It sounds like you've lost sight of the forest for the trees. Sure, a larger school might be able to have a larger impact. Sure, maybe Mudd isn't doing as much as it could, or is spending more money than it should. But it is still doing something demonstrably effective, which is more than most places can say.

That's actually not what blinkingled said. They said that some people here are using it as marketing for Apple, not that Tim Cook or others at Apple intended for it to be taken that way.

I was actually shocked two weeks ago when I was talking to someone about Gerrit and they complained that their comments were never addressed. Turns out they hadn't been hitting the "Publish Comments" button, and had been assuming that every draft comment they left was being sent as an individual email.

This taught me (or reminded me of) two things:

* GitHub is so dominant that even its poor decisions are being enshrined as "the way things work"

* Gerrit really needs some UI love as well.

Oh, that's absolutely true. There are far too few people stepping forward to fill non-technical roles in OSS. And that's a shame, because I think it would really help get some projects off the group, and help others keep their communities together.

But I didn't say "surely someone can just volunteer". I said that they should "get someone to join". There are a lot of ways to do that, and many of them involve the current team members being proactive about going out and trying to recruit someone to fill that role. The OSS communities can't just rely on the "if you build it they will come" philosophy -- if you really want your project to grow, you have to be willing to put yourself forward and actively get people to help you.

Yes, I've read both the full comment thread in the OP and the dear-github letter.

GitHub adding those features would be a huge boon for teams like this. And honestly, it may be that switching to a different system is the best move for this team. If their motivation is "we need features which GitHub has been unwilling or unable to provide", that's a great reason to move.

But, as I quoted, they also say that they want to move to another system because it will put up artificial walls and isolate them from the people that are currently inundating them with issues. I think that's a bad reason to move. Both because I think it will be ineffective, and because I think it represents bad faith towards their users and community.

Believe it or not, there are professional PMs who are just as interested in open source in their free time as some professional software engineers are. I'm not one of them -- I'm an engineer -- but I know some.

> If we move off GitHub, we will immediately eliminate the random noise we get through issues.

> At the same time, we'll eliminate drive-by pull requests that also need reviewing.

I don't think these are good reasons to move away from GitHub. If your project is truly popular, then the people who are filing these issues will follow you to your new home. You'll get a short period of respite, and then you'll be back where you were before. If your project is only popular because you're on GitHub... then moving off will not only give you a respite, it will also destroy your user base.

This is why full-time software engineering teams have PMs. They act as an API for the engineers: helping others understand what sorts of requests can be made, what kinds of responses can be expected, and turning away abusive/malformed traffic.

It simply sounds like this project is popular enough (and >5000 issues in just over 2 years certainly qualifies as popular in my book) that it needs non-engineering attention. Get someone to join the team who wants to fill in a PM role.

Keep in mind the perspective of the people trying to ship Firefox:

* The bug does not break the vanilla (and therefore vast majority of userbase) firefox experience

* The bug is easily worked-around (as opposed to completely unfixable)

* The release candidates were already being built (which means you don't want to make changes, because you have to rebuild+resend to manual QA+resign)

* The bug was merged in as part of a security fix which they can't risk touching

They're not necessarily out of touch. It could easily be that people who didn't have all the details (e.g. release managers who didn't realize the fix was re-adding a single trivial file) were worried about the risks of upsetting a security release.

Sometimes it takes time for the severity of a regression to work its way up to a decision maker. And in the end they did exactly the right thing, with 5 separate people all putting in work on a weekend to make it right.

Aha, that actually makes a lot of sense. I was only thinking about which numbers should have unique names, not whether the names we've given them make sense for their positions. Thanks!

In regards to the difference between American and European billion/trillion/etc:

  // These number terms were described by N. Chuquet and De la Roche in the 16th
  // century as being successive powers of a million.  These definitions are 
  // still used in most European countries.  The current US definitions for these
  // numbers arose in the 17th century and don't make nearly as much sense.

Huh? Admittedly I'm biased, being American, but how do the American definitions not make nearly as much sense?

By the time "billion" was defined by Chuquet and De la Roche, the concepts of "ten thousand" and "hundred thousand" were in widespread use. Those were followed by "million". So there's already a precedent for "we multiply things by a hundred before coming up with a new name". How does it make sense to change that to "but after a point, we multiply things by a thousand before coming up with a new name"?

I could see a couple systems that would arguably make more sense:

* ten, hundred, thousand, million, billion, trillion... (no multipliers)

* ten, hundred, ten hundred, thousand, ten thousand, hundred thousand, million, ten million, hundred million, thousand million, billion..., million billion, trillion... (use all previous multipliers before creating the next new name)

Admittedly, the US uses neither of those systems. But sticking with the precedent of "a hundred is the highest multiplier" makes sense.

Honestly I use ChromeOS + SecureShell and connect to a workstation from wherever I am. No Crouton or SSD necessary.

This is both cool and disappointing. I'm sure this is more challenging than it looks, and it's cool to see emergent complexity from a (seemingly) simply set of conditions to satisfy.

However, the reason I think about elevator programming isn't to make an elevator behave the way they do today. It's to make an elevator behave better than they do today.

For example:

* I don't want an elevator to close and reopen its doors on the same floor. That's horrible user experience.

* All the interesting problems arise when there are multiple elevators servicing the same set of floors. So let's control more than one elevator at the same time.

* If the elevator is on the ground floor, and has downward calls on both the 1st and 20th floors, then it is likely more efficient to service the 1st floor first rather than bypassing them just so you can keep travelling in the same direction.

I'd like to see a version of this that, rather than enforcing arbitrary rules, just has a lot of series of inputs and lets people compete to service those inputs in the shortest number of steps.

That's not really an accurate representation of the old proof. You've turned it around to make it look like the new one, but that's not how it is originally laid out at all.

The fundamental problem (for constructivists) with Euclid's proof is that it assumes the existence of a set of all primes, and then proves that that set is incorrect (either contains a composite, or doesn't contain at least one specific prime).

Saidak's proof, on the other hand, only assumes the existence of a single integer, and then constructs infinitely many primes from that integer.

Your restatement of Euclid's proof is basically "look, Euclid and Saidak proved the same thing", not "look, Euclid's proof is constructive too".

I was discussing copyright last night and proposed this exact same idea -- declare intellectual property to be, well, property, and subject it to a property tax. Require disclosure of what percentage of your revenue was due to that IP (or what percent of your total worth, or similar) and use that to determine the value of the IP. Then tax that value just like we tax real estate.

Does anyone know what the "anthropometric requirements for both the specific vehicle and the extravehicular activity mobility unit" are? I assume there are both maximum and minimum heights, but weight probably isn't a direct factor (just a factor as it affects your girth). Anyone have numbers?

That's the beauty of relativity, and why it is called relativity: it's all relative.

When you go fast, and look outside, it looks like it is the outside that is moving fast (unless you are experiencing acceleration, at which point General Relativity kicks in). Therefore, to you, it looks like time outside is moving slower.

When the space boats are doing their thing, to us on the outside it looks like they are moving fast. Therefore, to us, it looks like time for them is moving slower.

Which is, in fact, exactly the model of Google Contributor.

Puts $5 each month into a bucket, and then each time you visit a site you pay a few cents in order to have an ad-free experience.

Very little goes through google's servers, actually. "Casting" something from your phone/tablet to the chromecast is just sending it a url (and a timestamp if you were already watching on your phone). Then it streams locally.

So, for example, you can stream from Plex and not touch Google servers at all.

This is fantastic. Thanks, Keybase!

I've kept my private key on a single device because that's the easiest way for me to secure it... but it means that I haven't used keybase to actually secure communications much because that device is my nice big linux desktop... not my handy laptop or phone or any of the other devices that I spend more time communicating from.

Really looking forward to the Android app.

I think this is the best tracking bug: https://code.google.com/p/chromium/issues/detail?id=465929

There are three things going on:

1) Rietveld exists

2) A new Polymer-based UI for Rietveld exists

3) Gerrit exists

The bug linked above is about evaluating the ability to make the Polymer-based UI (which is pretty and functional) work on top of Gerrit instead of on top of Rietveld. This is one of the possible paths forward for getting people to use Gerrit, and the one for which external contributors could be the most help.

Other paths forward exist: making Rietveld and the polymer Rietveld UI so good that no one wants to switch to Gerrit anymore; working directly on the Gerrit UI; or convincing devs that the Gerrit UI is good enough. But I think the bug and description above is the path on which external contributors could do the most good.

There are no branches in the golden-source-of-truth repository (except for release branches, but those are never merged back into master and no development is done directly on them). The only branches that exist are on the developer's local machine, and only exist for that developer's personal preference and bookkeeping.

Yes, it is totally possible for two developers to be working in the same place and try to land their changes at the same time, resulting in a conflict. This happens in one of three ways: a) dev B's change fails tests, because the try bots which try to test dev B's change have already sync'd dev As change (this is the most common) b) dev B's change passes all the tests, but fails to commit because dev A's change landed seconds earlier. In this case the system sends dev B an email asking them to rebase their change and try again. Simple. c) dev B's change passes all the tests, then lands and causes tip-of-tree tests to fail because dev A's change landed seconds earlier and they disagree on the name of an API method or something. This happens rarely, and is easily resolved by reverting one of the two and asking the author to try again.

Anyway, the point is that the dev branches are incredibly short lived: they exist only on the developer's machine and end up as a single, coherent, self-contained commit on master. If you get far enough behind that your stuff doesn't apply on master, it is your responsibility to clean it up, and no one else even knows that you had a conflict.