Not really. Jupiter alone is good enough. Its huge mass accounts for almost all of the gain you get from any such slingshot. Launch windows from Jupiter to anywhere occur every 12 years. Voyager's alignment was captivating, but realistically if it hadn't happened, we would have just done separate Jupiter-Uranus and Jupiter-Neptune missions instead.
Yes, easily. The alignment doesn't really matter for that. Almost all your speed gain comes from just Jupiter. Saturn is 30% the mass and 2/3 of the orbital velocity, so your gain from Saturn is only 20% of what you can get from Jupiter (and also your potential gain is limited by a minimum approach distance greater than the rings, or you'd hit them.) And the ice giants are slower and smaller yet; Voyager barely gained from Uranus and actually slowed from Neptune since it wasn't routed to gain speed there.
New Horizons achieved 80% of Voyager's velocity with just Jupiter, and it wasn't really trying to optimize for speed, it approached Jupiter only to 10 million km (over 100x greater than the planet's radius.) A probe dedicated to a fast slingshot past Jupiter could easily overtake Voyager. We haven't had any need to try, unless one of the missions to specifically study the heliopause-interstellar area happens. It would still take a while to catch up to Voyager's head start, but it's doable.
The alignment for Voyager was captivating, but it really wasn't as important as people typically think. Jupiter alone can get you anywhere and launch windows for it come every 12 years. If the four-planet alignment hadn't happened then, realistically we would have just done separate Jupiter-Uranus and Jupiter-Neptune missions.
That was heuristics. It looked for the text "more" or "next" or "->" within an anchor tag. Sometimes it would be fooled if a forum thread or other link had a title containing one of those words.
PNG can be lossy before the lossless step. You can take areas of near-matching pixel values and make them actually match, to work better with PNG's near neighbor compression. There are a few encoders that can do that.
Zero shouldn't be an exception there. If f had been set from something like f = a - b, then you're in the same situation where f might be almost but not exactly zero.
The linter wouldn't know where f came from, so it should flag all floating point equality cases, and have some way that you can annotate it for "yeah this one is okay."
if (f == 0.0) means "is f exactly zero so it's not initialized" 99 times for every one time it means "is f zero-ish because of a cancellation/degeneracy/whatever"
I just found that I have now annotated it for "yeah this one is ok" about 100 times, and caught zero cases where I meant to do a comparison to zero-or-very-nearly-so but accidentally wrote == 0.0.
So my conclusion is: I would have had less noise in my code with that exception in the linter, and the linter had been equally useful.
The idea is not to do it with values derived from arithmetic, but e.g. from measurements where a real zero is very unlikely and indicates something different.
If you're complaining about the prices, remember how capitalism works. The price is set by buyers, not sellers. That's the invisible hand, the seller will set the price to what buyers show they will pay. If you're unhappy about $500 for a Millennium Falcon or whatever, your beef is not with the company for accepting that when people choose to pay it, it's with those other buyers for paying that much.
As the other replies are saying, it's mostly brand power. If your complaint is that $500 for a Falcon is monopolistic because there's no competition because nobody else can legally sell Falcons, the monopoly is really with Star Wars not Lego, they're just delegating it to Lego. You're always free to find your cheapest source of bricks perhaps from other manufacturers and build your own equivalent.
As for stickers and apps and the other stuff... yeah that's the enshittification that also always accompanies capitalism. It's lamentable but it only changes if enough customers vote no with their wallets.
reply