If we imagine a third observer in a space craft traveling close to he speed of light, it's possible to construct the scenario in such a way that the pilot of the space craft would observe the two events happening at the same moment. Time is relative
As an approximation it can be fine to speak that way in practical matters, but it's dangerous to go drawing any deep conclusions while doing so. Approximations shouldn't be allowed to go outside their operational parameters.
The approximation is the belief that things can happen simultaneously. It is approximating along the fact that we only need to concern ourselves with a single reference frame.
I think the difference in the scenario you proposed is that we can conceive of a practical situation in which someone on Pluto sends a message and waits for a reply. We can then say that they are going to have to wait at least 10 hours to receive a reply. This has meaning.
But when the distances become too great the urge is to resist believing that things have an existence beyond the interactions of particles. There is no practical reality to that object beyond our ability to observe it when the light reaches us.
I get what you're saying but you're also being incredibly dismissive to the common understanding which is still correct, otherwise most astrophysics wouldn't work, because it wouldn't be possible to predict where another planet will be at a later time. It's possible to have two alarm clocks go off at the same instant on two planets, though obviously each will observe the other going off later, after a delay.
It's obviously fair to say they happened at the same time in this scenario.
Depending on your feelings on being spoiled on the general techniques, and an approach to implement them, Sebastian Lague made a great two-part series on building a chess engine. It's specific enough that you have an idea of the techniques involved, without dwelling enough with the details to make implementing your own futile.
You can. But ammunition and the guns have to be stored in separate safes. And it's essentially impossible to get off with a self defense claim if you have time to gather your legal guns
I hope you don't mind being a bit curious about this, as a hobby driver.
At what level of motorsports are you working? It sounds like you both semi-regularly work with new teams. And are you working with them as a programmer? I'd be curious to know what kind of applications you're then working on, if so.
I work primarily with GT3 teams across the highest level championships (WEC, IMSA, DTM, GTWC, ALMS), with a variety of manufacturers.
With a small team of software engineers and data scientists, I'm building a cloud based motorsports data analysis platform which eliminates the friction involved in handling motorsports data and the differences between different manufacturers' software systems, and quickly gives drivers & coaches insights on how to improve their driving. So this involves getting into the weeds of a lot of this legacy software.
There are a few teams I work more closely with where I've set up their entire trackside network/tech stack, although nowadays I'm more focused on the software. Over the years I've done a bit of everything at the track, up to and including physically laying cables in a bare garage or setting up the systems on the car, although I don't do anything related to vehicle dynamics.
Much more egregious is the fact that the API allows returning both an error and a valid file handle. That may be documented to not happen. But look at the Read method instead. It will return both errors and a length you need to handle at the same time.
The Read() method is certainly an exception rather than a rule. The common convention is to return nil value upon encountering an error unless there's real value in returning both, e.g. for a partial read that failed in the end but produced some non-empty result nevertheless. It's a rare occasion, yes, but if you absolutely have to handle this case you can. Otherwise you typically ignore the result if err!=nil. It's a mess, true, but real world is also quite messy unfortunately, and Go acknowledges that
Most of the time if there's a result, there's no error. If there's an error, there's no result. But don't forget to check every time! And make sure you don't make a mistake when you're checking and accidentally use the value anyway, because even though it's technically meaningless it's still nominally a meaningful value since zero values are supposed to be meaningful.
Oh and make sure to double-check the docs, because the language can't let you know about the cases where both returns are meaningful.
The real world is messy. And golang doesn't give you advance warning on where the messes are, makes no effort to prevent you from stumbling into them, and stands next to you constantly criticizing you while you clean them up by yourself. "You aren't using that variable any more, clean that up too." "There's no new variables now, so use `err =` instead of `err :=`."
Dane here, and I just don't see the point of using Apple or Google pay. Aside from not wanting American tech interfering in, or data harvesting, my finances, it's not any easier to use. I just touch my card to the terminal and payment happens. Some times, or if the amount is over some limit, I have to enter a pin. I cringe every time I see someone contorting their arm to pay with their watch. It's tech for the sake of tech.
Interestingly, isn't that almost exactly what Garmin has done with their wearable ecosystem? A massive data collection people willingly agree to because of the perceived benefits.
Garmin was a long-standing well-respected consumer hardware company that started releasing a miniaturized version of the thing they were famous for: a GPS. They already had brand recognition and all the infrastructure to build quality products that people would trust.
That infrastructure and brand is extremely difficult to bootstrap.
Chromecast only works from iOS for apps that have integrated with the Chromecast SDK. Like Netflix and Youtube.
Maybe the EU can ask Google to open Chromecast up so Apple can integrate it into iOS. Then you can use it from any app without needing special integrations.
Apple has all the information they need, available publicly, to implement an OS-wide Chromecast client. They haven't done so because they don't want to.
reply