A real EPR-Bohm scenario

[FrediFizzx]

I'm not quite getting the significance of separate polarizer action. To me there is no conceptual difference between

1) source --> detector --> (+1 or -1)

and

2) source --> polarizer --> detector --> (+1 or -1)


the detector in (1) is always understood as including any polarizer action required to get the desired outcome. Is there a physically significant factor I'm missing? My point at RW had to do with time of measurement effects when the direction of the particle bivectors are dynamic. The issue does not arise if the bivectors are not changing direction.

In an EPR-Bohm scenario, it has to do with aligning the particle spins to the angle of the polarizer. That is what a Stern-Gerlach device does. IOW, if "s" is the direction vector of the A particle upon creation, it ("s") becomes "+/-a" before it hits the up or down detectors. Incorporating this polarizer action makes the simulation more like the real deal IMHO. When I first thought of having some kind of polarizer action in the simulations, I didn't think it would work. But to my surprise, it did work. Which means that it should be possible for a realistic model to have full prediction power.
.

[minkwe]

Fred,
Are you perhaps trying to model the SGM separately? That could be interesting. Otherwise I don't think it matters for EPRB. You could Think of the "detector" as a little black box which includes the magnet. By separating it out, you aren't really doing anything different for EPRB.

If you are interested in modelling the SGM, there are several experimental facts that will have to be obeyed by the model. Eh, the behaviour of several, SGMs in series, the effect of the length of the SGM, etc

[FrediFizzx]

Fred,
Are you perhaps trying to model the SGM separately? That could be interesting. Otherwise I don't think it matters for EPRB. You could Think of the "detector" as a little black box which includes the magnet. By separating it out, you aren't really doing anything different for EPRB.

If you are interested in modelling the SGM, there are several experimental facts that will have to be obeyed by the model. Eh, the behaviour of several, SGMs in series, the effect of the length of the SGM, etc

That is not the point. What are the angles (a - s) or (b - s)? Those angles are only relevant to perhaps the polarizer action in taking "s" to "a" or "b". In the simulations, it should be +/-cos(a) and +/-cos(b) not cos(a - s) and cos(b - s) to give the outcomes for A and B. By separating out the polarizer action, it is more like what would actually happen. And it works in the simulations. Now Joy simplified it a bit in R for the polarizer action to sign(cos(a - s)) and sign(cos(b -s)). And it still works in R but I can't get it to work in the Mathematica simulation. It would be good if you could verify the R simulation in Python somehow if you wish.

http://rpubs.com/jjc/233477

I am suspecting that the difference is between using fixed angles (R) and random angles (Mathematica). I am trying to setup Mathematica with fixed angles but not being a programmer, I am probably way over my head.
.

[minkwe]

That is not the point. What are the angles (a - s) or (b - s)? Those angles are only relevant to perhaps the polarizer action in taking "s" to "a" or "b". In the simulations, it should be +/-cos(a) and +/-cos(b) not cos(a - s) and cos(b - s) to give the outcomes for A and B. By separating out the polarizer action, it is more like what would actually happen.

Perhaps you are focusing too much on the words "detector", typically, "Alice's detector" is used to conceptualize everything that happens at Alice's station, which includes the polarizer and UP and DOWN detectors. The function A(a,s) -> +/- 1 represents everything combined into one.

Separating it out surely makes it closer to what will happen, which is good. But it is also making a statement about how polarizers work in the model. In which case you are saying the polarizers are doing

(a, s) -> +/-cos(a)
(b, s) -> +/-cos(b)

My point is that you haven't changed anything in the simulation by conceptualizing them separately. I'm not seeing any difference or the significance of the differentiation, unless you are interested in modelling the polarizer by itself. Otherwise It is exactly the same simulation.

But if you separate it out and call the first part "polarizer action", you better be sure that it reproduces all experimental results for how polarizers work.

As concerns the R vs Mathematica, I'm not proficient in either one. But given that I don't really see anything that has changed in the simulation, I'm not sure what I should verify in python. From what I see in jjc/233477

Source:
- particle = (e = random unit vector on sphere, s = random angle [0-pi))

Station:
- f(s) = -1 + (2/sqrt(1 + ((3 * s)/pi)))
- A(a; e, s) = +sign(a.e) * { sign(a.X) if |a.e| > f(s), 0 otherwise} and
- B(b; e, s) = -sign(b.e) * { sign(b.X) if |b.e| > f(s), 0 otherwise},
- where X is the vector (1,0,0)

Is that what you want me to verify?

[FrediFizzx]

Yes, but with fixed a and b angles. It doesn't work in Mathematica with random angles. What works in Mathematica for polarizer action is,

Code: Select all

If[Abs[angle - e] < Pi, d = 1, d = -1];  (*Polarizer for A Station*)


