Group Abstract Group Abstract

Message Boards Message Boards

0
|
4.1K Views
|
9 Replies
|
7 Total Likes
View groups...
Share
Share this post:

Unexpected behavior from Arg in v13.3

After installing 13.3 and testing my code I ran into an issue with Arg which i guess has to do with something in the handling of the numerical precision of complex numbers. To prevent stuff happing in the background of my data i always mask that out by multiplication with exact 0 values. However in 13.3 doing that Arg[0.+0.I] gives back 0. or 3.14159 rather random. However Arg[Re[0.+0.I]+0.I] or Arg[0.+Im[0.+0.I]I] both always produce 0 for the same data.

I have found a workaround for my code which is using Chop before Arg which for hundreds of iterations is slowing down the code but solves it for now.

Does anybody have any ideas how to prevent this? Any number multiplied by an exact 0 should return 0. right? Or are there any cases where this assumption is not correct.

Here is my example, I can't share the data and have not been able to make a toy example that reproduces the effect. I'm using identical data and code for both Mathematica versions.

  1. this was the difference in output that started my hunt for the changed behavior. enter image description here

  2. I isolated the issue to this part of my code. enter image description here

  3. The binary mask (which contains rounded 0 and 1) is multiplied with the complex data (for which here the Re and Im are shown) enter image description here

  4. Now the weird stuff is happening after taking the Arg of the complex data i get non zero values in the background of the image which i never encountered before in any version of Mathematica. enter image description here

  5. So i selected some of the background datapoints and tested what is happening. Here is my expected output for v13.2 enter image description here

Here is my unexpected output for v13.3 enter image description here

The best example i could come up with is below but this behaves exactly as i expect.

n = 200;
m = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
Arg[ {
  ( -(10.^-n + (10.^-n) I)), (10.^-n + (10.^-n) I), ( -(10.^-n + (0.) \
I)), (10.^-n + (0.) I), ( -(0. + (10.^-n) I)), (0. + (10.^-n) I),
  ( -(10.^-n - (10.^-n) I)), (10.^-n - (10.^-n) I), ( -(10.^-n - (0.) \
I)), (10.^-n - (0.) I), ( -(0. - (10.^-n) I)), (0. - (10.^-n) I)
  }]
Arg[m {
   ( -(10.^-n + (10.^-n) I)), (10.^-n + (10.^-n) I), ( -(10.^-n + \
(0.) I)), (10.^-n + (0.) I), ( -(0. + (10.^-n) I)), (0. + (10.^-n) \
I),
   ( -(10.^-n - (10.^-n) I)), (10.^-n - (10.^-n) I), ( -(10.^-n - \
(0.) I)), (10.^-n - (0.) I), ( -(0. - (10.^-n) I)), (0. - (10.^-n) I)
   }]

{-2.35619, 0.785398, 3.14159, 0., -1.5708, 1.5708, 2.35619, \
-0.785398, 3.14159, 0., 1.5708, -1.5708}

{0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.}

EDIT

did some extra experiments where i can show that multiplying with 0 or 0. does not remove the effect but any other operation does.

