HN user
I believe they are mixing it up with The Guns of August (published in 1962, also by Tuchman), which JFK was fond of and supposedly drew on during the Cuban missile crisis.
This is nonsense, at least in part because it's mixing two different ideas. The notion that the image "looks exactly the same as how it originally appeared" is only true when one of your eyes is positioned exactly where the camera sensor would have been, which requires a specific distance away from the screen.
Lines in 3D remaining straight in a photo is unrelated and not actually demonstrated by the image. I'm having trouble imagining why this matters - you're trying to find the intersection of two lines in an image without drawing anything?
Another aspect of the solution that makes it rather abstract is it effectively assumes we know nothing about the distribution of the number of days.
Paying at 1/2 will be optimal if it ends before you buy, very bad (3x optimal) if it ends right after you buy, and slightly better than the solution in the post if it lasts at least twice that long (1.5x optimal vs e/(e-1)).
The metric in the post is just the worst of those ratios. Assuming the unproven statement in the post (that the solution which is a constant factor worse than optimal is best), any solution of the form you suggest is going to have similar tradeoffs. If we had a distribution, we could choose.
If it wasn't clear, their statements are all true when the events follow a poisson distribution/have exponentially distributed waiting times.
The main image is all at the same 90x level, and those buttons just zoom in (more or less) all the way on the points, while the "140x" are separate scan patches at higher magnification (though the real point is they have 3D/height data, too).
https://tmbw.net/wiki/Shows/1992-07-23
sounds like the concert in question
That isn't at all what the central limit theorem says. The whole point is it holds independent of the actual shape of distribution of the population. You could use the same argument to say social security numbers are normally distributed.
One way to explain things like height being normally distributed is that there are a bunch of independent factors which contribute, and the central limit theorem applied to those factors would then suggest the observed variable looking normal-ish.
The nice thing about deciding on a distance metric is that it gives you both a path (geodesics) and the speed, and if you trust your distance metric it should be perceptually constant velocity. I agree it's non-euclidean, I think the hyperbolic geometry description works pretty well (and has the advantage of well-studied geodesics).
I did finally find the duration logic when I was trying to recreate the path, I made this shader to try to compare: https://www.shadertoy.com/view/l3KBRd
Actually playing around with it the behavior was very different from what I expected - there was much more zooming. Turns out I missed some parts of the zoom code:
Their zoom actually is my "y" rather than a scale factor, so the metric is ds^2 = dy^2 + (C-y)^2 dx^2 where C is a bit more than the maximal zoom level. There is some special handling for cases where their curve would want to zoom out further.
Normalizing to the same cost to pan all the way zoomed out (zoom=1), their cost for panning is basically flat once you are very zoomed in, and more than the hyperbolic model when relatively zoomed out. I think this contributes to short distances feeling like the viewport is moving very fast (very little advantage to zooming out) vs basically zooming out all the way over larger distances (intermediate zoom levels are penalized, so you might as well go almost all the way).
I think you can reasonably think about the flight path by modeling the movement on the hyperbolic upper half plane (x would be the position along the linear path between endpoints, y the side length of the viewport).
I considered two metrics that ended up being equivalent. First, minimizing loaded tiles assuming a hierarchical tiled map. The cost of moving x horizontally is just x/y tiles, using y as the side length of the viewport. Zooming from y_0 to y_1 loads abs(log_2(y_1/y_0)) tiles, which is consistent with ds = dy/y. Together this is just ds^2 = (dx^2 + dy^2)/y^2, exactly the upper-half-plane metric.
Alternatively, you could think of minimizing the "optical flow" of the viewport in some sense. This actually works out to the same metric up to scaling - panning by x without zooming, everything is just displaced by x/y (i.e. the shift as a fraction of the viewport). Zooming by a factor k moves a pixel at (u,v) to (k*u,k*v), a displacement of (u,v)*(k-1). If we go from a side length of y to y+dy, this is (u,v)*dy/y, so depending how exactly we average the displacements this is some constant times dy/y.
Then the geodesics you want are just the horocycles, circles with centers at y=0, although you need to do a little work to compute the motion along the curve. Once you have the arc, from θ_0 to θ_1, the total time should come from integrating dtheta/y = dθ/sin(θ), so to be exact you'd have to invert t = ln(csc(θ)-cot(θ)), so it's probably better to approximate. edit: mathematica is telling me this works out to θ = atan2(1-2*e^(2t), 2*e^t) which is not so bad at all.
Comparing with the "blub space" logic, I think the effective metric there is ds^2 = dz^2 + (z+1)^2 dx^2, polar coordinates where z=1/y is the zoom level, which (using dz=dy/y^2) works out to ds^2 = dy^2/y^4 + dx^2*(1/y^2 + ...). I guess this means the existing implementation spends much more time panning at high zoom levels compared to the hyperbolic model, since zooming from 4x to 2x costs twice as much as 2x to 1x despite being visually the same.
the chart in the streetsblog article puts some values in the wrong boxes, too. pathetic
you're reading the table correctly but it's been reproduced incorrectly and had its title removed from the original source https://www.iihs.org/news/detail/high-visibility-clothing-ma...
i'm not clear from that how many trials were run for each test condition, but the percentage is average speed reduction, not a chance for binary hit/not hit. edit: the paper pdf says up to three trials each.
You're misreading the solution, the first part reads n=1, a trivial special case, not n congruent to 1 mod 4.
The statement doesn't hold for e.g. n=5. Taking m=2 gives the permutation (1 2 4 3), which is odd, and thus cannot have a square root.
Wikipedia (citing a book on archive.org but no page number) [1] claims the largest order of an element of the Rubik's cube group is only 1260, so the simple repetition strategy would have to have a repeated unit way too long to be practical. (It sounds like you could potentially get a longer sequence if you allow "rotating the cube" as a move vs just turning the sides, though probably not enough to matter)
The linked circuit does have a repeating pattern like this at its core, and visits entire cosets of a subgroup at a time (presumably the same way each time) so it seems like there's already a bit more structure than a random 200MB file.
https://en.wikipedia.org/wiki/Rubik%27s_Cube_group#Group_str...
This looks like the relevant fix: https://github.com/lichess-org/scalachess/pull/154
(the broken code checked that the only pieces on the king's path to its new position were kings and rooks of the appropriate color)
The example is poorly chosen in terms of practicality for this reason, but otherwise, no, this is a poor summary that misses something interesting.
The memory layout isn't changing in the faster versions, and there are no additional cache misses. It's easy to convince yourself that the only difference between the naive linked list and assuming linear layout is the extra pointer load - but TFA shows this is false! The execution pipeline incurs extra costs, and you can influence it.
The "neat result" article linked at the top has some of the missing math: https://kevinventullo.com/2018/12/24/hashing-unordered-sets-...
Restated, if abelian G acts transitively on a set X, X and G have the same size. There's a tacit assumption, then, that you want as many possible states as possible, which the group action result immediately belies.
I'm not sure the author of TFA really thought through the implications of the "block" stuff, all of the conclusions feel pretty uninspiring. The elliptic curve solution is just taking G to be cyclic with prime order (smaller than 2^n). This avoids some pathological behavior that power-of-two abelian groups give you for the multi-set use case - collision probabilities are sort of bunched up around power-of-two multiples, with some unlucky hashes having extremely low order and e.g. adding two of an element doubling the number of potential collisions.
reminiscent of http://www.koalastothemax.com/ (although more mobile friendly, as koalas is mouseover based)
Tametsi explores a similar concept, although with mostly-regular non-square grids
The index of refraction (including its dependence on frequency) fully describes the physics, there's nothing else to look up. Group velocity is a derived property taking into account the mathematics of waves, and in the typical textbook example of a very-nearly-monochromatic wave can be computed from the derivative of the index of refraction with respect to frequency.
I was surprised the article didn't add another couple of sentences explaining the finite field construction of the Hamming code. It seems like the important property of β is generating the finite field of size 8, so that its powers from 1 to 7 are distinct.
Then every 7-bit sequence gets assigned one of the 8 values in the field via the polynomial. The 0s are the code elements, as it says, and every other sequence is a power of β indicating which bit to flip to get a code element.
https://managore.itch.io/stereogram is an impressive example of the possibilities here, with an animated noise image and interactive depth map.
As best I can tell from reading https://www.stat.purdue.edu/~yuzhu/stat514s2006/Lecnot/fracf... the unstated assumption here is that we're going to do linear regression where (critically) the "-" case for each condition is -1, and the "+" is +1. This has the surprising-to-me effect of making "I", which looks like it might be the control group based on notation, actually a positive recipient of AC interaction (and any even-order interaction). You can think of this as a change in basis in how you parse out the effects, where we're talking about
1 -1
-1 1
(like a covariance matrix) instead of
0 0
0 1
for an interaction.
I have a gut feeling it's done this way mostly because the tools being used expect things to be expressed this way rather than any conscious choice by experimenters. Through this lens, if you test
I, B, AC, ABC
every experiment has a positive effect from AC interaction, and taking B-I, which we might think of as the effect from B, is in this paradigm also sensitive to the ABC interaction and the AB and BC interactions. The "real" effect from B would be approximated as (B + ABC - AC - I)/2, which is exactly the same as the effect from ABC interaction (which is positive when an odd number of its constituents are positive...).
I'm pretty sure this is just a difference in mathematical perspective - you can represent exactly the same data, but the coefficients (i.e. effect values) will change, and there's a different notion of what you know vs don't know. Maybe there's a more convincing reason to do this when you have more than two "levels", but from the presentation in TFA it just feels like overcomplicating things with a confusing prior about how effects work.
It also seems like the given example is just bad. If the parameters are numeric and there's not a reasonable "control", this perspective feels much more natural.
Sorry, to clarify, it's supposed to be a multi-step process (see https://www.youtube.com/watch?v=mxlvsts3c6o ) where you get it to jump onto land, then it gets kicked to another location where you can knock it into the waterfall.
In the game, these are actually two separate entities, and I haven't done anything to prevent the "kicked" one from immediately spawning in the air here https://noclip.website/#snap/1A;ShareData=AUsPn92;%5eVT:h=19... , or to hook up the first one to the second (although the system to signal between distant pokemon, which it probably uses, is mostly implemented). There are a few other instances of things that are supposed to be spawning conditionally which aren't handled yet, like extra lapras in the beach.
Many of the contributions are others reversing and implementing a new game on top of the existing API, so the really labor-intensive per-game work is still spread out reasonably well.
The Pokemon Snap behavior is a mixture of handwritten code and parsing of the game's AI code. It was originally written in a very structured way that makes it easier than having to fully emulate. More involved interactions are missing (Magikarp evolution in the valley, a lot of the cave sequences)
The justification on the main page doesn't inspire confidence:
IQ test reports costs 19.99 due to increased costs associated with collection, updation and normalization of data.
To set the record straight for the above comment -
- it's true that there isn't a precise frequency needed for microwave ovens to heat food
- however, "polarity flipping" is just a description of electromagnetic radiation itself, and shooting enough EM radiation at food in a frequency range it absorbs will heat it up via dielectric heating
- microwaves have no relationship to any specific resonant frequency of water - the vibration frequencies are orders of magnitude higher https://en.wikipedia.org/wiki/Electromagnetic_absorption_by_... while rotation response inherently does not have a peak
- otherwise, yes, the motion of (polar) molecules induced by an electric field is indeed the mechanism of dielectric heating
Looks like a demo released on steam a few weeks ago: https://store.steampowered.com/app/1141050/Nour_Play_with_Yo...
Another interesting little go difference (along with other newer languages like rust, but not c/c++/c#/java/javascript) is making equality lower precedence than bitwise operators, so that var & 1 == 0 tests the lowest bit of var, which makes it more convenient for bit hacking.
This feels natural now, but other languages inherited a decision dating back to B, when logical operators like && and|| didn't exist, and the bitwise forms were used in their stead.