Same for B Station. That also works in R.

[Joy Christian]

After Michel's latest post on RW about polarizer action, I may go back to thinking that it can't be predicted. However, then why does it work in the simulations?

It doesn't work the way you wanted it to work in the R simulation. The factorized version with separated polarizers is equivalent to the original un-factorized version.

***

Michel is right. As I noted above, the R version that factorizes the polarizers and the previous R version that does not are equivalent. The difference is purely cosmetic.

***

[minkwe]

Yes, but with fixed a and b angles. It doesn't work in Mathematica with random angles. What works in Mathematica for polarizer action is,

Code: Select all

If[Abs[angle - e] < Pi, d = 1, d = -1];  (*Polarizer for A Station*)


Same for B Station. That also works in R.

What do you mean by "fixed a and b angles". Even when you simulate multiple angles randomly, you should still select just specific fixed angles to calculate the correlations for, should you?

[FrediFizzx]

Yes, but with fixed a and b angles. It doesn't work in Mathematica with random angles. What works in Mathematica for polarizer action is,

Code: Select all

If[Abs[angle - e] < Pi, d = 1, d = -1];  (*Polarizer for A Station*)


Same for B Station. That also works in R.

What do you mean by "fixed a and b angles". Even when you simulate multiple angles randomly, you should still select just specific fixed angles to calculate the correlations for, should you?

Notice in the very first line of the R sim that the angles are all fixed at 7.2 degree increments.

Angles = seq(from = 0, to = 360, by = 7.2) * 2 * pi/360

They are not randomly selected like with,

aliceAngle = RandomReal[{0, 2*Pi}]
.

[minkwe]

Yes, but with fixed a and b angles. It doesn't work in Mathematica with random angles. What works in Mathematica for polarizer action is,

Code: Select all

If[Abs[angle - e] < Pi, d = 1, d = -1];  (*Polarizer for A Station*)


Same for B Station. That also works in R.

What do you mean by "fixed a and b angles". Even when you simulate multiple angles randomly, you should still select just specific fixed angles to calculate the correlations for, should you?

Notice in the very first line of the R sim that the angles are all fixed at 7.2 degree increments.

Angles = seq(from = 0, to = 360, by = 7.2) * 2 * pi/360

They are not randomly selected like with,

aliceAngle = RandomReal[{0, 2*Pi}]
.

Yes, I see that the R version does not randomly pick the angles but iterates through the range sequentially. It shouldn't matter unless there's an error somewhere. You can also generate the list of pairs of angles in the same way in Mathematica and verify that it works before you generate a random list of pairs of angles.

[FrediFizzx]

Yes, I see that the R version does not randomly pick the angles but iterates through the range sequentially. It shouldn't matter unless there's an error somewhere. You can also generate the list of pairs of angles in the same way in Mathematica and verify that it works before you generate a random list of pairs of angles.

Easier said than done. If you can get the R version to work in Python, I can probably translate that to Mathematica a bit easier. But I will keep on struggling through doing the R version in Mathematica. It is a good learning process if nothing else. It is just going to take me a long time.

I don't see any errors in the R code. And yes, it shouldn't matter as you say.

[minkwe]

The framework I use for my simulations is quite different from those used in the R code since I'm doing a networked event-by-event simulation. In my framework, a new model simply has to define two functions "particle_emitter", which produces two particles and "particle_detector", which produces an array of 3 numbers for each detected particle [time-offset, setting, outcome]. With this model, I can easily simulate many different models. I did the following test of the above equations in my framework as follows:

Code: Select all

def particle_emitter():
        e = ga.randVec3d()
        s = numpy.random.uniform(0, 1) 
        Pr = s + e + ga.I  # Right particle
        Pl = s + e - ga.I  # Left particle
        return Pl.value, Pr.value

def particle_detector(info):
    particle, setting = info
    a = ga.ang2Vec3d(theta=setting, phi=numpy.pi/2)
    z = particle[-1]
    s = particle[0]
    particle[0] = 0; particle[-1] = 0 # zero out scalar and tri-vector parts after reading them

    # read particle e is just the vector part
    e = ga.MultiVector(ga.layout, value=particle)

    # polarizer action
    f = -1 + 2 / numpy.sqrt(1 + 3*s)
    pol = (a*e).value[0]

    out = z*numpy.sign(pol) if abs(pol) > f else 0
    return [0, setting, out]

The framework takes care of generating the particles according to the specification, detecting them, and doing the analysis. For the above code, it produces

https://drive.google.com/open?id=0B6sZy ... 2xaUHRvYWs

[thray]

Michel -- beautiful.

[FrediFizzx]

The framework I use for my simulations is quite different from those used in the R code since I'm doing a networked event-by-event simulation. In my framework, a new model simply has to define two functions "particle_emitter", which produces two particles and "particle_detector", which produces an array of 3 numbers for each detected particle [time-offset, setting, outcome]. With this model, I can easily simulate many different models. I did the following test of the above equations in my framework as follows:

