0

Something ridiculous happened while handling complex numbers.

> complex(1,2)/complex(1,2)  
(1+0j)

This one was nice, but...

>complex(15,22)/complex(15,22)   
(1-5.51196762578357e-17j)

(WHAT?)

> a=complex(15,22)/complex(15,22)  
> a.imag  
-5.51196762578357e-17  
> int(a.imag)==a.imag  
False

Surely the imaginary part is not zero... Please try it on your own and witness this ironic situation.

One more example.

> print c  
(74+33j)   
> c/(1+10j)   
(4-7.000000000000001j)

Of course, that -7.0000000000000000001 should have been -7.

Riduidel
  • 22,052
  • 14
  • 85
  • 185
Joongyu Oh
  • 9
  • 3
  • Just a rounding error... https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html (it's actually kind of expected that it works with 1 and 2 because they are both powers of 2, while 15 and 22 aren't.) – CherryDT May 23 '16 at 11:04
  • Plz tell me much much easier.. I'm not a skilled programmer(and not able to read the whole document you posted cause I'm not good at reading English) I need more childlike advices... – Joongyu Oh May 23 '16 at 11:21
  • 1
    Check out [this question](http://stackoverflow.com/questions/588004/is-floating-point-math-broken), there are tons of answers between child-like and deep technical. In short: Computers only have so-much precision when calculating, so there will always be rounding errors. The rounding errors will look weird in decimal notation because computers do the math in binary. For example, if a human rounds 1/3 then it will be something like 0.333..., and (1/3)*3 with this 3-digit precision would give 0.999 instead of 1. The same thing happens here, but just with different number bases. – CherryDT May 23 '16 at 11:25

0 Answers0