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!

ADHD is a developmental condition which is highly genetic and relates to neurotransmitter brain chemistry (Dopamine / Norepinephrine). People with ADHD have it their whole life, it's not something you can develop in adulthood. However, people can be (commonly are) diagnosed in adulthood, especially for the inattentive subtype which has less outward symptoms.

What can change or develop over time is the life circumstances that a person with ADHD finds themselves in. Circumstance can make the difference between ADHD being a disorder with significant impairments vs a joyful and creative existence.

Situations which demand executive function, like putting down that mobile phone or closing youtube in favor of doing something more productive are much harder for people with ADHD. The market built by the tech industry to transact human attention for profit certainly hasn't helped here.

Here's a good brief overview of ADHD: https://www.adhdbitesize.com/post/understand-what-adhd-is-re...

Or a bite-size youtube version https://www.youtube.com/watch?v=xMWtGozn5jU

An online ADHD test which is relatable and seems fairly accurate: https://totallyadd.com/do-i-have-add/

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.

That's biologically impossible, but we might end up with weeds which resemble the crop in new and interesting ways.

This has already happened in history for weeds which came under artificial selective pressure due to practices of separating seeds, etc. The fascinating thing is that some of these weeds took on so many of the desirable properties of the primary crop that they became crops in their own right. Rye and oats originally being mimicks of wheat for example: https://en.wikipedia.org/wiki/Vavilovian_mimicry

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.

> it makes a mess of your system that is hard to clean up

This was true in the past, but the Julia ecosystem has rapidly moved away from installing anything via system package managers or messing with the system state in hard to understand ways.

Instead, everything goes into the .julia directory under the control of the Julia package manager, and the dependencies for any given project can be reproduced on another machine or OS by copying the Project and Manifest. The same goes for binary dependencies (eg, the result of compiling C/fortran/rust/go code) for which there's some amazing cross compilation tooling and build infrastructure — see https://binarybuilder.org/

At this point, I think Julia projects enjoy really first class portability and reproducibility.

The piston idea seems like a appealing design requiring minimal new technology. The plant is the same as existing pumped hydro plant, the weight can come from the native rock.

Using a rolling membrane for the seal is discussed at

https://heindl-energy.com/technical-concept/engineering-chal...

Naively that does seem plausible but it's a very large sheet of material to manufacture. What are your thoughts on that approach?

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?!)

Punning through the union is explicitly allowed in the GCC documentation which explains why it's reliable for use in the Linux kernel. See

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Typ...

> you also have to assume the size of those primitive types

This usually works though there's some situations where you could still be surprised. For instance if you're programming embedded processors with avr-gcc you'll have sizeof(double)==4

Actually the heat arises from the natural decay of radioactive elements within the Earth. In the far future it will be gone!

It's true that in the early history of the Earth there would have been heating from gravitational contraction of the protoplanetary disc. But as soon as the Earth swept its orbit of material this source of heating disappeared.

There's an interesting footnote in the history of physics where gravitational contraction was the proposed mechanism for solar luminosity: https://en.wikipedia.org/wiki/History_of_Solar_System_format...

> 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.

I liked the following blog post where Jack Lindamood argues pretty convincingly against using Context.Value in nearly all circumstances, and gives some nice alternatives.

https://medium.com/@cep21/how-to-correctly-use-context-conte...

Agreed, treating log events as a string seems like throwing a lot of readily available information away. There's various logging libraries which do allow more structure but too often this is ignored.

I think we got some of this right in the standard Julia logging frontend. We allow the user to attach arbitrary key value pairs (name=data) to the event, and also automatically attach some statically known context such as source location.

