No, the point of proofs in mathematics IS to prove a particular statement is true, given certain axioms (accepted truths). Yes, there are numerous benefits beyond demonstrating something is undeniably true, given certain accepted truths, perhaps more “useful” than the proof itself, but math is a method of formal knowledge that doesn’t accept shortcuts.
A lot of mathematicians (myself included) would say that the point of proofs isn’t entirely to know whether or not a statement is true, but that it exists to promote human understanding. In fact, I’d argue that at some level, knowing whether or not a theorem is true can be less important than understanding an argument.
This is why having multiple different proofs is valuable to the math community—because different proofs offer different perspectives and ways of understanding.
Three failures this close together is problematic! I have no insight, but I wonder if organization or cultural changes are to blame? Plus, SpaceX flouting FAA rules recently, makes me worry about their long term future.
What’s the best way to handle url slugs that change? For example, if I have www.example.com/page/foo, and the user changes that page’s title to bar, the slug updates to www.example.com/page/bar and anyone visiting the old url gets automatically redirected to the new one. But now the old slug of foo can’t be used again (without appending some unique identifier to it, like foo-th683gh9i).
It’s not great but it matters less when the content you get going to that page is so unremarkable. Don’t forget you can do that to any url, even of sites that don’t use optional slugs, if your goal is just vague, evil-by-link-appearance.
This article is about incorrect understanding by engineers and scientists of how different materials, in different conditions, behave during reentry:
“"During its initial design, the Dragon spacecraft trunk was evaluated for reentry breakup and was predicted to burn up fully," NASA said in a statement. "The information from the debris recovery provides an opportunity for teams to improve debris modeling. NASA and SpaceX will continue exploring additional solutions as we learn from the discovered debris."”
and
“These incidents highlight an urgency for more research into what happens when a spacecraft makes an uncontrolled reentry into the atmosphere, according to engineers from the Aerospace Corporation”.
The inclusion at the end of the article about how low the risk of space debris injuring an individual serves to tell the reader space debris hitting them is not something they need to worry about. Again, this is about experts updating and improving their models, especially as the number of space launches grows dramatically, sometimes using novel materials.
I agree people are generally very bad at understanding the relationships among probabilities, hazards, and risks. But this article cites multiple, independent experts, and specifically highlights how this is not a problem of you getting hit by space debris, which is quite anti-clickbait.
A very common quote by Paracelsus in medicine and toxicology: “All things are poison, and nothing is without poison; the dosage alone makes it so a thing is not a poison.” [0]
The leaks in question are on the service module of the Starliner spacecraft. This is a separate part of the spacecraft that is jettisoned before the main spacecraft reenters the atmosphere. Therefore, the service module, where all the leaks are that they want to understand better, would burn up in the atmosphere, and be destroyed.
“Once Hubble is on target, the steadiness of the telescope in one-gyro mode is almost comparable to that of a full three-gyro complement… Although one-gyro mode is an excellent way to keep Hubble science operations going, it does have limitations, which include a small decrease in efficiency (roughly 12 percent) due to the added time required to slew and lock the telescope onto a science target… If Earth or the moon block two of the fixed head star trackers’ fields of view, Hubble must move further along in its orbit until the star trackers can see the sky and its stars again. This process encroaches upon science observation time. Second, the additional time the fine guidance sensors take to further search for the guide stars adds to the total time the sensors use to complete the acquisition. Third, in one-gyro mode Hubble has some restrictions on the science it can do. For example, Hubble cannot track moving objects that are closer to Earth than the orbit of Mars. Their motion is too fast to track without the full complement of gyros. Additionally, the reduced area of sky that Hubble can point to at any given time also reduces its flexibility to see transient events or targets of opportunity like an exploding star or an impact on Jupiter. When combined, these factors may yield a decrease in productivity of roughly 20 to 25 percent from the typical observing program conducted in the past using all three gyros.“ [0]
The impact on Jupiter bit seems strange to me. Unless it's something that just pops up out of nowhere, it seems like we'd have been tracking the impactor for some time to be able to have plenty of lead time for Hubble to use its walker to slowly get into position.
Impactors are indeed not seen that far ahead in comparison to the Hubble time allocation time scale, so for scheduling purposes they do more or less pop up out of nowhere.
Since its not very likely that you happen to have a scheduled science target lying close to Jupiter around the time of impact, you would have to do a long slew which now takes such a long time you likely have to cancel some other science. But I think this is a general issue that will discard most targets of opportunity that Hubble could otherwise have observed.
What are people’s thoughts on using event driven architecture in games? Specifically multiplayer games, and massively multiplayer games (MMOrpgs).
Another comment mentions it was helpful, how specifically, were there any tradeoffs, do certain types of games work better?
I have not worked on an MMO before, but recently I had the chance to try out my own custom event system on a small multiplayer game (Unity, PUN2). I had most issues with differentiating which events came from which client. Additionally, I had lots of issues differentiating which events were issued locally. In the end, the code ended up being quite messy. If I were to redo the game, I'd use direct method calls where possible with regular callbacks.
Generally, I found that when using event systems you have to be really careful not to over-use it, even small/single player games. Its super hard to debug when everything is an event - if you go this route, you essentially end up in a situation where everything is "global" and can be reached from anywhere (might as well just go full singleton mode at that point). Additionally, I found it difficult having to deal with event handlers which raise other events, or worse, async events, as then it becomes really hard to ensure the correct order of invocations.
If you plan to use an event system, my advice would be (in Unity):
- Reference and raise events only on root Game Object scripts (e.g., have a root "Actor" script which subscribes/publishes events and communicates with its children via properties/C# events)
- Never subscribe or publish events in regular "child" components
- Use DI/service locator to fetch systems/global things and call them directly when possible from your "Actors"
