Yes it does. We (at the Netherlands eScience Center) will be building such an interface next January, extending Entangled (https://entangled.github.io). This approach uses Markdown and enables editing your code both in Markdown and generated source codes, synchronizing when files are written to. Currently with traditional documentation site generators like MkDocs, you can get nicely presented content, but what you suggest requires a bit more work. We will build better content navigation in Pandoc, and a side-by-side view as you suggest is definitely on the table. Also: outside contributions are more than welcome ;)
There are notable exceptions. In scientific programming, code is tightly linked to scientific context and explaining stuff in prose is vital for being able to understand. Often, people claiming their code just reads itself just haven't worked on hard enough problems. Other than that, people seem to mistake the reason for having documentation: we aren't necessarily (just) explaining how something works, rather why you made a certain choice, why the alternative doesn't work etc.
Yes, writing a good literate program is more work, and it may not be for everything, but there are many cases where this approach can help communicating your work and save time in the process.
That being said, I'm not a huge fan of Org-mode, since it forces Emacs onto your collaborators. A much nicer method based on Markdown is Entangled: https://entangled.github.io/, though disclaimer: I'm the author of Entangled ;)
In cosmology we use a similar procedure to generate initial conditions of sample universes. Just then the noise is in 3D. The article raises a question about the Gaussian nature of the generated noise. To generate non-gaussian noise, you need a way to correlate the phases, otherwise the central-limit theorem will always kick in.
There is so much hate here for the GIL, which is undeserved. You tend to not notice all the nice safety it gives you. If you want to speed up your Python code you could of course try to make it run in parallel: congratulations, you just wasted N times more CPU on slow interpreted code. You could have used an accellerator language like Numba, or write parts of your code in C++ or Rust and get a 10-100 times speedup on a single core!
This is the third time you've replied to someone with this exact comment. Please don't do that. You are not being as effective at promoting your POV as you might be if you were a little more tactful.
I read the document. Sam Gross seems to have a clear grasp on the risks associated with this kind of project (I would quote the relevant part, but google docs is a clown shoe.)
One the one hand I wish him luck. If he pulls it off he'll be a hero. On the other hand this seems like a huge "turd polishing" for a problem that one only encounters if one is doing something ill-advised. The GIL just isn't that big of a problem in practice. I've been writing Python for going on twenty years without ever encountering a single problem due to the GIL.
I replied to comments that seemed ill-informed or hadn't bother to read the design doc. I have been writing Python since January 2000 or so, so I guess I maybe have 2 years on you there.
I haven't encountered any difficulties with the GIL either, but that doesn't mean it's not a problem.
FWIW, I think it's a good thing to encourage people to read the design doc. Ignorant knee-jerk responses help no one and waste a lot of time, and we can have a better discussion if participants are better informed. I don't think you were doing the wrong thing, I felt you were doing the right thing poorly. ("FUD" is pretty strong language IMO in this context.)
I really do hope Gross is successful. It does seem like he's "got an angle", so to speak, on the problem. At the very least, he's coming into it well-informed with his eyes open. He wants to try excising the GIL (and FB is apparently footing the bill to boot) so it's stupid to object, eh? Who cares if he wastes his time? He's not hurting anything. And maybe the horse will learn to sing. :)
The FUD comments came when I was on my phone and in https://xkcd.com/386/ mode. I was just disappointed seeing so many comments that were, well, FUD. FUD may be terse, but I don't think it's strong language.
There's a lot of misunderstanding around the GIL in general.
You can’t just call everything that doesn’t agree with your opinion FUD…
Because, you know, they make a valid (flamebatish) point, the ‘easiest’ way to get performance out of python is to wrap the critical code in another language as an extension. Removing the GIL isn’t going to change this no matter how careful it is designed.
FUD isn't just a meaningless phrase, it means fear, uncertainty and doubt. Nearly every comment against GIL removal makes vague claims about this causing stability issues in a large amount of code that possibly, might, perhaps depend on it without even being aware of it. Yet there is not a single example given that holds up to even basic scrutiny. This is quite literally a textbook case of FUD.
What's the point of "safety" if it's not needed anymore, as it seems not to be under nogil? If that's right, then modulo regressions/bugs possibly introduced by nogil, the choice is really just between worse or better performance, and it's not important whether there are (more effortful, by the way) ways of getting much much better performance.
Moreover, to the point about writing performance-critical sections in $NOT_PYTHON, as Sam Gross explains in the nogil design doc, things aren't always so straightforward for scientific computing:
> Calling into Python from C requires acquiring the GIL -- even short snippets of Python code can inhibit scaling. Addressing this issue sometimes requires rewriting large portions of Python code in C/C++ to actually achieve the desired parallelism. For example, PyTorch rewrote all of the core automatic differentiation from Python to C++ to avoid acquiring the GIL in the backward pass.
The solution here is that you can edit code, with all your IDE features enabled, in tangled form. Changes are automatically merged into the Markdown by the Entangled daemon.
This could be highly interesting. Especially when starting with the FFT butterfly structure for connections and the corresponding weights as network initialization and then adapting that to real data via training.
This is a great idea, I bet one could find a bit-faster fftw that would be close enough for many applications, but it would apply a statistical approach to each weight.
Hear, hear! I think this problem is also beautifully put by the Knuth in Surreal Numbers. Results are boiled down to the smallest possible representation, without giving a historical/pedagogical overview, or even the slightest hint about how the author himself also struggled with the material.
This also boils down to what you understand the word "elementary" to mean. It is definitely not synonymous to "simple", rather as Feynman put it, "only requiring an infinite intelligence to understand".
It's a nice figure displaying the presence of elements in the Earth core, human body and cell phones, but why does it give no hydrogen in cell phones?
Also the picture of "native gold" is really pyrite, also known as fool's gold.
My confidence levels for this article are low.
