A real EPR-Bohm scenario

[Joy Christian]

I am not sure why you have the g-function as you don't call it in the simulation. I also found out that sign(p(a,e)) as you have it programmed is not quite the same as using the acos() function that I was originally using so a bit of a mystery as to why both ways work.

I call the g-function in the second part (for f = 0 case), but we don't have to. We have an option to call it for the main part also. I have done it this way to retain the connection with the original "complete state" theory behind the simulation: https://arxiv.org/abs/1405.2355. "acos()" is just a way of writing the "Angles", so it is not surprising that both of them work. "sign(p(a,e))" is exactly the function Bell used in his own local model of 1964. But he missed the q(a,e,s) part from the g-function.

I'm hung up with trying to program a full arc cosine function for GAViewer. I suspect it is also the difference between the R version and Mathematica version. I need it for GAViewer so that I can get the angles properly for b - a. As you know, arc cosine only works 0 to pi and gives the wrong angles for quadrants 2, 3 and 4 based on cosine values. But knowing both cosine and sine values it is possible to have a full arc cosine function that works from 0 to 2pi correctly. I'm almost there.
.

In Mathematica, or in the GAViewer, you don't have the "function" thing we have in R. May be that is what is missing?

***

[FrediFizzx]

In Mathematica, or in the GAViewer, you don't have the "function" thing we have in R. May be that is what is missing?

***

They both have function calls just like R. I think this does it for GAViewer.

Code: Select all

function acosfull(w, z)
{
     if(z == w && z == 0) {theta=0;} else {if(w>0 && z>0){theta = (2*acos(z) - asin(w))*180/pi;}
     if(w<0 && z>0){theta = (2*acos(z) - asin(w))*180/pi;}
     else {if(w<0 && z<0){theta = (2*acos(z) + asin(w))*180/pi;} else{theta = (2*acos(z) + asin(w))*180/pi;}}}

     return(theta);
}


Where "w" is the sine value and "z" is the cosine value and this is just getting the angle for a or b but not for b - a yet. It seems to work in Mathematica but I have a mistake somewhere in GAViewer. I will find it.
.

[ajw]

What are you trying to accomplish? Apart for the situation where both z and w are zero, the return of your function only depends on the sign of z, as can be clearly seen if I rewrite it a bit:

Code: Select all

function acosfull(w, z)
{
    if (z == w && z == 0)
    { theta = 0; }
    else
    {
        if(w > 0)
        {
            if(z > 0)
            {
                theta = (2 * acos(z) - asin(w)) * 180 / pi;
            }
            else
            {
                theta = (2 * acos(z) + asin(w)) * 180 / pi;
            }
        }
        else
        {
            if (z > 0)
            {
                theta = (2 * acos(z) - asin(w)) * 180 / pi;
            }
            else
            {
                theta = (2 * acos(z) + asin(w)) * 180 / pi;
            }
        }
    }
    return (theta);
}

[FrediFizzx]

What are you trying to accomplish? Apart for the situation where both z and w are zero, the return of your function only depends on the sign of z, as can be clearly seen if I rewrite it a bit:

Code: Select all

function acosfull(w, z)
{
    if (z == w && z == 0)
    { theta = 0; }
    else
    {
        if(w > 0)
        {
            if(z > 0)
            {
                theta = (2 * acos(z) - asin(w)) * 180 / pi;
            }
            else
            {
                theta = (2 * acos(z) + asin(w)) * 180 / pi;
            }
        }
        else
        {
            if (z > 0)
            {
                theta = (2 * acos(z) - asin(w)) * 180 / pi;
            }
            else
            {
                theta = (2 * acos(z) + asin(w)) * 180 / pi;
            }
        }
    }
    return (theta);
}

Hi Albert Jan,

As you know, when we have random angles for a and b in GAViewer we have something like,

a = -0.51*e1 + -0.86*e2

for 2D angles. The coefficient value for e1 is the sine value and for e2 is the cosine value. I want to take those and get what the angle is in degrees for the full 0 to 2pi rotation. Once I have that, then it is easy to get b - a for the correlation angles. I need that to match up the A*B +/-1 data for the correlation. Which I will take and then calculate and plot in Excel.
.

[ajw]

