What if there are hidden properties that affect each particle of a pair after they are split, in predetermined ways? that would certainly create correlations that seem to be created on the fly, but they would simply be the result of the inner workings of particles that don't communicate.
For example, if we have two balls, each containing a spin mechanism inside them which makes them spin in relation, let's say, to the magnetic north, and we throw one of them to the other...and later we discover that their spin is somehow correlated.
That is not action at a distance, that is the result of the inner mechanism of each ball.
> In general, classical correlation cannot break the Bell inequalities [assuming no peeking, ie. no action-at-a-distance in the measurement devices].
What if the particles have properties that mutate their state after they are sent to Alice and Bob?
Suppose, in the billiards example, that I put a small device into the balls that changes the spin of the ball to some predefined value.
Wouldn't that break the Bell inequalities without action at a distance?
The reason for the breaking would be that the state of the balls would be modified after they are sent to Alice and Bob. It would look like action at a distance without being 'action at a distance'.
> Victor can prepare a pair of quantum particles in a special state known as an entangled state. In this state, the outcomes of Alice's and Bob's measurements are not just random but are correlated in a way that defies any classical explanation based on local hidden variables.
What if there are no hidden properties per particle, but the combination of specific property values of particles allow for breaking Bell's Inequality?
I.e. what we call 'entanglement', it might not be 'action-at-a-distance', but the simple effect of the interaction of the properties of the two particles as they are generated.
For example, if we have two billiard balls, which are really close together, and we hit them with a third ball simultaneously, their spin will be correlated when we measure it for both balls (without taking into account other factors, i.e. friction, tilting of the table etc). Wouldn't that break Bell's inequality as well? the spins of the two balls will be correlated.
My question for Haskellers is how to do updates of values on a large scale, let's say in a simulation.
In imperative languages, the program will have a list of entities, and there will be an update() function for each entity that updates its state (position, etc) inline, i.e. new values are overwriten onto old values in memory, invoked at each simulation step.
In Haskell, how is that handled? do I have to recreate the list of entities with their changes at every simulation step? does Haskell have a special construct that allows for values to be overwritten, just like in imperative languages?
Please don't respond with 'use the IO monad' or 'better use another language because Haskell is not up for the task'. I want an actual answer. I've asked this question in the past in this and some other forums and never got a straight answer.
If you reply with 'use the IO monad' or something similar, can you please say if whatever you propose allows for in place update of values? It's important to know, for performance reasons. I wouldn't want to start simulations in a language that requires me to reconstruct every object at every simulation step.
I am asking for this because the answer to 'why Haskell' has always been for me 'why not Haskell: because I write simulations and performance is of concern to me'.
Here is a good approach between using microservices or a monolith: create your product as a series of libraries that can be used to built either a microservices-based product or a monolith product.
In this way, you can turn a monolith to microservices very easily, since the core of your code will be there already.
Requirements always exist in a project, even if they are not written.
And how they cannot exist, since the only reason a program is written is because of some need...
And since requirements always do exist, they better be in written form, so as that they can be referenced, tested, discussed etc.
In previous projects, JIRA was used. In the current project, an internal tool is used, pretty much similar to JIRA.
In some older projects, a simple Word document was used and an Excel sheet for tracking progress.
Writing a requirement should be simple enough: it shall either define things, or describe processes and their side effects.
It is better to have a dedicated person to write them, because the wording and style of requirements should be consistent, and the person that writes them will gradually be more and more experienced in writing better requirements.
Having good requirements makes it a lot easier for developers to write the required programs.
My idea for C++ memory safety would be compile time reference counting.
I.e. the compiler/tool to go through the code, as if it was executing, and apply reference counting to objects, revealing whether an object will be destroyed normally, prematurely or never.
This is what we actually do as humans by the way, when we are developing an algorithm in C++ with manual memory management. We do it implicitly though.
Nice pattern, but it only solves the problem of having to use a mutex, which is almost never the problem. Deadlocks are way more nastier to handle.
In order to solve deadlocks, I created a mutex that first does a try lock, then if that fails it unlocks all mutexes of the thread and then relocks them in memory order.
Not very efficient some times, especially if there are many mutexes involved (i.e maybe it does not scale up), but it allows me to have algorithms not deadlock.
Perhaps it could be made more efficient with various tricks, I may have to do research on that idea...
For string heavy workload, C is ideal, provided that you don't use C string functions.
You can always allocate a very large buffer and do your string operations there, using memncpy and the assorted functions which can be inlined in many architectures and be really fast.
Then you can dispose of the buffer really quickly with one call or reuse it for later operations by simply setting a few pointers to initial status...
Sincere question: could it be that the underlying structure of the universe is really simple but since we have no idea what it is we have to use exotic mathematics for it?
Reading the comments from top to bottom, the above is exactly what I wanted to write.