Code: Select all

def particle_emitter():
        e = ga.randVec3d()
        s = numpy.random.uniform(0, 1) 
        Pr = s + e + ga.I  # Right particle
        Pl = s + e - ga.I  # Left particle
        return Pl.value, Pr.value

def particle_detector(info):
    particle, setting = info
    a = ga.ang2Vec3d(theta=setting, phi=numpy.pi/2)
    z = particle[-1]
    s = particle[0]
    particle[0] = 0; particle[-1] = 0 # zero out scalar and tri-vector parts after reading them

    # read particle e is just the vector part
    e = ga.MultiVector(ga.layout, value=particle)

    # polarizer action
    f = -1 + 2 / numpy.sqrt(1 + 3*s)
    pol = (a*e).value[0]

    out = z*numpy.sign(pol) if abs(pol) > f else 0
    return [0, setting, out]

The framework takes care of generating the particles according to the specification, detecting them, and doing the analysis. For the above code, it produces

https://drive.google.com/open?id=0B6sZy ... 2xaUHRvYWs

Great, thanks. I guess that verifies the R code. Though "f = -1 + 2 / numpy.sqrt(1 + 3*s)" is not part of the polarizer action. It is part of lambda in complete states.

Can you try it with random angles?
.

[FrediFizzx]

After Michel's latest post on RW about polarizer action, I may go back to thinking that it can't be predicted. However, then why does it work in the simulations?

It doesn't work the way you wanted it to work in the R simulation. The factorized version with separated polarizers is equivalent to the original un-factorized version.

***

Michel is right. As I noted above, the R version that factorizes the polarizers and the previous R version that does not are equivalent. The difference is purely cosmetic.

***

Yes, we already figured that they are equivalent. But it is more than just cosmetic. It is the way EPR-Bohm actually works. The original creation polarization goes to +/-a and +/-b... if it can. As Michel pointed out, modelling the polarizers correctly could lead to new insights. For instance, if the original polarization is pointed down the beamline (in the direction of propagation) or close to it, maybe it can't get aligned with the A or B station polarizers. Thus no detection. Is there an angle from the beamline that defines what can get aligned with the polarizer thus be detected or not? Just tossing out some speculation about it here.

Plus there is what Michel was talking about on RW.
.

[minkwe]

The framework I use for my simulations is quite different from those used in the R code since I'm doing a networked event-by-event simulation. In my framework, a new model simply has to define two functions "particle_emitter", which produces two particles and "particle_detector", which produces an array of 3 numbers for each detected particle [time-offset, setting, outcome]. With this model, I can easily simulate many different models. I did the following test of the above equations in my framework as follows:

Code: Select all

def particle_emitter():
        e = ga.randVec3d()
        s = numpy.random.uniform(0, 1) 
        Pr = s + e + ga.I  # Right particle
        Pl = s + e - ga.I  # Left particle
        return Pl.value, Pr.value

def particle_detector(info):
    particle, setting = info
    a = ga.ang2Vec3d(theta=setting, phi=numpy.pi/2)
    z = particle[-1]
    s = particle[0]
    particle[0] = 0; particle[-1] = 0 # zero out scalar and tri-vector parts after reading them

    # read particle e is just the vector part
    e = ga.MultiVector(ga.layout, value=particle)

    # polarizer action
    f = -1 + 2 / numpy.sqrt(1 + 3*s)
    pol = (a*e).value[0]

    out = z*numpy.sign(pol) if abs(pol) > f else 0
    return [0, setting, out]

The framework takes care of generating the particles according to the specification, detecting them, and doing the analysis. For the above code, it produces

https://drive.google.com/open?id=0B6sZy ... 2xaUHRvYWs

Great, thanks. I guess that verifies the R code. Though "f = -1 + 2 / numpy.sqrt(1 + 3*s)" is not part of the polarizer action. It is part of lambda in complete states.

Can you try it with random angles?
.

Hi Fred,
The above is with random angles. My simulation framework always uses random angles.

What I presented above is:

Station:
- f(s) = -1 + (2/sqrt(1 + ((3 * s)/pi)))
- A(a; e, s) = +sign(a.e) if |a.e| > f(s), 0 otherwise
- B(b; e, s) = -sign(b.e) if |b.e| > f(s), 0 otherwise

NOT

Station:
- f(s) = -1 + (2/sqrt(1 + ((3 * s)/pi)))
- A(a; e, s) = +sign(a.e) * { sign(a.X) if |a.e| > f(s), 0 otherwise} and
- B(b; e, s) = -sign(b.e) * { sign(b.X) if |b.e| > f(s), 0 otherwise},
- where X is the vector (1,0,0)

