Scientific computing

(for the rest of us)

How to use this material

The best way to read this material is to keep a terminal running Julia open, and type the code. It is tempting to copy and paste, but typing the code actually matters. The sections (and modules within them) are presented in chronological order, and whenever possible (most of the time) introduce one concept at a time. Every so often, an illustration or example will start to re-use previous knowledge, and this gets more common in the later sections. The content is definitely designed to be read from beginning to end!

The lessons have a release cycle, and the current position of the modules in this cycle is indicated next to their title in the main page (and their node on the timeline for each module is also color-coded). The cycle has four steps. “Building” means that the lesson is not ready to be used at all. We are working on it. “Writing” means that there is some information, but it can change at any time, or be updated and overhauled, or that the content is ready but has not been used for actual training yet. “Testing” means that the lesson is ready to be used, and will receive updates based on the experience of actually teaching it. Finally, “Released” is the most mature step in the cycle, and means that after sufficiently many uses of the lesson, it is not expected to change in significant ways. Lessons labelled as released or in testing are meant to be usable in a self-directed learning way, although the later will need some clarifications. Almost all “in testing” lessons have been used for actual training, but will only move up to the “released” stage when we are ready to stop tinkering with them.

A very good way to contribute is to look at modules awaiting testing and give feedback (using Discord or GitHub issues), or to check out modules in development and jumping into adding content!

Whenever a package is discussed, it will be presented in a little box, like e.g. Distributions. Clicking on this link will open a new window with the Julia packages documentation hub, which will hopefully provide you with an incentive to checkout what the packages do!

You will notice that there are very few comments in the material. This is because the text surrounding the code are the comments. The modules are actual Julia scripts, executed using the Literate package. This ensure that whatever you see on screen is the result of an actual code execution. Furthermore, there is no hidden code!

Snippets of code that are important are presented this way (and their output, when not silenced, is immediately below them):

[rand() for i in 1:5]
5-element Vector{Float64}:
 0.21471633048957484
 0.46333316215785325
 0.2601041048115109
 0.6396345614392719
 0.7285488714975501

Bits of code of lower importance (pseudocode or code you are not meant to type), are presented this way:

for each_element in vector
  function(each_element)
end

Throughout the lessons, we have added some asides – they are ranked in order of importance. The first are “informations”:

All that should matter in the choice of tools, language, environment, is that it lets you become productive, and solve the problem you want to solve.

“Opinions” are points we would like to raise for the reader’s consideration, and can be ignored. Example:

People who think it’s OK to criticize others based on their choice of language, OS, text editor, etc, should go home and think about what they did.

“Warnings” are points that can be important, but not necessarily as a novice. It is worth keeping a mental note of them, especially in the long term. Example:

Any time you are about to comment on people’s choice of tools, ask yourself whether this is really necessary, and the answer is usually “no”. The Good Tool is the one that works for its user.

“Dangers” are really important points, that can prove especially dangerous or risky to everyone. They are worth reading a few times over. Example:

This toxic behaviour is driving brilliant people away, and should never be tolerated. Disliking Windows has not made anyone edgy or cool since 1998.

More rarely, there will be a few “Big Brain Time” callouts, meant to contextualize the code with do with some mentions of domain knowledge.

It’s big brain time!

If you want to contribute, there are a number of ways to do so! Before you start, please have a look at our Code of Conduct. It boils down to be nice and respectful – no contribution, no matter how amazing it may be, justifies or excuses bad behaviour. For the actual details on how to contribute, head over to the guidelines.