(The loggers are also dynamically scoped to the task, which has several good properties. For example it gives great control over attaching context known by the caller to the callee's messages and over dynamically routing or filtering messages. Sort of like MDC but more convenient.)

I agree the exterior algebra is beautifully elegant mathematics, but expressive elegance of the formalism is largely irrelevant to numerical robustness. (Cramer's rule itself is a perfect example of this: it's elementary to express, but in simple form is a terrible idea numerically.)

To be clear, I'm not claiming there's anything wrong with your algorithm but simply adding a note of caution. Any careful comparison between methods must include both efficiency and numerical accuracy.

In terms of engineering, I can't see how steering this beam would be remotely viable: it appears you've got to line up the long axes of the 1000 km circumference muon ring to point exactly in the direction of the weapon to be targeted. So to have it steerable at all it appears necessary to make it space-based. Having done that, it seems the energy, reaction mass and and time required to steer the thing would be pretty crazy.

From a basic physics viewpoint this seems surprisingly within grasp though in terms of energy scales. Greatly entertaining!

My main concern with this comparison is that there's no mention of numerical stability / accuracy of this method.

Calculating determinants is notoriously prone to cancellation error if done naively, so you've got to be really careful. By extension, the usual text book implementation of Cramer's rule is a rather bad way to solve matrix systems. (I don't know much about Grassman.jl so perhaps they've used some known tricks to make this work better, but you do have to be really careful with this stuff.)

Actually in early versions of StaticArrays we were pretty cavalier about numerical accuracy because it was just a library we needed for fast geometric calculations. However as people started using this library for serious numerical work we've had to pay a lot more attention to having good numerical properties.

There's still a lot to learn - and no doubt much work to do - in upgrading the implementation to make sure everything is first robust, and second as fast as possible.

"Static" is a reference to the size of the arrays being fixed and encoded in the type. There's various allocation strategies, for instance StaticArrays.SizedArray uses a normal heap-allocated Array as the storage.

That said, the backing storage for the particular static array types used in this example (SMatrix,SVector) is an immutable Tuple which should generally be stack allocated if the library and optimizer are working together as intended. So the allocations here are a bit of a surprise; they may indicate a lack of inlining in something we expected to be inlined.

A year or so I looked into "git for data" for medical research data curation. At the time I found a couple of promising solutions based on wrapping git and git annex:

GIN: https://gin.g-node.org/ datalad: https://www.datalad.org/

At the time GIN looked really promising as something potentially simple enough for end users in the lab but with a lot of power behind it. (Unfortunately we never got it deployed due to organizational constraints... but that's a separate story.)

Current MR physicist / data scientist here. There seems to be a lot of misapprehension in this thread.

First, this work is about taking data in the sensor domain ("k-space") and reconstructing it into an image. Doing this with partial k-space data and hand-coded heuristics is a completely standard part of the MRI research agenda and has been for quite some time. See, for example, http://mriquestions.com/k-space-trajectories.html. Further, several of these techniques have already made it into routine clinical work, and this acquisition-side stuff generally happens before the radiologist even sees the image (reliable acquisition is in the interaction of radiographer with the scanner manufacturer's software).

There's also various claims here that seem to imply learned reconstruction inherently implies the risk of hallucinations without recourse. Naturally, one should be careful about this, but it's just a matter of careful cross validation: hold out examples of abnormal anatomy for the test set. There's other ways to attack this problem too: training can be done partly or mostly on synthetic data because we have reasonably good forward models of the physics. In this case, one could choose a wide variety of arbitrary synthetic anatomies during training, to further ally the fear of always hallucinating the "typical human brain" from any scan.

Slow acquisition and image artifacts in MRI are a fact of life for people in the field and I believe there's huge scope for improvement if we had more intelligent reconstruction and acquisition. Ideally the reconstruction would feed dynamically back into the acquisition to gather more context as necessary; the MR machine is, after all, one giant programmable physics experiment. This is already done in a limited way, but in what I've seen it relies on a lot of hand-coded heuristics. And guess what's the logical step after hand-coded heuristics? Yes, learned models where you objectively optimize for a final result, rather than hand-coding based on a few examples.

Final note - publicly releasing human data is a massive effort in data cleaning and careful anonymization. Not to mention that the acquisition of each sample is extraordinarily expensive. So bravo to these guys for going to the effort.

Julia has been excellent for shelling out since almost the beginning. See https://julialang.org/blog/2012/03/shelling-out-sucks

The models you'd use for map making are often really simple. For example, the Australian plate motion model is a "seven parameter transformation" - three translations, three rotations and a scale factor. The deformation errors which can't be modeled with this are roughly centimeter level over decades; see https://www.researchgate.net/publication/258401581_ITRF_to_G...

For anyone using these kind of transformations, the boundary between the preferred models for two countries may well be discontinuous!

Ultimately the correct way to deal with this is to use a global time dependent deformation model. Some countries with large internal deformation have already gone to the effort of producing local versions. For example New Zealand: https://www.linz.govt.nz/data/geodetic-system/datums-project....

I guess there will eventually be a high quality global deformation map available but I wasn't aware of any such thing in general use as of two years ago.

In principle this is actually quite a reasonable idea and is a common pattern of many types of physical measurement. Often we have a detailed and accurate physical model of the forward dynamics of a system, given some system parameters, but we can't measure these parameters directly. Instead, we measure some data in a "sensor domain" and we'd like to map it back to the physical parameters.

This setup is known as an "inverse problem" and is often ill conditioned / singular or very complex, therefore requiring some regularization in the form of prior knowledge. Treating the inverse problem as a regression problem (given these observations in sensor domain, predict the state of the system) with a neural network as the regressor is one way of attacking these problems and is becoming very successful in some areas, for example MRI reconstructions, eg https://www.biorxiv.org/content/10.1101/278036v1. In this case you are adding the regularization / priors by constructing the training data with a physical model.

I think this kind of approach is interesting because it scales to input and output spaces with high dimensionality. However, it's not exactly clear to me what kind of estimate such a regressor provides (is it kind of like doing maximum likelihood?)

From a more standard statistical point of view, you'd like to estimate the full probability distribution over system parameters. In this case, the orbital elements and mass of the unknown bodies. Because this inference problem has relatively low dimensionality (I think?) you might do better to treat it as a problem of Bayesian inference and sample it using MCMC. Then you'd have a rigorous way to understand the uncertainty of the estimates and also to attack the problem of "unknown number of bodies" in a systematic way.

Have you seen https://github.com/sciapp/gr ?

This is pretty neat work, I was considering using it to help work around the problems of anisotropically scaled SDF font rendering. (Trick: do the anisotropic scaling and add the Jacobian correction factor per color channel before combining with the median. This will avoid some subset of the artifacts you get when trying to anisotropically scale SDFs and subsequently use them for antialiasing and stroke rendering.)

If you're going to use this library, note that the maintenance situation is complicated. Some forks seem well ahead in terms of bug fixes, for example https://github.com/RCrockford/msdfgen

This has been vastly improved fairly recently with the advent of the tensorflow-gpu meta package available via conda. See https://towardsdatascience.com/tensorflow-gpu-installation-m...

In terms of hiding an emitter, the relevant quantity is the beam solid angle in the far field. This is wavelength dependent which implies temperature dependence if we're talking thermal radiation.

The lower the temperature, the longer the wavelength and the wider the beam (given fixed emitter geometry). So there's a tradeoff between hiding your Dyson sphere vs extracting the most energy from the source.