So you mean because the e3 component is zero and the vector is normalized, the -0.51 is the cos.
Can it be best just to use the e1 component for both a and b, and calculate each angle with acos?
Then take abs(angleA - angleB). When this is >180, subtract 180 to have the smallest angle. Something like this?:

Code: Select all

function toDegrees(x)
{
    return 180 * x / PI;
}
function acosfull(ae1, be1)
{
    angleA = toDegrees(acos(ae1));
    angleB = toDegrees(acos(be1));
    angle = abs(angleA - angleB);
    if(angle > 180)
    {
        angle = angle - 180;
    }
    return angle;
}


[FrediFizzx]

So you mean because the e3 component is zero and the vector is normalized, the -0.51 is the cos.
Can it be best just to use the e1 component for both a and b, and calculate each angle with acos?
Then take abs(angleA - angleB). When this is >180, subtract 180 to have the smallest angle. Something like this?:

Code: Select all

function toDegrees(x)
{
    return 180 * x / PI;
}
function acosfull(ae1, be1)
{
    angleA = toDegrees(acos(ae1));
    angleB = toDegrees(acos(be1));
    angle = abs(angleA - angleB);
    if(angle > 180)
    {
        angle = angle - 180;
    }
    return angle;
}


Oh, if -0.51 is the cosine value then that is one of my mistakes. I thought it was the sine value. I believe I got that from one of your simulations here,

viewtopic.php?f=6&t=200&p=5549#p5496

Anyways, I will try out your suggestion.
.

[FrediFizzx]

So you mean because the e3 component is zero and the vector is normalized, the -0.51 is the cos.
Can it be best just to use the e1 component for both a and b, and calculate each angle with acos?
Then take abs(angleA - angleB). When this is >180, subtract 180 to have the smallest angle. Something like this?:

Code: Select all

function toDegrees(x)
{
    return 180 * x / PI;
}
function acosfull(ae1, be1)
{
    angleA = toDegrees(acos(ae1));
    angleB = toDegrees(acos(be1));
    angle = abs(angleA - angleB);
    if(angle > 180)
    {
        angle = angle - 180;
    }
    return angle;
}


Oh, if -0.51 is the cosine value then that is one of my mistakes. I thought it was the sine value. I believe I got that from one of your simulations here,

viewtopic.php?f=6&t=200&p=5549#p5496

Anyways, I will try out your suggestion.
.

It doesn't work. acos(ae1) doesn't give the correct angle thru the full range of 0, 2pi. It only works correctly from 0 to pi/2.
.

[ajw]