Which did not work.

[minkwe]

Great, thanks. I guess that verifies the R code. Though "f = -1 + 2 / numpy.sqrt(1 + 3*s)" is not part of the polarizer action. It is part of lambda in complete states.

Code: Select all

def particle_emitter():
    e = ga.randVec3d()
    s = numpy.random.uniform(0, 1)
    f = -1 + 2 / numpy.sqrt(1 + 3 * s)
    Pr = e + f + ga.I  # Right particle
    Pl = e + f - ga.I  # Left particle
    return Pl.value, Pr.value

def particle_detector(info):
    particle, setting = info
    a = ga.ang2Vec3d(theta=setting, phi=numpy.pi/2)
    z = particle[-1]    # represents which arm we are on, left or right
    f = particle[0]
    particle[0] = 0; particle[-1] = 0 # zero out scalar and tri-vector parts

    # read particle e is just the vector part
    e = ga.MultiVector(ga.layout, value=particle)

    pol = (a*e).value[0]
    out = z*numpy.sign(pol) if abs(pol) > f else 0

    return [0, setting,out]


Fred the above is effectively the same and produces the same results. But note that there is no X in it.

[minkwe]

Actually, thinking about it, it is simpler to have:

s = [1,4)
f(s) = -1 + 2/√s

instead of

s = [0, π)
f(s) = -1 + 2/√(1 + 3s/π)

both have exactly the same effect

[FrediFizzx]

Hi Fred,
The above is with random angles. My simulation framework always uses random angles.

What I presented above is:

Station:
- f(s) = -1 + (2/sqrt(1 + ((3 * s)/pi)))
- A(a; e, s) = +sign(a.e) if |a.e| > f(s), 0 otherwise
- B(b; e, s) = -sign(b.e) if |b.e| > f(s), 0 otherwise

NOT

Station:
- f(s) = -1 + (2/sqrt(1 + ((3 * s)/pi)))
- A(a; e, s) = +sign(a.e) * { sign(a.X) if |a.e| > f(s), 0 otherwise} and
- B(b; e, s) = -sign(b.e) * { sign(b.X) if |b.e| > f(s), 0 otherwise},
- where X is the vector (1,0,0)

Which did not work.

Oh, right. So the R code is not verified with random angles and there seems to be a difference for some reason. Is there a way you can do fixed angles in your framework?

Or... can you try the polarizer action that I am using in Mathematica to verify it?

If[Abs[angle - e] < pi, then pol = 1, else pol = -1]
.

[minkwe]

Fred,
Where in the model does this condition appear:

If[Abs[angle - e] < pi, then pol = 1, else pol = -1]

It doesn't look to me like anything that appears in the model.

- f(s) = -1 + (2/sqrt(1 + ((3 * s)/pi)))
- A(a; e, s) = +sign(a.e) if |a.e| > f(s), 0 otherwise
- B(b; e, s) = -sign(b.e) if |b.e| > f(s), 0 otherwise

I'm still trying to understand what your intention is with respect to the "polarizer action". Does the above expression represent enough of the polarizer action that you expect. What would you expect in addition to the above for it to qualify as including "polarizer action".

Please use the following image for reference

[FrediFizzx]

Fred,
Where in the model does this condition appear:

If[Abs[angle - e] < pi, then pol = 1, else pol = -1]

It doesn't look to me like anything that appears in the model.

- f(s) = -1 + (2/sqrt(1 + ((3 * s)/pi)))
- A(a; e, s) = +sign(a.e) if |a.e| > f(s), 0 otherwise
- B(b; e, s) = -sign(b.e) if |b.e| > f(s), 0 otherwise

I'm still trying to understand what your intention is with respect to the "polarizer action". Does the above expression represent enough of the polarizer action that you expect. What would you expect in addition to the above for it to qualify as including "polarizer action".

The sign(a.e) and the sign(b.e) are wrong as I mentioned previously for A and B functions. What the heck are the angles (a - e) = c and (b - e) = d? IOW, what are "c" and "d"? As far as I can ascertain, they only have to do with the polarizer action and complete state selection so the A and B functions should be using "pol" from If[Abs[angle - e] < pi, then pol = 1, else pol = -1],

- A(a; e, s) = +sign(cos(a*pol)) if |a.e| > f(s), 0 otherwise
- B(b; e, s) = -sign(cos(b*pol)) if |b.e| > f(s), 0 otherwise

That works in Mathematica with random angles and also works in R with fixed angles. IOW, the main part of the A and B functions is sign(cos(+/- angle)) where the +/- are determined by polarizer action and complete state selection is determined by abs(cos(angle - e)) and f(s).

Basically it matches better with what Joy is expressing in his GA math limits with a slight change. e --> +/-a and e' --> +/-b.
.