{
DeleteDuplicates[
 Arg[Round[
    B0mask[[16, 81, 40 ;; -40]]] compi[[4, 16, 81, 
     40 ;; -40]]]](*has Pi*),
DeleteDuplicates[
 Arg[N[Round[B0mask[[16, 81, 40 ;; -40]]]] compi[[4, 16, 81, 
     40 ;; -40]]]](*has Pi*),
DeleteDuplicates[
 Arg[B0mask[[16, 81, 40 ;; -40]] Chop[
    compi[[4, 16, 81, 40 ;; -40]]]]](*no Pi, Int*),

DeleteDuplicates[
 Arg[B0mask[[16, 81, 40 ;; -40]] (Re[compi[[4, 16, 81, 40 ;; -40]]] + 
     0. I)]](*no Pi, N*),
DeleteDuplicates[
 Arg[B0mask[[16, 81, 40 ;; -40]] (0. + 
     Im[compi[[4, 16, 81, 40 ;; -40]]] I)]](*no Pi, N*),

DeleteDuplicates[
 Arg[Round[
    B0mask[[16, 81, 40 ;; -40]]] (Re[compi[[4, 16, 81, 40 ;; -40]]] + 
     0. I)]](*no Pi, N*),
DeleteDuplicates[
 Arg[Round[
    B0mask[[16, 81, 40 ;; -40]]] (0. + 
     Im[compi[[4, 16, 81, 40 ;; -40]]] I)]](*no Pi, N*),

DeleteDuplicates[
 Arg[N[Round[
     B0mask[[16, 81, 40 ;; -40]]]] (Re[
      compi[[4, 16, 81, 40 ;; -40]]] + 0. I)]](*no Pi, N*),
DeleteDuplicates[
 Arg[N[Round[B0mask[[16, 81, 40 ;; -40]]]] (0. + 
     Im[compi[[4, 16, 81, 40 ;; -40]]] I)]](*no Pi, N*)
}

Out[]= {{0., 3.14159}, {0., 
3.14159}, {0}, {0.}, {0.}, {0.}, {0.}, {0.}, {0.}}
POSTED BY: Martijn Froeling
9 Replies
Sort By:

Martijn, I doubt there is anything I can change about this, but I’ll take a look because it does seem suspicious. Your explanation in this recent response, and isolation of clear examples, is a big help.
POSTED BY: Daniel Lichtblau

The idea behind having 0*0.0 evaluate to 0.0 is to maintain the type rule int times real equal real. One can question this of course. But it has advantages particularly for type consistency and inferencing, as is needed in Compile and the newer FunctionCompile world.
POSTED BY: Daniel Lichtblau

I did check. It appears to be simply a bug. I filed a report for it.
POSTED BY: Daniel Lichtblau

Thanks Daniel! For now i know the reason why my code changed outputs and i have a fix for it which works in all versions and i learned some things on the way so I'm happy for now.

POSTED BY: Martijn Froeling

From the documentation on Numbers:

Whenever you give a number with an explicit decimal point, the Wolfram Language produces an approximate numerical result

Here is what happens by multiplying an approximate number by the exact zero:

In[2]:= 0*0.

Out[2]= 0.
POSTED BY: Gianluca Gorni
ZAQU zaqu
ZAQU zaqu
Posted 2 years ago

Can you check mine too? I recently downloaded 13.3 on my Debian linux and checked there is the same issue as in cloud.
POSTED BY: ZAQU zaqu

I am working with version 13.3 on a Mac. The command c = Unitize[arg] gives a list of zeros every time I try it.
POSTED BY: Gianluca Gorni
  • I agree that 0*0.0+0.0 I gives 0.0+0.0 I
  • I also expect that 0 * 0.0 + 10.0^-200 should give 0.0+0.0 I
  • I also expect that Arg[-10.^-200 + (0.)] = Pi and Arg[0.0+0.0 I] = 0.0

But that was not my point, Arg[0 *(-10.0^-200+0.0I)] should and has always evaluated to 0.0 but with Mathematica 13.3 it no longer does. In one case it goes to 0.0 and the other case it goes to Pi which is inconsistent and unexpected.

I found the test case that things are unexpected and they changed from Mathematica 13.2 to 13.3

  • The examples below all go to values i expect => Arg[0 x.] goes to 0.0

    In[347]:= (*define values*)
i = 50; n = 200.;
(*single number - evaluates to 0.0*)
Arg[0 (-10.^-n + (0.)) I]

