joppy

To get something useful and not attackable, the complement operation would need to take the complement inside the set of valid UTF-8 strings rather than the set of all byte-sequences, which is probably doable but I'm not sure how straightforward it would be.

T.Tao's first publication (at least the first one that shows up on MathSciNet) was in 1996, the same year he finished his mathematics PhD. I would say for most people working towards the pure side of mathematics, having over 5 papers before the end of a PhD is not at all typical.

I would recommend looking not only at books, but at online video lecture recordings (from reputable sources). There is so much intuition you get from someone actually discussing and problem-solving in front of you, not to mention (especially in higher pure mathematics at least) a lot of intuition which is spoken or drawn on the board, which never makes it into a book.

To be clear, it was a very low-traffic (both car and foot) location - neither would expect to encounter each other almost ever. I thought the decision to not encourage pedestrians into a false sense of security was a sensible one.

I applied to my local council (in Australia) for a pedestrian crossing to be painted somewhere near my home where a footpath from a park comes out onto the road, and pedestrians need to cross to the other side of the road. Seemed like a real no-brainer to me.

I got a letter back several months later saying that they had reviewed my request, measured the foot traffic in the area on several days, and decided to not paint a pedestrian crossing because there was low enough pedestrian traffic that cars would get complacent and ignore it (therefore endangering pedestrians who would have expectations that cars would stop at a pedestrian crossing).

It's the first time I realised there is actually a lot of though that goes into where to place a pedestrian crossing, and when to not place one.

For pages with lots of mathematics markup, it is far better (in terms of download size) to send the latex markup and the katex library to the browser, and render it there. I tried rendering the mathematics server-side using katex on my own website a while ago, and the div soup generated by katex takes up loads of space.

Original page (compressed): 10 kB

Page with server-rendered Katex (compressed): 50 kB

Katex.js (compressed): 80 kB

So after two pages it’s a net win to not render the mathematics server-side.

This decomposition is not used much because it is not unique in any sense, it is not numerically stable, and it is fairly uninteresting: the matrix D can always be taken to consist of a diagonal of 1s of length rank(A) and the rest zeros. It is much more interesting once X and Y are constrained to something like unitary matrices (in which case we get SVD).

This “rank decomposition” is a bit interesting algebraically rather than numerically, since then the numerical stability problems disappear. Also, if we take all matrices to be over the integers (and require that “invertible” means the inverse is also an integer matrix), then the rank decomposition is a lot like the Smith normal form of a matrix.

Are you sure this is not just the amount of exposure to each type of clock?

On the other hand, I’ve noticed that children who understand how to read only digital clocks are quite capable of answering what the time is (just read the numbers right off), but have trouble telling how many hours there are from 10am to 3pm.

Right, but I would probably test the output while compressing instead of putting a big USE AT YOUR OWN PERIL sign across the front…

Why is there such a big disclaimer/warning on the front? Shouldn’t the program just check that decompress(compress(x)) = x as it goes, and then it can be sure that compress(x) has not lost any data?

Companies do this all the time with share-based compensation don’t they?

Because of how floating-point numbers are distributed, you should expect a random number drawn uniformly from [0,1] to basically never hit the smallest floating-point number: hitting something in the range [0, 2^-n] should happen with probability 2^-n.

I agree there is much more one could want out of a uniform random float generator than just k/N where k is a integer drawn uniformly from {0, 1, …, N}, but hitting arbitrarily small floating point numbers is not on this list.

If you are intending to sample numbers in the range [0,1] such that each float occurs with equal probability then that’s fine, but it’s certainly not uniformly random on [0,1].

I’m also on 15.3.1. The huge “Up Next” menu (the first thing on the first page) is what I’m describing - perhaps you need to subscribe to some podcasts before you see it.

Clicking the purple durations next to the play button always starts the podcasts playing for me.

What do you think of the iOS podcasts app then? I have no idea of where to press to view details of a podcast, vs to start playing it. On the main page, the black text starts playing a podcast, and the purple text shows details. Further into the app, the purple text will start playing while the black text will view details. While playing, neither the purple nor black text do anything (they act as title/subtitle). Clicking on a picture is also pretty unpredictable.

This is admittedly not a flat vs non-flat design problem, but it is exacerbated by the flat design. If actions which started something playing were outlined or something, it would be so much easier to use.

Wikipedia is a terrible place to learn advanced mathematics, for the reasons you raise (and more). There are lots of terrific short books, and many terrific lectures online.

In MAGMA, a computer algebra programming language, there is a “exists” statement which takes a comprehension and evaluates to true if any item is true, something like exists{x % 2 == 0 for x in numbers}. But it also has an extra parameter which can bind the value of the first item satisfying the condition, something like

If exists(y){x : x % 2 == 0 for x in numbers}: Print y

There is also a “for all” statement which can return the first offender which does not satisfy the condition.

It’s an awkward but incredibly useful language choice - it would be interesting to see it explored more in mainstream languages.

I guess the author has never done any (two extremely specific subfields) work? Most people don’t need to convert characters into numbers, there’s nothing overly surprising about that…

If you take linear neurons, then the whole network is just some linear (or affine function) of its inputs, and hence the universal approximation fails (not every continuous function can be uniformly approximated by linear functions).

Why does the function you are approximating need to be smooth? From the paper cited in the article, all you need is for f to be continuous on a compact subset of R^n.

Start with an unfinished series? Strange recommendation, I’d instead suggest going with one of the more complete stories…

So reverse a list/slice of anything else then?

Negative numbers are more obvious though: if you have half a number line (positive numbers) and you want to talk about relative positions of things, negative numbers make a lot of sense.

The whole approach of Grothendieck (the “rising sea” analogy) is to conquer deep theorems by first conjuring obscure (but simple) objects and prove simple properties of them, again and again, until finally the deep theorem is a result of many simple ones. In this project (and Grothendieck’s program) the deep result is the Weil conjectures.

Haskell also supports using any old function as an infix function by putting backtics around it, for instance (x `div` y). It’s a nifty feature that can improve code readability (especially in more mathematical contexts) when used well, I wish more languages had it.

Another argument is in regular expressions, where you can see that concatenation distributes over alternation: A(B|C) is the same regex as AB|AC.

Unboxing is a huge optimisation though isn’t it? No need to allocate when inserting a new item into the queue (beyond the standard allocations which happen when growing a slice), fewer pointer indirections when reading the queue, easier garbage clean up at the end (a single deallocation of a slice).

I think (but am not sure) that the Go compiler can add some small primitive types and structs (precisely: those that fit in a machine word) to a []interface{} by storing them inline, removing the need for an allocation. So perhaps you will only see major speed increases when using larger structs.

As long as you normalise by only multiplying/dividing by positive numbers rather than any nonzero number, you’re really working in S^3.

Great post!

Your code example for isHot() seems round the wrong way; also doing something like “return temperature > 100” is probably more idiomatic than using if/else just to return true/false.

It's very hard to see the patterns in mathematical expressions or equations without compressing the notation down to be very small, which is the main reason this is done. However, mathematicians break complex expressions down into simpler reusable parts all the time...

Having dead or sick parents and teachers is also a terrible outcome for children.