Re: [Bug-apl] Circle

[Juergen Sauermann]

Hi Mike,

thanks, fixed in SVN 672.

/// Jürgen

On 08/31/2015 04:21 PM, Mike Duvos wrote:

Hi,

¯4○ is supposed to be equal to  5○¯6○.  While trying to check this on GNU APL, I noticed your ARCCOSH gives a domain error on my vector.

      ⎕IO←0
      X←1D45*⍳8

      8 1⍴¯6○X
DOMAIN ERROR
      8 1⍴¯6○X
          ^  ^

APL2 returns the answer.  If I write my own ARCCOSH...

    ∇
[0]   Z←ARCCOSH X
[1]   Z←(X+1)⋆0.5
[2]   Z←Z×(X-1)⋆0.5
[3]   Z←X+Z
[4]   Z←⍟Z
    ∇

      8 1⍴ARCCOSH X
             0
7.642854597E¯1J9.989374566E¯1
 8.81373587E¯1J1.570796327E0
7.642854597E¯1J2.142655197E0
3.814090015E¯8J3.141592615E0
7.642854597E¯1J¯2.142655197E0
 8.81373587E¯1J¯1.570796327E0
7.642854597E¯1J¯9.989374566E¯1

Then I get a result, which agrees with APL2 to a few decimal places in most places.

On Sun, Aug 30, 2015 at 11:24 PM, Mike Duvos <address@hidden> wrote:

Hi,

I looked into the ¯4○ thing a bit more and have identified the discrepancy between APL2 and GNU APL, which may or not be a bug depending on whether the ISO spec agrees with APL2 on this function.

According to the APL2 language reference, if the real part is greater than or equal to zero, or the real part is between -1 and zero with the imaginary part zero, you return (¯1+X×X)*0.5.  Otherwise you flip the sign and return -(¯1+X×X)*0.5.

So in APL2....

      8 1⍴¯4○1D45*-⎕IO-⍳8
 0.000000000E0                 
 4.550898606E¯1J 1.098684113E0 
 7.146297292E¯16J 1.414213562E0
¯4.550898606E¯1J 1.098684113E0 
¯3.814090016E¯8J 3.814090016E¯8
¯4.550898606E¯1J¯1.098684113E0 
¯1.342666713E¯15J¯1.414213562E0
 4.550898606E¯1J¯1.098684113E0 

and in GNU APL

     8 1⍴¯4○1D45*-⎕IO-⍳8
             0
4.550898606E¯1J1.098684113E0
             0J1.414213562E0
4.550898606E¯1J¯1.098684113E0
 1.10663761E¯8J¯1.10663761E¯8
4.550898606E¯1J1.098684113E0
             0J1.414213562E0
4.550898606E¯1J¯1.098684113E0

As you can see, APL2 flips the signs on half the values, and GNU APL does not.

So APL2 cancels, and GNU APL adds up to a big value when you sum them.

So that's why they are different.

Whether this is "wrong" remains to be seen, but it's a case where APL2 and GNU APL do things differently.

On Sun, Aug 30, 2015 at 9:37 PM, Mike Duvos <address@hidden> wrote:

Dropped an iota in the prior post.

        X←1D1*⍳360
        +/¯4○X
¯3.814090113E¯8J3.814086508E¯8

That changes the IBM result slightly, but the GNU APL one is still off by a large amount.

On Sun, Aug 30, 2015 at 9:13 PM, Mike Duvos <address@hidden> wrote:

      )CLEAR
CLEAR WS
      ⎕IO←0
      X←1D1*360
      +/(¯1+X×X)*0.5
5.393937829E¯8J¯5.393937829E¯8 

[IBM APL2]
     

      +/¯4○X
5.393937829E¯8J¯5.393937829E¯8

[GNU APL]

      +/¯4○X
122.0040743J2.828427087

I think this is wrong.