This is not so crazy - this was exactly the progression in screw drives. First came slotted screws (2-fold rotational symmetry), then Phillips/posidrive/Robertson (4-fold), and now Torx (6-fold). Going back to slotted now is actually irritating.
Of course the constraints and trade-offs are very different... still it would be a piece of cake to plug them in on the backside of a box with your eyes closed.
I think the paper is a satire on "evidence-based medicine" - a framework which insists upon randomized controlled trials as the primary basis for medical decisions.
Notably this is exactly such a trial, while also absolutely irrelevant to the question of needing a parachute or not (the trial planes were all on the ground at the time of the jumps).
I guess I'm insane then... I built his pantorouter, and am half-way through his 16" bandsaw build. One good reason to build the bandsaw is that it's actually a very high-quality machine - if executed well. It has an extremely stiff frame (for a relatively light weight), and a large capacity. Buying a similar quality saw of a similar size would be a lot more than a few 100 dollars. That is in fact part of the reason I'm building it (though mostly it's for the challenge).
The other advantage of machines you make yourself is that you can always fix and improve them yourself.
Both machines are an engineering challenge by the way. In the pantorouter, alignment/calibration was a big issue for me - there too many of degrees of freedom, combined with inevitable slop in the mechanism, that has to take a lot of force from the router. Also, even after calibration you need to be careful to not cut too deeply, and in consistent direction to prevent the router bit pulling too hard. But it's all worth it once you're making perfect mortice and tenons with minimal effort :-)
Or: there are a lot of people who think that they're in on a scam, but in fact are lower down the pyramid than they are told. That explanation requires no faith, and can also explain participation of entirely rational actors.
A place where autocorrect might be considered is in REPLs. Out of habit I still regularly write "print 'a'" in the Python REPL although I've been using Python 3 for a while. You get:
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("a")?
Looking at the documentation - einops seems to only implement operations on a single tensor, so it's quite far from a general replacement for einsum, which can perform tensor-products on an arbitrary number of tensors.
The idea of using a multi-agent game, rather than minimizing a single loss function, is already used in GANs - and there it seems to be an very powerful generalization of optimization. Personally I would say the idea is extremely interesting.
GANs have lots of applications, and PCA is useful for various tasks in data-analysis: compression, feature selection, reduced-dimensional modelling. I doubt finding applications will be a problem.
Reliably finding solutions (Nash equilibria), is much harder than optimization for minimum loss however. So I see these being much harder to train than loss-based models.
Not at all serious but... maybe all electrons have the same mass, charge, etc. because there is only one electron, bouncing backwards and forwards through time. As it passes backwards we see it as the anti-electron (positron). When they meet they annihilate from our perspective, but that's just the electron being reflected and becoming a positron heading backwards.
To be clear this is all not at all consistent with observations - just a fun(?) thought experiment.
I went to one of these Sunday dinners about 5 years ago. I was living in Paris and taken there by friends - who didn't explain the concept to me in advance. So I found myself in someone's house, with a massive buffet table and was expected to help myself - there was then a long conversation with my friends about what was going on. Much incredulity on my part :-)
I met Jim very briefly - I guess I was one of hundreds of new people he meets every month. Mostly I hung out with other guests - who were mostly expats (I didn't hear much French) - and who also didn't know Jim very well.
He definitely stepped outside the box with this idea. This is something almost anyone with a big house could do in any place, but which only he actually did.
Maths notation can be wonderfully concise and precise, so it worth thinking about following it closely when programming. One of my favorite examples of this is the numpy `einsum` call [1]. It implements Einstein summation convention [2] - thereby making working with the many dimensions of high-rank tensors feasible.
Each "wedge" is one method of reducing net CO2 output by 1 gigaton/year by 2054. Each wedge is a major economic and technological undertaking. Current estimates are that 13 wedges would be needed to limit CO2 to below 500 ppm. We have currently implemented 0 wedges.
In my opinion it is disingenuous to call any supersonic aircraft sustainable. Independently of any clever aerodynamic design to moderate the drag coefficient, aerodynamic drag always increases like the velocity squared. Doubling the speed will mean applying 4x the force for 1/2 the time, so all propulsive efficiencies being equal, you will expend twice the fuel to go the same distance - at an absolute minimum. In reality engine efficiencies decrease at high-speeds, and you won't be able to completely eliminate the Mach 1 "barrier" (drag peak), or design an aircraft that is equally efficient in takeoff/landing... so the factor will be bigger than that. But x2 fuel consumption is a hard lower bound.
I don't believe this can be called sustainable. Air transport is already a major contributor to CO2 emissions. We as a civilization badly need significantly more efficient ways to fly, not less efficient ways. To even slightly suggest that this might be helping the environment is deplorable.
Also, air transport is already miraculous. Going around the world in a day is not enough for you? Really? Buy a book.
The reason those are all "f"s is that they are all versions of the same thing: the function mapping features to outputs, or approximations of it. The capital "F"s refer to random variables/processes describing the same function (using capitals for RVs and lower-case for samples is standard practice in statistics).
By using this notation he is drawing careful distinctions between the various approximations he's using. I think it's pretty good writing.
Indeed, it seems like a pretty subtle distinction. Given sufficiently bright light, sunflowers would certainly pass the behavioral experiment done here (which is very nicely summarized in Figure 1 of the paper).
The distinction must be in the ability of these starfish to resolve objects (with an angular resolution between 30-50 degrees apparently).
Perhaps even more significant is that Uber gave you the price of the trip in advance. With regular taxis you had to guess, and if you weren't familiar with area, you best guess might well be just "expensive". And then you had to worry about being ripped off.
Uber gave everyone access to information about the cost of taxis - and generally people found it wasn't as expensive as they'd thought.
While I understand the desire for a unified Python ecosystem as much as anyone - this kind of pettifogging is not going to convince anyone to switch to Py3.
Consider if the authors of the article had used (for example) Ruby - you probably wouldn't ask why they didn't do it in Python3, so why do you do it if they write it in Python2?
The red block reminds me of the monster in the film "It Follows". It very slowly but relentlessly heads straight for you wherever you are. Surprisingly unnerving.
This is a really great tool - the kind I didn't even know that I needed until I was given it!
One question, does anyone here know how to interpret the GIL (Global Interpreter Lock) percentage display in the top-left? In my code, "Active" sticks nicely at 100%, but the GIL jumps around from 1% to 100%, changing on every sample.
edit: Now that I think about it, my code spends a lot of time in C API calls - maybe the GIL is released there?
Your missing the requirement that the random sample be uniform in the sphere. That is, if the sphere is cut into any number of pieces of equal volume, the sample is equally likely to appear in any piece.
Your approach samples uniformly from the radius, so you're going to end up with far too many samples close to the center.
Of course the constraints and trade-offs are very different... still it would be a piece of cake to plug them in on the backside of a box with your eyes closed.