Of course, you're right. The sign of ae2 determines whether angleA is positive or negative. But it is strange that the acos in GAViewer doesn't work between 0 and -1 (I didn't check that) .
(e1 and e2 are interchangeable, so I don't think it matters which of the coefficients is taken to be the sin, and which one the cos)

Are you sure in your simulation the norm of the vector is 1? In the original simulations the 3 vector had length 1, but taking e3 along the direction of propagation of the particle and therefore ignorable doesn't automatically normalize the components for e1 and e2. In that case they are not equal to sin and cos.

[FrediFizzx]

Of course, you're right. The sign of ae2 determines whether angleA is positive or negative. But it is strange that the acos in GAViewer doesn't work between 0 and -1 (I didn't check that) .
(e1 and e2 are interchangeable, so I don't think it matters which of the coefficients is taken to be the sin, and which one the cos)

Are you sure in your simulation the norm of the vector is 1? In the original simulations the 3 vector had length 1, but taking e3 along the direction of propagation of the particle and therefore ignorable doesn't automatically normalize the components for e1 and e2. In that case they are not equal to sin and cos.

Yes the norm is 1; GAViewer reports the magnitude as 1 for the angles a and b and checking the values using Mathematica also gives 1 for the norm. I will make sure that it doesn't matter for the interchange of sine or cosine for e1. Though I think you are right about that.

acos works in GAViewer but it doesn't give the correct angle because it doesn't know exactly what quadrant the angle is in if sine is not used along with it somehow. IOW, if the cosine value is positive, acos doesn't know if it is the first or second quadrant so it always just gives the angle for the first quadrant. Ditto for quadrants 3 and 4 if it is negative.
.

[FrediFizzx]

It is the atan2(y, x) function that gives the angle knowing sine and cosine values. However, its range is -pi to +pi so just have to program it to convert the -pi's to the correct + angle in quadrants 3 and 4.

Sheesh, I think I already had this figured out a couple years ago.

[ajw]

Of course, you're right. The sign of ae2 determines whether angleA is positive or negative. But it is strange that the acos in GAViewer doesn't work between 0 and -1 (I didn't check that) .
(e1 and e2 are interchangeable, so I don't think it matters which of the coefficients is taken to be the sin, and which one the cos)

Are you sure in your simulation the norm of the vector is 1? In the original simulations the 3 vector had length 1, but taking e3 along the direction of propagation of the particle and therefore ignorable doesn't automatically normalize the components for e1 and e2. In that case they are not equal to sin and cos.

Yes the norm is 1; GAViewer reports the magnitude as 1 for the angles a and b and checking the values using Mathematica also gives 1 for the norm. I will make sure that it doesn't matter for the interchange of sine or cosine for e1. Though I think you are right about that.

acos works in GAViewer but it doesn't give the correct angle because it doesn't know exactly what quadrant the angle is in if sine is not used along with it somehow. IOW, if the cosine value is positive, acos doesn't know if it is the first or second quadrant so it always just gives the angle for the first quadrant. Ditto for quadrants 3 and 4 if it is negative.
.

ok, then perhaps this does the job (making the angles negative instead of having them in the 3th and 4th quadrant shouldn't make any difference when trying to get the smallest angle between a and b)?

Code: Select all

function toDegrees(x)
{
    return 180 * x / PI;
}
function sign(x)
{
    if(x>0)
    {
        return 1;
    }
    else
    {
        return -1;
    }
}
function acosfull(ae1, ae2, be1, be2)
{
    angleA = sign(ae2) * toDegrees(acos(ae1));
    angleB = sign(be2) * toDegrees(acos(be1));
    angle = abs(angleA - angleB);
    if(angle > 180)
    {
        angle = angle - 180;
    }
    return angle;
}

[FrediFizzx]

ok, then perhaps this does the job (making the angles negative instead of having them in the 3th and 4th quadrant shouldn't make any difference when trying to get the smallest angle between a and b)?

Code: Select all

function toDegrees(x)
{
    return 180 * x / PI;
}
function sign(x)
{
    if(x>0)
    {
        return 1;
    }
    else
    {
        return -1;
    }
}
function acosfull(ae1, ae2, be1, be2)
{
    angleA = sign(ae2) * toDegrees(acos(ae1));
    angleB = sign(be2) * toDegrees(acos(be1));
    angle = abs(angleA - angleB);
    if(angle > 180)
    {
        angle = angle - 180;
    }
    return angle;
}

Yes, that may work but it is atan2(y, x) that does the trick of getting the angles when you know sine and cosine values. And it works in GAViewer.
.

[ajw]

Ah, missed your atan2 post

[FrediFizzx]

Ah, missed your atan2 post

Yeah, I think we were posting at the same time is why you didn't see it. I must have been a fraction of a second before you.

[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?

[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.

***

[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.

***

The polarizer action did work in R the same way as in Mathematica. I couldn't get your new way of polarizer action in R to work right in Mathematica. ???

[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.

***

The polarizer action did work in R the same way as in Mathematica. I couldn't get your new way of polarizer action in R to work right in Mathematica. ???

Perhaps Mathematica is not as good a coding language as R. It would be good if Michel takes a look at both programs. I am just an amateur programmer (if at all)!

***

[FrediFizzx]

Perhaps Mathematica is not as good a coding language as R. It would be good if Michel takes a look at both programs. I am just an amateur programmer (if at all)!

***

I haven't tried setting up Mathematica with fixed angles like the R simulations have. Perhaps that is worth trying to see if it is the difference. The programming in Mathematica has way more features than R but it is only as good as the programmer.

[minkwe]

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.

***

The polarizer action did work in R the same way as in Mathematica. I couldn't get your new way of polarizer action in R to work right in Mathematica. ???

Perhaps Mathematica is not as good a coding language as R. It would be good if Michel takes a look at both programs. I am just an amateur programmer (if at all)!

***

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.