(*manual list of numbers - all evaluate to 0.0 including negative Re*)
msk = {0, 0, 0, 0, 0};
comp = {(-0.0` 10.^-n + 0.0 I), -5.234654279824674565789` 10.^-n + 
    00. I, -4.32467641324676543243` 10.^-n + 0.0 I, 
   5.234654279824674565789` 10.^-n + 00. I, 
   4.32467641324676543243` 10.^-n + 0.0 I};
val = msk comp;
arg = Arg[val]
Thread[{msk, comp, val, arg}]

Out[348]= 0.

Out[352]= {0., 0., 0., 0., 0.}

Out[353]= {{0, 0. + 0. I, 0. + 0. I, 0.}, {0, -5.23465*10^-200 + 0. I,
   0. + 0. I, 0.}, {0, -4.32468*10^-200 + 0. I, 0. + 0. I, 0.}, {0, 
  5.23465*10^-200 + 0. I, 0. + 0. I, 0.}, {0, 4.32468*10^-200 + 0. I, 
  0. + 0. I, 0.}}

  • But for generated lists they do not, values with small negative Re to to Pi even when multiplied with exact 0 and the actual value that goes into Arg is 0.0+0.0 I the outcome is always Pi. First output is 13.3 second output is 13.2. They are different

    In[364]:= (*define values*)
i = 50; n = 200.;

(*generated list of number  - everything with negative Re evaluates \
to Pi*)
msk = ConstantArray[0, i];
comp = RandomComplex[{-10.^-n, 10.^-n}, i];
val = msk comp;
arg = Arg[val];
Thread[{msk, comp, val, arg}]

(* proof dat all negative numbers in array evaluate to *)
a = UnitStep[-Sign[Re[comp]]]
b = Sign[Re[val]]
c = Unitize[arg]
a == c


Out[369]= {{0, -3.59355*10^-201 + 0. I, 0. + 0. I, 
  3.14159}, {0, -8.71485*10^-201 + 0. I, 0. + 0. I, 3.14159}, {0, 
  4.51555*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 4.56213*10^-201 + 0. I, 
  0. + 0. I, 0.}, {0, -1.73914*10^-201 + 0. I, 0. + 0. I, 
  3.14159}, {0, 2.76678*10^-201 + 0. I, 0. + 0. I, 
  0.}, {0, -7.29739*10^-201 + 0. I, 0. + 0. I, 
  3.14159}, {0, -3.88282*10^-202 + 0. I, 0. + 0. I, 
  3.14159}, {0, -2.38636*10^-201 + 0. I, 0. + 0. I, 
  3.14159}, {0, -7.88456*10^-201 + 0. I, 0. + 0. I, 3.14159}, {0, 
  8.5064*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 9.23848*10^-201 + 0. I, 
  0. + 0. I, 0.}, {0, -2.09942*10^-201 + 0. I, 0. + 0. I, 
  3.14159}, {0, 6.05198*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 
  7.35013*10^-201 + 0. I, 0. + 0. I, 0.}, {0, -9.72399*10^-202 + 0. I,
   0. + 0. I, 3.14159}, {0, -2.16232*10^-201 + 0. I, 0. + 0. I, 
  3.14159}, {0, -1.72071*10^-201 + 0. I, 0. + 0. I, 3.14159}, {0, 
  2.56238*10^-201 + 0. I, 0. + 0. I, 0.}, {0, -4.72392*10^-202 + 0. I,
   0. + 0. I, 3.14159}, {0, 1.46317*10^-201 + 0. I, 0. + 0. I, 
  0.}, {0, 5.45542*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 
  6.98144*10^-202 + 0. I, 0. + 0. I, 0.}, {0, 7.52893*10^-201 + 0. I, 
  0. + 0. I, 0.}, {0, 5.63282*10^-202 + 0. I, 0. + 0. I, 0.}, {0, 
  5.83295*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 8.2813*10^-201 + 0. I, 
  0. + 0. I, 0.}, {0, -9.01357*10^-201 + 0. I, 0. + 0. I, 
  3.14159}, {0, -7.20074*10^-201 + 0. I, 0. + 0. I, 
  3.14159}, {0, -6.65122*10^-201 + 0. I, 0. + 0. I, 
  3.14159}, {0, -4.04739*10^-203 + 0. I, 0. + 0. I, 3.14159}, {0, 
  7.55101*10^-201 + 0. I, 0. + 0. I, 0.}, {0, -5.3072*10^-201 + 0. I, 
  0. + 0. I, 3.14159}, {0, 5.01132*10^-201 + 0. I, 0. + 0. I, 0.}, {0,
   2.43361*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 9.98434*10^-201 + 0. I,
   0. + 0. I, 0.}, {0, 5.41462*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 
  2.51404*10^-201 + 0. I, 0. + 0. I, 0.}, {0, -5.79749*10^-201 + 0. I,
   0. + 0. I, 3.14159}, {0, 3.89775*10^-201 + 0. I, 0. + 0. I, 
  0.}, {0, -2.98549*10^-201 + 0. I, 0. + 0. I, 3.14159}, {0, 
  5.02625*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 1.49796*10^-203 + 0. I, 
  0. + 0. I, 0.}, {0, 7.29538*10^-201 + 0. I, 0. + 0. I, 
  0.}, {0, -4.74217*10^-201 + 0. I, 0. + 0. I, 
  3.14159}, {0, -3.63903*10^-201 + 0. I, 0. + 0. I, 
  3.14159}, {0, -9.08686*10^-201 + 0. I, 0. + 0. I, 3.14159}, {0, 
  3.00761*10^-201 + 0. I, 0. + 0. I, 0.}, {0, -6.14527*10^-201 + 0. I,
   0. + 0. I, 3.14159}, {0, 6.85878*10^-201 + 0. I, 0. + 0. I, 0.}}

Out[370]= {1, 1, 0, 0, 1, 0, 1, 1, 1, 1, 0, 0, 1, 0, 0, 1, 1, 1, 0, \
1, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 1, 0, 0, 0, 0, 0, 1, 0, 1, 0, \
0, 0, 1, 1, 1, 0, 1, 0}

Out[371]= {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, 0, 0, 0, 0, 0, 0, 0}

Out[372]= {1, 1, 0, 0, 1, 0, 1, 1, 1, 1, 0, 0, 1, 0, 0, 1, 1, 1, 0, \
1, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 1, 0, 0, 0, 0, 0, 1, 0, 1, 0, \
0, 0, 1, 1, 1, 0, 1, 0}

Out[373]= True

Now look at the output from the same code in Mathematica 13.2

In[1]:= (*define values*)
i = 50; n = 200.;

(*generated list of number  - everything with negative Re evaluates \
to Pi*)
msk = ConstantArray[0, i];
comp = RandomComplex[{-10.^-n, 10.^-n}, i];
val = msk comp;
arg = Arg[val];
Thread[{msk, comp, val, arg}]

(* proof dat all negative numbers in array evaluate to *)
a = UnitStep[-Sign[Re[comp]]]
b = Sign[Re[val]]
c = Unitize[arg]
a == c


Out[6]= {{0, 4.5418*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 
  5.69817*10^-202 + 0. I, 0. + 0. I, 0.}, {0, -8.08554*10^-202 + 0. I,
   0. + 0. I, 0.}, {0, -2.50589*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 
  5.8806*10^-202 + 0. I, 0. + 0. I, 0.}, {0, 2.03054*10^-201 + 0. I, 
  0. + 0. I, 0.}, {0, 2.31057*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 
  7.43712*10^-201 + 0. I, 0. + 0. I, 0.}, {0, -1.32253*10^-201 + 0. I,
   0. + 0. I, 0.}, {0, -4.77195*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 
  4.58221*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 8.59623*10^-201 + 0. I, 
  0. + 0. I, 0.}, {0, 4.82584*10^-201 + 0. I, 0. + 0. I, 
  0.}, {0, -8.78687*10^-201 + 0. I, 0. + 0. I, 
  0.}, {0, -2.65764*10^-202 + 0. I, 0. + 0. I, 0.}, {0, 
  2.20168*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 2.74392*10^-202 + 0. I, 
  0. + 0. I, 0.}, {0, -7.233*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 
  6.18229*10^-201 + 0. I, 0. + 0. I, 0.}, {0, -1.41438*10^-201 + 0. I,
   0. + 0. I, 0.}, {0, 2.30648*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 
  2.99944*10^-201 + 0. I, 0. + 0. I, 0.}, {0, -9.78346*10^-201 + 0. I,
   0. + 0. I, 0.}, {0, 4.17352*10^-201 + 0. I, 0. + 0. I, 
  0.}, {0, -5.85227*10^-201 + 0. I, 0. + 0. I, 
  0.}, {0, -5.58142*10^-201 + 0. I, 0. + 0. I, 
  0.}, {0, -3.90072*10^-201 + 0. I, 0. + 0. I, 
  0.}, {0, -2.97276*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 
  7.29687*10^-201 + 0. I, 0. + 0. I, 0.}, {0, -1.34306*10^-201 + 0. I,
   0. + 0. I, 0.}, {0, 5.24692*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 
  8.0529*10^-201 + 0. I, 0. + 0. I, 0.}, {0, -2.38566*10^-201 + 0. I, 
  0. + 0. I, 0.}, {0, 6.40825*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 
  6.80501*10^-201 + 0. I, 0. + 0. I, 0.}, {0, -3.68792*10^-201 + 0. I,
   0. + 0. I, 0.}, {0, 3.56694*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 
  7.03833*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 8.75828*10^-201 + 0. I, 
  0. + 0. I, 0.}, {0, -8.0177*10^-201 + 0. I, 0. + 0. I, 
  0.}, {0, -4.44713*10^-201 + 0. I, 0. + 0. I, 
  0.}, {0, -3.30227*10^-201 + 0. I, 0. + 0. I, 
  0.}, {0, -9.00441*10^-201 + 0. I, 0. + 0. I, 
  0.}, {0, -1.33593*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 
  5.87783*10^-201 + 0. I, 0. + 0. I, 0.}, {0, -9.87446*10^-202 + 0. I,
   0. + 0. I, 0.}, {0, -9.15533*10^-201 + 0. I, 0. + 0. I, 0.}, {0, 
  5.32573*10^-201 + 0. I, 0. + 0. I, 0.}, {0, -6.20455*10^-201 + 0. I,
   0. + 0. I, 0.}, {0, 6.24134*10^-201 + 0. I, 0. + 0. I, 0.}}

Out[7]= {0, 0, 1, 1, 0, 0, 0, 0, 1, 1, 0, 0, 0, 1, 1, 0, 0, 1, 0, 1, \
0, 0, 1, 0, 1, 1, 1, 1, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 0, 1, 1, 1, 1, \
1, 0, 1, 1, 0, 1, 0}

Out[8]= {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, 0, 0, 0, 0, 0, 0}

Out[9]= {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, 0, 0, 0, 0, 0, 0}

Out[10]= False

In my opinion the behavior of 13.2 is the correct and expected one and the output of 13.3 is unexpected.
POSTED BY: Martijn Froeling
ZAQU zaqu
ZAQU zaqu
Posted 2 years ago

The C99 complex.h requires a separate implementation, that is in glibc and Intel libm, even less accurate than real numbers math.h glibc and Microsoft math library. Mathematica did not bother, it just uses naive implementation for complex multiplication. In practice the code using glibc is less accurate than from Windows:

https://community.wolfram.com/groups/-/m/t/2851685
POSTED BY: ZAQU zaqu
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Tag limit exceeded
Note: Only the first five people you tag will receive an email notification; the other tagged names will appear as links to their profiles.
Reply Preview
Attachments
Remove
or Discard