Comment author: skeptical_lurker 28 September 2015 09:47:59PM *  11 points [-]

There are sometimes controversial discussions here, and I wonder how these conversations play out at meetups. Do you ever get an anarchist, a communist and a neoreactionary turning up to the same meeting? If so, does it cause problems? Or, indeed, do discussions about dust specks/torture or other controversial but apolitical topics ever get heated?

LW seems far more cool-headed than the rest of the world, and I am wondering to what extent it might be partially due to being online.

Personally, I have only gone to a few meetups, but I think I have managed to offend people :(

Comment author: ShardPhoenix 29 September 2015 09:30:30AM *  4 points [-]

Do you ever get an anarchist, a communist and a neoreactionary turning up to the same meeting? If so, does it cause problems?

I've been part of some arguments between libertarians and socialists. They got moderately heated but not severely so. Rationality-wise they seemed better than I've experienced in other communities, but still pretty far from a cool-headed ideal. To be fair I've also had some somewhat heated arguments over more abstract philosophical issues, though with few hard feelings.

Comment author: TheMajor 15 September 2015 07:18:04PM *  2 points [-]

I am confused by section 5 in the paper about probabilistic generation of the search tree - the paper states:

Testing showed that a naive implementation of probability-limited search is slightly (26 +- 12 rating points) stronger than a naive implementation of depth-limited search.

But the creators of the most popular engines literally spend hours a day trying to increase the rating of their engine, and 26 rating points is massive. Is this probabilistic search simply that unknown and good? Or is does the trick lie in the "stronger than a naive implementation of depth-limited search", and is there some reason why we expect depth-limited search to have sophisticated implementations, but do not expect this for probablistic search?

Comment author: ShardPhoenix 15 September 2015 11:47:54PM *  1 point [-]

Or is does the trick lie in the "stronger than a naive implementation of depth-limited search", and is there some reason why we expect depth-limited search to have sophisticated implementations, but do not expect this for probablistic search?

Something like that I think. The paper suggests that optimizations applied to depth-based search techniques in more sophisticated engines are already effectively like an approximation of probability-based search.

Comment author: V_V 15 September 2015 09:07:26PM -1 points [-]

Although it's not better than existing solutions, it's a cool example of how good results can be achieved in a relatively automatic way - by contrast, the evaluation functions of the best chess engines have been carefully engineered and fine-tuned over many years, at least sometimes with assistance from people who are themselves master-level chess players. On the other hand this neural network approach took a relatively short time and could have been applied by someone with little chess skill.

But how much of its performance comes from the neural network learning some non-trivial evaluation function and how much comes from brute-forcing the game tree on a modern computer?

If the neural network was replaced by a trivial heuristic, say, material balance, how would the engine perform?

Comment author: ShardPhoenix 15 September 2015 11:31:19PM *  2 points [-]

In the paper they start with just material balance - then via the learning process, their score on the evaluation test goes from "worse than all hand-written chess engines" to "better than all except the very best one" (and the best one, while more hand-crafted, also uses some ML/statistical tuning of numeric params, and has had a lot more effort put into it).

The reason why the NN solution currently doesn't do as well in real games is because it's slower to evaluate and therefore can't brute-force as far.

Comment author: redding 14 September 2015 07:52:17PM 7 points [-]

I think this is pretty cool and interesting, but I feel compelled to point out that all is not as it seems:

Its worth noting, though, that just the evaluation function is a neural network. The search, while no long iteratively deepening, is still recursive. Also, the evaluation function is not a pure neural network. It includes a static exchange evaluation.

It's also worth noting that doubling the amount of computing time usually increasing a chess engine's score by about 60 points. International masters usually have a rating below 2500. Though this is sketchy, the top chess engines are rated at around 3300. Thus, you could make a top-notch engine approximately 10,000 times slower and achieve the same performance.

Now, that 3300 figure is probably fairly inaccurate. Also, its quite possible that if the developer tweaked their recursive search algorithm, they could improve it. Thus that 10,000 figure I came to above is probably fairly inaccurate. Regardless, it is not clear to me that the neural network itself is proving terribly useful.

Comment author: ShardPhoenix 14 September 2015 11:34:48PM *  9 points [-]

Although it's not better than existing solutions, it's a cool example of how good results can be achieved in a relatively automatic way - by contrast, the evaluation functions of the best chess engines have been carefully engineered and fine-tuned over many years, at least sometimes with assistance from people who are themselves master-level chess players. On the other hand this neural network approach took a relatively short time and could have been applied by someone with little chess skill.

edit: Reading the actual paper, it does sound like a certain amount of iteration, and expertise on the author's part, was still required.

edit2: BTW, the paper is very clear and well written. I'd recommend giving it a read if you're interested in the subject matter.

Comment author: SodaPopinski 03 September 2015 05:11:14PM 5 points [-]

What is the best way to handle police interaction in countries you don't live in? In the US it is generally considered pretty wise to exercise your right to be silent extensively. Now obviously in some really corrupt places your just going to have to go along with whatever they want. But what about the different countries in Europe? My instinct would be to respectfully tell the officer I would like to call my embassy (and have that number with me!).

Comment author: ShardPhoenix 05 September 2015 10:41:10AM 4 points [-]

I've never been in this situation, but one question I'm confused about is how both sides arrive at an appropriate-sized bribe. What's the stop them taking everything you have?

Comment author: ShardPhoenix 08 August 2015 07:56:27AM 3 points [-]

Did you accidentally edit out the beginning of your post?

Comment author: btrettel 05 August 2015 01:56:34PM *  3 points [-]

If you're suggesting that I say I don't think branching is useful because I can't do it well in svn, or something like that, then I can't say much other than that you're mistaken. If you're not suggesting this, please clarify.

Yes, I have learned about branching workflows. I decided that they don't make sense for most of my repositories. For example, the repository I commit most often to is primarily a collection of text outlines on a variety of subjects. How would a branching workflow help me here? It wouldn't. In the 3 years I've been using this repository, branching never seemed like a good idea. Branching just seems like extra friction in the process. My impression is that many git people probably would branch in this case, and I don't understand what benefits they get from that. If you're aware of any, I'm listening.

The larger project my PhD is a part of uses git with a pretty standard git workflow, which I agree makes sense for the project. My claims are that large software projects have different requirements than small software/documentation projects, and that you might find different tools to be useful in each case.

Edit: If you thought the hammer sentence was snark, sorry for that. It was my attempt to explain why some people who use git might branch more often than is needed.

Comment author: ShardPhoenix 06 August 2015 08:25:51AM *  0 points [-]

If you don't need git's features it's fine not to use it. I just brought up branching because you left it out of your comparison, but IIRC it's the main reason git was even created.

Comment author: btrettel 04 August 2015 01:24:25PM *  1 point [-]

If you really need to branch then svn is the wrong tool to use, because branching makes a lot more sense for distributed systems. For the repositories I use svn for, I never once have had to branch in any complicated way. If I needed to branch in a significant way, I'd use git or hg. The most I've done is "branching" a file by duplicating it, and then later merging in the changes with a graphical diff tool. At this level, git is no easier or harder than svn, though you might consider this approach to be sloppier than git's approach.

Talking to some git people gives me the impression that they branch way more often than is necessary, though. Maybe if you have a hammer, everything looks like a nail.

Comment author: ShardPhoenix 05 August 2015 03:04:07AM *  0 points [-]

Maybe if you have a hammer, everything looks like a nail.

Those grapes are probably sour anyway.

edit: To make a less snarky contribution, there's always a difficult balance between "those people are doing something that seems weird to me, I should probably just ignore them and go my own way" vs "if smart people are doing something that seems weird, it's probably for a good reason, maybe I should learn it".

Comment author: btrettel 02 August 2015 11:40:50PM *  2 points [-]

In my view, svn has a number of benefits over git. Let me offer a quick runthrough of why I prefer svn for small projects.

The main reason to use svn in my view is simplicity. git can't do many things svn does with as little friction as svn requires.

Centralized version control is definitely simpler than distributed. Distributed can be useful if you want to develop a feature offline (and find the svn ways of doing that to be a pain, as I do), want to work on something independently for a while, want to work on an experimental branch, etc.. But there's a good reason to prefer centralized in some cases. Distributed version control is too confusing for many people you might want to collaborate with. My research group has enough trouble getting my PhD advisor to use svn. Do you think this will be easier with git?

The documentation for git is pretty bad. In contrast to svn, I can't rely on the documentation for git making sense and basically have to Google for many things, even some things which are straightforward in svn (like svn keywords). The Pro Git website is pretty good, however.

One thing I like is having a incrementing number that refers to a unique version. You actually can get that in git, but it's a complicated command that I've never seen used in real life. This is just how svn works.

Let's say you are using git just want to print the hash and date of last modification in your code or document. svn has a keyword functionality to do this automatically when you update. git makes this at least moderately complicated (for silly reasons). There are several ways to do this, but editing the file directly with a script is unsatisfactory because the file will show up modified, unless there's some git way around this. In svn the files show up as unmodified. You also could pass in the hash at compile time, which is just extra work over svn.

I have heard conflicting things about partial checkouts in git. My impression is that they work but are more complicated than svn. Partial checkouts are totally normal and easy in svn. I do them fairly regularly, as well.

GUIs for git were still underdeveloped last I checked, or at least the free ones were. GUIs make a number of things much easier. At one point I started converting my repositories over to git because I wanted to work offline more often, but the lack of good GUIs made me stick with svn. (I have some other restrictions here that made some GUIs not attractive, and maybe I should look into this again.)

Here are the advantages I see to git/github: pull requests being code reviews and the distributed nature of the software. The former is great, as problems are caught early. The latter is not always an advantage, as I explained earlier, but generally is a major advantage in large projects.

To be honest, I could see myself changing my mind over this in the future, but for now I see no reason to switch from svn to git for most of the repositories I have.

Comment author: ShardPhoenix 04 August 2015 12:59:03PM *  1 point [-]

The big thing (for some people) that you are missing with git is that it makes working with branches really easy. In my first job we used SVN and maintaining separate branches was a pain in the ass, to the point where we only did it for a release branch, while with git it's pretty trivial to the point where people use them all the time even when working locally only.

I do agree that git's documentation and UX for basic operations is not as nice as SVN.

edit: Also agree about the signalling part to some extent. I do feel like there's a tendency among some programmers to gravitate toward the most complex plausible technology in order to show how smart they are.

Comment author: [deleted] 03 August 2015 04:26:56AM 1 point [-]

Gakkou Gurashi is by far my favorite show of the current season. For anyone who doesn't mind moe and wants to see a more exciting twist on the genre, I'd recommend watching the (entire) first episode with as little information/spoilers as possible.

I picked it up on recommendation from /r/rational. Then I fell over laughing, having accidentally downloaded ep 4 instead of ep 1. Then I watched ep 1 and was so excited to get to the "flip".

In response to comment by [deleted] on August 2015 Media Thread
Comment author: ShardPhoenix 03 August 2015 09:10:30AM *  0 points [-]

I picked it up on recommendation from /r/rational.

As much as I enjoy the show I'm not sure what makes it rationality material...

View more: Prev | Next