This analysis is not quite fair. It takes into account locality (i.e. the speed of light) when designing UUID schemes but not when computing the odds of a collision. Collisions only matter if the colliding UUIDs actually come into causal contact with each other after being generated. So just as you have to take locality into account when designing UUID trees, you also have to take it into account when computing the odds of an actual local collision. So a naive application of the birthday paradox is not applicable because that ignores locality. So an actual fair calculation of the required size of a random UUID is going to be a lot smaller than the ~800 bits the article comes up with. I haven't done the math, but I'd be surprised if the actual answer is more than 256 bits.
(Gotta say here that I love HN. It's one of the very few places where a comment that geeky and pedantic can nonetheless be on point. :-)
This is the right critique. The whole article is a fun thought experiment but it massively overestimates the problem by ignoring causality. In practice, UUID collisions only matter within systems that actually talk to each other, and those systems are bounded by light cones. 128 bits is already overkill for anything humans will build in the next thousand years. 256 bits is overkill for anything that could physically exist in this universe.
And recent DESI data suggests that dark energy is not constant and the universe will experience a big crunch in a little more than double its current age, for a total lifespan of 33 billion years, no need to get wild with the orders of magnitude on years into the future. The infinite expansion to heat death over 10^100 years is looking less likely, 10^11 years should be plenty.
Protons can decay because the distinction between matter and energy isn't permanent.
Two quarks inside the proton interact via a massive messenger particle. This exchange flips their identity, turning the proton into a positron and a neutral pion. The pion then immediately converts into gamma rays.
If you go far beyond nanoseconds, energy becomes a limiting factor. You can only achieve ultra-fast processing if you dedicate vast amounts of matter to heat dissipation and energy generation. Think on a galactic scale: you cannot have even have molecular reaction speeds occurring at femtosecond or attosecond speeds constantly and everywhere without overheating everything.
Maybe. It's not clear whether these are fundamental limits or merely technological ones. Reversible (i.e. infinitely efficient) computing is theoretically possible.
We don't "make" universes in the MWI. The universal wavefunction evolves to include all reachable quantum states. It's deterministic, because it encompasses all allowed possibilities.
Protons (and mass and energy) could also potentially be created. If this happens, the heat death could be avoided.
Conservation of mass and energy is an empirical observation, there is no theoretical basis for it. We just don't know any process we can implement that violates it, but that doesn't mean it doesn't exist.
Time translation symmetry implies energy conservation, but time translation symmetry is only an empirical observation on a local scale and has not been shown to be true on a global universe scale.
I got a big laugh at the “only” part of that. I do have a sincere question about that number though, isn’t time relative? How would we know that number to be true or consistent? My incredibly naive assumption would be that with less matter time moves faster sort of accelerating; so, as matter “evaporates” the process accelerates and converges on that number (or close it)?
Times for things like "age of the universe" are usually given as "cosmic time" for this reason. If it's about a specific object (e.g. "how long until a day on Earth lasts 25 hours") it's usually given in "proper time" for that object. Other observers/reference frames may perceive time differently, but in the normal relativistic sense rather than a "it all needs to wind itself back up to be equal in the end" sense.
The local reference frame (which is what matters for proton decay) doesn't see an outside world moving slower or faster depending on how much mass is around it to any significant degree until you start adding a lot of mass very close around.
Maybe the definitions are shifting, but in my experience “on point” is typically an endorsement in the area of “really/precisely good” — so I think what you mean is “on topic” or similar.
Would this take into account IDs generated by objects moving at relativistic speeds? It would be a right pain to travel for a year to another planet, arrive 10,000 years late, and have a bunch of id collisions.
Um, where is the car? All the images are of (parts of) the interior, and the captioning is bizarre. Ooohh! It has a steering wheel! (And it's a input! Who knew?)
But this has absolutely nothing to do with "certain things are supposed to happen after other things", and CANNOT POSSIBLY have anything to do with that. Flatmap is a purely functional concept, and in the context of things that are purely functional, nothing ever actually happens. That's the whole point of "functional" as a concept. It cleanly separates the result of a computation from the process used to produce that result.
So one of your "simple" explanations must be wrong.
Because you're not used to abstract algebra. JavaScript arrays form a monad with flatmap as the join operator. There are multiple ways to make a monad with list like structures.
And you are correct. Monads have nothing to do with sequencing (I mean any more than any other non commutative operator -- remember x^2 is not the same as 2^x)
Haskell handles sequencing by reducing to weak head normal form which is controlled by case matching. There is no connection to monads in general. The IO monad uses case matching in its implementation of flatmap to achieve a sensible ordering.
As for JavaScript flat map, a.flatMap(b).flatMap(c) is the same as a.flatMap(function (x) { return b(x).flatMap(c);}).
This is the same as promises:
a.then(b).then(c) is the same as a.then(function (x) { return b(x).then(c)}).
Literally everything for which this is true forms a monad and the monad laws apply.
Nota bene, then is not a monad because the implementation of then implies map is isomorphic to flatmap. This is because `then` turns the return value of a callback into a flat promise, even if the callback itself returns a promise.
That is to say, then checks the type of the return value and then takes on map or flatmap behavior depending on whether the return value of the callback is a Promise or not.
You don't? There's nothing special about monads. I don't know why everyone cares so much about them.
There are a few generic transforms you can use to avoid boilerplate. You can reason about your code more easily if your monad follows all the monad laws. But let's be real.. most programmers don't know how to reason about their code anyway, so it's a moot point
I can do you one better and specify that the normal base-2 integer represented by the bits is the number of up-arrows. But as /u/tromp has already pointed out, that is not very interesting.
Settings -> General -> Software Update -> Beta Updates
It's the same on macOS and iOS, pick "macOS Sequoia Public Beta" or the corresponding release for your device. Apple still pushes security updates for those releases, and I haven't heard of any problems with the kind of minor updates that ship late in a major release's lifecycle, so I think the risk of running this way is low. This kicks the can a year or two down the road, at which point hopefully there are better workarounds.
The post had a different title hours ago. Something along the lines of "it's Apple's philosophy to offer our software for free forever". I didn't followed the link before, so I don't know if it was the same content, but I'm sure the comments are related to the previous title.
I had the privilege of working with Don back at JPL at the time he invented the rocker bogey. (I wrote the software for the first prototype with a computer on board.) Not only was he brilliant, he was also a really nice guy. I didn't appreciate at the time how rare that combination of traits is among humans.
To my astonishment, it turns out Don doesn't have a Wikipedia page (though the rocker bogie suspension does).
Thanks for pointing out the rocker-bogie Wikipedia page. There's a true dearth of info about them. Do you happen to know if there's any kinematic analyses of these suspensions available? I used to do stress analysis in the aerospace industry and I've been interested in that sort of analysis since the 1997 Sojourner rover.
I'm not sure what you mean by kinematic analysis, but the video mentions several analytical analyses of his suspension and how he came up with it. They did some computer simulations to optimize how it would deal with various obstacles. Really cool and clever.
I wasn't sure what word to use. That suspension has lots of pin joints and linkages, which are usually the subject of kinematics, 3-bar linkages, mechanisms, etc etc.
I realize that the stiffness of the rockers and links will make a difference in how forces are distributed, because that suspension is clearly not statically determinant, but the main factor in the design has to be the proportions of the links and beams. I can't find anything about that, so I asked.
> I realize that the stiffness of the rockers and links will make a difference in how forces are distributed, because that suspension is clearly not statically determinant
I think it's (mostly) the terrain geometry (plus gravity) that constrains the system, not joint or bar stiffness. This makes them feasible to analyze with the tools of theory of mechanisms I believe.
Also a really noteworthy insight I think he had was that when there is some kind of non-planar geometry arrangement of the wheels, that tends to create additional (perpendicular to surface) force on the wheels, effectively increasing the coefficient of friction. Think how a child may be able to climb a door frame by pressing hard enough on the sides.
(Gotta say here that I love HN. It's one of the very few places where a comment that geeky and pedantic can nonetheless be on point. :-)
reply