davidshepherd7

The title of the press release is misleading, there was no non-trivial machine learning/AI involved. "Computers Create Recipe for" translates to: the researchers picked a class of materials, ran DFT simulations (the usual way to simulate this sort of thing) for all combinations of elements in that class and fabricated the ones that were predicted to have interesting properties.

The regression mentioned in the press release was only used to predict one property (the Curie temperature) of the materials based on experimental data for similar materials.

It's still a really impressive piece of work, just nothing to do with AI.

The paper is open access, so you can read the full text here: http://advances.sciencemag.org/content/3/4/e1602241.full

emacs had a similar effect on me. Configuration is all in elisp so you can happily tumble down a rabbit hole of tweaking settings and find yourself learning all kinds of interesting lispy ideas.

Huh, interesting results on my machine:

    urxvt 0.233
    gnome 0.474
    st    0.515
    xterm 1:13.87

times are total real time, in seconds, seem repeatable from a few runs.

I was expecting st to blow everything else away given its focus on minimalism, and what the hell is going on with xterm?

Minor bug: If I hit "Create a PDF" without entering any data I get an internal server error page.

You could try looking at using ivy instead of helm. Not tried it myself but there was a thread on the emacs reddit last week [1] where people said it's much faster.

https://www.reddit.com/r/emacs/comments/51lqn9/helm_or_ivy/

Coursera courses don't always close: I've been doing the compilers recently one and I've not come across any restrictions on access even though the last session was a year and a half ago.

I had the same thing, but I was unable to even log in and stop the emails. I had to just mark it all as spam in the end.

But `sort` has to read all the input before writing any output (I think...). So you get some parallelism but not as much as you might hope.

So it still fits the definition of perfect secrecy, but (with vanishingly small probability when the key is large) it's possible for a key to be chosen that is more "guessable"?

I don't think this is a problem. Depending on the guess for the key an attacker could get back any possible message as the plaintext. So there is no reason for them to believe that the message they obtain by using a simple key (e.g. AAAAAAAAAAAA as in the example) is the original plaintext?

Just in case the authors are reading the comments: the second paragraph of section 1.1 ends mid-sentence, and even worse is missing the closing parenthesis!

Emacs with ido or helm does this [1] but unfortunately it requires quite a bit of customisation, and even more customisation to get nice fuzzy matching.

It does include every possible command though, and it can show keyboard shortcuts.

[1]: http://sachachua.com/blog/2014/03/emacs-basics-call-commands...

That's one of the things I really like about Unity. Can't remember which menu the mouse settings are buried in? No problem, just type "mouse" into the dash.

The ease of installing packages in Emacs has improved hugely in the last few years, so I think it's getting better for beginners already.

It seems nice, but not quite as powerful. I like the way the tracing macro automatically prints every intermediate value, but q doesn't seem to do that.

Their argument [0] against namedtuple is that the namedtuple implementation is basically a hackier macro anyway (format a string then eval it). But I agree that it's not the most impressive example of what you can do with macros (see my other post).

[0]: https://github.com/lihaoyi/macropy#skeletons-in-the-closet

Some of these things look really nice. I'm particularly impressed by the tracing macro:

    with trace:
        sum = 0
        for i in range(0, 5):
            sum = sum + 5

prints

    sum = 0
    for i in range(0, 5):
        sum = sum + 5
    range(0, 5) -> [0, 1, 2, 3, 4]
    sum = sum + 5
    sum + 5 -> 5
    sum = sum + 5
    sum + 5 -> 10
    sum = sum + 5
    sum + 5 -> 15
    sum = sum + 5
    sum + 5 -> 20
    sum = sum + 5
    sum + 5 -> 25

This would save a huge amount of boring typing `print(...)` when debugging, and since it's only for debugging you don't even need to have MacroPy as a dependency!

Unfortunately python 3.4 support is not quite ready [0], and attempting to install it with `pip3` just fails.

[0]: https://github.com/lihaoyi/macropy/issues/32

Related: there are a few emacs plugins that can do structural editing for lisps.

http://danmidwood.com/content/2014/11/21/animated-paredit.ht...

https://github.com/Fuco1/smartparens

https://github.com/abo-abo/lispy

I had problems with this sort of thing while I was doing my PhD and working stupid hours every day. When it got really bad I decided to cut back to a normal working week and it seems to have helped (eventually). So if you're working all the time: try to work less.

I was skimming the abstract and got as far as "forced swimming" before I realised that the test subjects were not human.

I use a short shell function for this:

  take-a-break ()
  {
    if [ $# -lt 1 ]; then
        length="60"
    else
        length="$1"
    fi

    echo "Take a break in $length minutes at $(date --date="+$length minutes" +%T)."

    sleep "${length}m"
    gnome-screensaver-command -l

}

Replace gnome-screensaver-command with whatever screensaver you use.

Are you using a bleeding edge distro? I've been using the version of xmonad from apt-get in Ubuntu (usually the latest release) for ~3 years and it's never broken or required me to change my config.

I started taking fixed breaks every hour to (try to) reduce my rsi pains and it does seem help my productivty. I used to check reddit/hn/feedly whenever I got really frustrated with something but now I usually power through it because I know I'll get a break soon anyway.

Thanks, for anyone curious here's what emacs does with the first example:

http://imgur.com/Rddi9QH

compare with color_coded: https://camo.githubusercontent.com/5cf719c6357f27b86c45bf9b5...

So it looks like color_coded can highlight at least a few things that default emacs doesn't: function calls, variables (when they are used, both can highlight declarations) and non-standard type template parameters.

Have you got a plain text version of the highlighted source examples somewhere? I want to compare it with emacs' default highlighting (I think default emacs highlights almost as much as the "After color_coded" screen shot).

I can't find a publication date for the first version, but since the second edition [was published in 2010](http://webcache.googleusercontent.com/search?q=cache:eW9X2nO...) I suspect it's now been nearly 10 years since that statement was written.

Seems unlikely: in the experiments here the lists are not sorted in the sense of the stack overflow question (i.e. they are not in numerical or alphabetical order). They are sorted (in memory) by their index in the linked list. By definition the array is already in this order.

Unless I've missed something?

I agree this seems very odd (and I came to the comments hoping for an answer).

edit: Since the conclusion doesn't mention anything about the list being faster than the array it seems possible that it is just a typo.

Also the paper mentions (in section 2) that:

        Occasionally when a recorded benchmark time seemed to be implausible,
        (perhaps caused by other activity on the computer system), or we re-tested
        the data point for other reasons and found a significant variation, we indi-
        cate the repeated time as well.

which seems to imply that the timing experiments were not usually repeated.

Can I ask why? Is it bad style? (I'm fairly new to C)