Live data from Hacker News

Distill: a modern machine learning journal

distill.pub

101–109 of 109 posts

Re: Distill: a modern machine learning journal

#101

I feel like science publication in general could benefit from disruption of the publishing model. I'm not sure that the toolkit that Distill has provided is quite enough to totally change the paradigm, and it currently restricted to only one field. I like the idea of having research being approachable for the non-scientist, and the more important question of whether there is a more efficient form (in terms of communi…

Yes, check everything made by Bret Victor and his explorable explanations.

I made an awesome list recently just for this topic: github.com/sp4ke/awesome-explorables

Re: Distill: a modern machine learning journal

#102
While this is very nice, I'm a bit confused about the target. What kind of material is intended to be published here in the future?

Because the blog post and title seems to be describing it as a "journal" intended to replace PDF publications, but the actual content appears to be more in the tutorial/survey category, e.g. "how to use t-SNE," etc. Is this intended to be a place to publish new research in the future, or is it meant more for enhanced "medium"-style blog posts?

Both are fine, I just find the dissonance between the announcement and the actual content a bit confusing.

Re: Distill: a modern machine learning journal

#103
post #93
post #73

Earlier quoted context omitted.

Jupyter notebooks are a big piece of solving ML reproducability, it feels like.

I see this a lot, but I disagree, at least in their current form. They miss a variety of very key parts for reproducibility (which, to be fair, was not their original goal). * Dependencies like libraries are not specified anywhere. * Dependencies on local code are not bundled. * Dependencies on local data are not bundled. * Underlying requirements like LLVM (which needs to be specifically 3.9.X for llvmlite in python…

Right, "a part" was important. Looks like the authors of that writeup agree.

> Technologies such as Jupyter and Docker present great opportunities to make digital research more reproducible, and authors who adopt them should be applauded.

Re: Distill: a modern machine learning journal

#104
post #83

Earlier quoted context omitted.

As another designer + researcher with a varied background and an interest in data viz as well as ML, I am super interested in this as a potential contributor. I have experience creating an interactive visualization interface for simple ML algorithms (which has been used by professors in the life sciences department to understand / get a new perspective on what's happening). I would LOVE to be able to be involved with…

> Is there any way that somebody with my background (design+data viz+development+interest and curiosity to learn ML) could be involved with Distill? Absolutely. We know a number of leading ML researchers who would love to publish papers as Distill articles but don't have the design/data vis skills. We'd like to facilitate collaborations which would lead to data vis people co-authoring cutting edge research papers.

This is very exciting. How are you looking at facilitating these collaborations? Will there be a listing of sorts, where, say, ML researchers would say "I need a dataviz guy" and then dataviz specialists can apply, almost like a job (or rather more like matchmaking I guess--bad analogy)?

Or would said facilitation be done by the admins / editors / steering committee? If so, then how do you plan on finding dataviz people? I'm asking this in particular because I would imagine that people who have ML findings to talk about would probably contact you ("I researched such and such, and found such and such. Now I would love to publish in Distill"). But I wonder if data visualization specialists would do the same thing. Contacting with "hey, I love data viz, would love to collaborate with somebody looking for one" feels a little inappropriate to me.

Thoughts?

Re: Distill: a modern machine learning journal

#105
post #2

Various announcements: Google Research: https://research.googleblog.com/2017/03/distill-supporting-c... DeepMind: https://deepmind.com/blog/distill-communicating-science-mach... OpenAI: https://openai.com/blog/Distill/ YC Research: http://blog.ycombinator.com/distill-an-interactive-visual-jo... Chris Olah: http://colah.github.io/posts/2017-03-Distill/

Looks simply amazing and looking forward to getting deeper into it. As a side note who made the interface design for this?: http://playground.tensorflow.org/#activation=tanh&batchSize=... I am very interested in getting into this space from a design perspective.

I'm one of the editors of distill and I designed the interface for the playground, along with my awesome colleague Daniel Smilkov.

Re: Distill: a modern machine learning journal

#106
post #93

Earlier quoted context omitted.

I see this a lot, but I disagree, at least in their current form. They miss a variety of very key parts for reproducibility (which, to be fair, was not their original goal). * Dependencies like libraries are not specified anywhere. * Dependencies on local code are not bundled. * Dependencies on local data are not bundled. * Underlying requirements like LLVM (which needs to be specifically 3.9.X for llvmlite in python…

Right, "a part" was important. Looks like the authors of that writeup agree. > Technologies such as Jupyter and Docker present great opportunities to make digital research more reproducible, and authors who adopt them should be applauded.

I somewhat disagree that it's a big part or even really should be a part of the solution, I'm really not sure that these notebooks are the right approach to making reproducible research. The conclusion there doesn't seem supported by their findings, to me.

I think they solve a different use case well, and forcing them into a workflow they weren't designed for may just result in both less useful workbooks and a poor experience.

Edit - To expand a little, jupyter notebooks are nice to mix code and descriptions, and in essence force people to release a certain amount of their code. But other than that they actually provide fewer of the guarantees that you want from things for reproducibility. And since the goals for reproducibility generally force more restrictions on how you work, I can see there being more issues for trying to match these different ways of working.

I don't see how there are any features which are useful for the goal of making things reproducible, and as such why people keep bringing them up as a solution.

The main steps would seem to be

1. Make sure the results used are not generated on "my machine" but on a specified base run somewhere else. Just like we don't take the unit test results I run locally as gospel.

2. Unique and versioned identifiers for code, base system and data.

3. Archived code and data.

4. An agreed on format in the output data to say where it came from (which references the identifier(s) for the code, base system used and input data)

Your output might be a rendered notebook, but the notebook itself is entirely orthogonal to the process, as what a notebook provides is:

* A nice interface for entering the code

* A nice output format

* A neat way of mixing nicely written documentation along with the code

Re: Distill: a modern machine learning journal

#107
post #51

Earlier quoted context omitted.

I left a comment on your blog announcement to this effect, but I'd love to be a "research distiller" :)

You already are. :) Love your blog.

Well, to be paid as such :)

And I rarely cover recent work.

Re: Distill: a modern machine learning journal

#108
post #62

Earlier quoted context omitted.

Hi Chris, Thank you for this effort. I'm a fan of your blog articles. A question regarding Distill: is it a journal like conventional journal to target new research? Or it is a journal for educational articles to explain old researches better? I hope to contribute to an effort to better explain deep learning. I don't know if that is what distill is looking for?

We're interested in both review/tutorial articles and novel research articles. :)

So would an article explaining the basics of say dynamic programming be of interest? Are there "page" limits. For example, would a tutorial article that is about 20-30 pages in a traditional paper format be okay?

Re: Distill: a modern machine learning journal

#109

Earlier quoted context omitted.

Looks simply amazing and looking forward to getting deeper into it. As a side note who made the interface design for this?: http://playground.tensorflow.org/#activation=tanh&batchSize=... I am very interested in getting into this space from a design perspective.

I'm one of the editors of distill and I designed the interface for the playground, along with my awesome colleague Daniel Smilkov.

It's really great work. Would love to connect with you guys and talk some more about what you are doing.
Post reply on HN