ChrisFoster

Exactly my thought too. The offset is just the zero frequency. But in general, the need to do this for the zero frequency would suggest that there's a scaling problem for all the longer frequency Fourier components? And that, perhaps, the effective spatial Fourier spectrum of noise which is used in Sd is not optimal?

I'm not sure we're disagreeing here? As I understand it, some people have a certain kind of distractable brain and there's an underlying brain chemistry implicated here which isn't something you develop in adulthood.

However, having this brain chemistry doesn't necessarily mean a person suffers impairments in daily life: impairments are highly situational.

I suppose - to the extent that the DSM-5 requires a fair level of impariment for someone to be diagnosed with ADHD - that it's technically correct to say people can develop this in adulthood: there it passes from a syndrome to an disorder. (Personally I feel it's kind of absurd not to have a name for the syndrome if it occurs in the absence of impariment due to life circumstances! Perhaps this will be "fixed" one day as psychology slowly becomes more quantitative.)

Thanks for the book suggestion!

This is from to the history of how the Julia language was bootstrapped. The fact that Jeff happened to have written his own scheme (femtolisp) as a previous project probably helped :-)

Actually it's not just the parser but most of the compiler frontend which is written in femtolisp. It would be nice to make the frontend more accessible by replacing it with Julia code at some stage. Bootstrapping is tricky though until someone gets separate compilation working.

I used to think this was true (as a developer of a lot of generic Julia code and small data analysis applications).

But now as a developer of larger amounts of "application style" code, I'm not so sure. In an application, you've got control of the whole stack of libraries and a fairly precise knowledge of which types will flow through the more "business logic" parts of the system. Moreover, you'd really like static type checking to discover bugs early and this is starting to be possible with the likes of the amazing JET.jl. However, in the presence of a lot of duck typing and dynamic dispatch I expect static type inference to fail in important cases.

Static type checking brings so much value for larger scale application work that I'm expecting precise type constraints to become popular for this kind of non-generic code as the tooling matures.

Have you tried Infiltrator.jl? It's great for breaking out into an interactive REPL from some inner scope, allowing you to examine the local variables and other program state interactively. This covers the part of the functionality of pdb.set_trace() which I care about.

Yes, well put. I'd take it further - in numerical code there is no real distinction /at all/ between closed form vs iterative solutions. Every type of numerical code is subject to truncation error; an iterative method with few moving parts may systematically converge to a more accurate result than the direct expression of a closed-form solution.

It's quite interesting to delve into how special functions like `sin` and the like are actually implemented and the lengths people go to to make them "correctly rounded" (see, for example, crlibm). Even something as simple as linear interpolation between two floating point endpoints can be quite subtle if you want an implementation that is exactly correctly rounded and also fast.

This is really neat. In the past I've used similar techniques to decode binary data from a third party lidar system in parallel. In a way that the manufacturers probably didn't intend or expect.

The system generated large data files which we wanted to process in parallel without any pre-indexing. It turned out that these streams contained sync markers which were "unlikely" to occur in the real data, but there wasn't any precise framing like COBS. Regardless, the markers and certain patterns in the binary headers were enough to synchronize with the stream with a very high degree of reliability.

So for parallel processing we'd seek into the middle of the file to process a chunk of data, synchronize with the stream, and process all subsequent lidar scanlines which started in that chunk. Exactly the algorithm they describe here.

Amusingly this approach gave reasonable results even in the presence of significant corruption where the manufacturer's software would give up.

No, I'd say it was an almost-complete success. The point of this was to test several things which they've never tested before and gather data to drive design improvements. They successfully tested: ascent under three engines, flap-controlled aerodynamic descent to the landing site, the landing flip maneuver - including drawing propellant from the header tanks - and final landing burn.

They didn't stick the landing, but it looks like they got test data from all the planned test activities. The explosion will prevent gathering some data from post-flight inspection, but other than that I doubt it has much affect on future development.

To look back on SN5/SN6 testing, they stuck the landings with those prototypes, but the prototypes themselves are now obsoleted by the new prototypes in production (up to SN16?!)

> A function does not spring into existence until the definition of the function is executed.

Methods and their type signatures do exist within the runtime as soon as the function expression is evaluated. To simplify the example from your article

  julia> a = 20
  20

  julia> foo(x::(a < 10 ? Int : Float64)) = "thing"
  foo (generic function with 1 method)

  julia> methods(foo)
  # 1 method for generic function "foo":
  [1] foo(x::Float64) in Main at REPL[2]:1

Here you see that one method of the function foo has been defined, and the code in the type signature has already run, resulting in a method which takes x::Float64. After this point, changing the value of `a` will not change anything about foo.