Sure, but then your issue is with type coercion, not operator overloading.
Sure, but then your issue is with type coercion, not operator overloading.
It should just randomly pick any “1”. Add a bit of spice, you know
That’s the case in many languages, pretty much in all that don’t have a separate string concatenation operator.
As such we had to install openrgb the usual system-wide way, with rpm-ostree in terminal - something I was hoping he would never had to do.
There is nothing wrong with doing that if there’s no better option. You’re not losing out on anything.
Python has a bunch of magic variables, like __name__
. This one contains the name of the module you’re currently in (usually based on the file name), so if your file is called foo.py
, it will have the value foo
.
But that’s only if your module is being imported by another module. If it’s executed directly (e.g. python foo.py
), it will instead have a __name__
of __main__
. This is often used to add a standalone CLI section to modules - e.g. the module usually only defines functions that can be imported, but when executed it runs an example of those functions.
Sure, that’s one approach. But there’s probably a bunch of people that have multiple screens layed out horizontally with slight vertical offsets, and they’d probably prefer the wallpaper to be assigned as if they were in one row.
Doesn’t seem incredibly straightforward to me, since screens can be set up in any configuration relative to each other. You pretty much would have to implement multiple options to make everyone happy, at which point it’s not a small feature anymore.
I see what you’re trying to get at. It’s not that we can definitely know the state, it’s that we could build the experiment in such a way that we can definitely know the state - and by not building it this way we’re essentially deliberately “throwing away” information about the final state.
Thanks for the explanation!
But that’s ignoring that there are multiple paths that can lead to state z
, isn’t it?
I’ll try to design the simplest possible experiment: you have to radioactive atoms, each connected to a detector, and the detectors are connected to a counter. You leave the room and come back - the counter shows 2. How do you determine which atom decayed first?
Sorry, it’s been a long time since I last looked at the mathematical side of quantum mechanics, so most of your comment flew over my head. Let me put it in as simple terms as I can:
If there are multiple paths a system can take to reach a final state, how can you accurately determine which path was taken if you only know the initial & final state? IMO this shouldn’t be possible.
Hm, I’m not sure if I understand the abstract correctly.
Say I build two Schrödingers cat experiments next to each other, and connect them so that each vial dispersing the poison also makes the other vial disperse poison. I go away, and come back to both vials having triggered and both nuclear decays having occurred. How could I determine the path the whole system took?
Scientists believed this for the longest time, but I’ve recently seen a documentary explaining that, at the very bottom, there’s a giant koala bear. Apparently they’re still trying to determine why it’s smiling.
If our universe requires a being outside it as an origin, why shouldn’t that being itself require another being of even further outside as an origin, and so on?
“inherently probabilistic and can’t be determined” is just another way of saying “random” or “we don’t know yet”.
Well yes, it means “random”. Of course there’s always a chance that we’re just missing something fundamental, but it would mean that literally every model we have is completely wrong. Unless we find indications for that (and there don’t seem to be any so far) I think it’s fair to assume that quantum interactions are actually random.
If reality was not deterministic, the reliability of models and predictions in physics would be upended.
No, because reality is not deterministic, yet the reliability of models and predictions in physics is not upended. There simply are enough of these interactions happening that, in the “macro” world, we can talk about them deterministically, since they are probabilistic. But that doesn’t mean the “micro” interactions are deterministic, and it also doesn’t mean it’s impossible for a “macro” interaction to be non-deterministic - again, the example of Schrödingers cat comes to mind.
You could literally build a non-deterministic experiment right now if you wanted to.
Just pointing this out - we don’t live in a deterministic reality. Quantum interactions are inherently probabilistic and can’t be predetermined. This usually doesn’t matter, but you can chain larger classical systems onto quantum interactions (i.e. Schrödingers cat), which makes them non-deterministic as well.
We had one null
, yes. But what about second null
?
typeof null === "object"
was actually a bug in the early implementations, and they decided to keep it in the spec: https://2ality.com/2013/10/typeof-null.html
(see the comment from Brendan Eich)
You’re thinking a little too hard about a silly joke
That depends entirely on whether the un- prefix only negates the other un- prefix, or the entire adjective.
There is operator overloading happening - the
+
operator has a different meaning depending on the types involved. Your issue however seems to be with the type coercion, not the operator overloading.If you don’t want it to happen either use a different language, or ensure you don’t run into this case (e.g. by using Typescript). It’s an unfortunate fact that this does happen, and it will never be removed due to backwards compatibility.