['python has complex numbers???', '\nefficiency of calculations with complex numbers in python&\njust as a warning, graphs suck on mobile here. if you can pinch to zoom then that\'s a very good idea\n (**intro**) \ni don\'t know much of complex numbers. i know they\'re written in the form a+bi where a represents the "real" part and b is the coefficient of the root of -1 (also called i). i was recently working on a program involving polynomials, and some error somewhere led to it giving a result as \'\'\' (5.7+13.2j) \'\'\' which was confusing to say the least. it was pretty obvious that this was an attempt at a complex number, using j instead of i, something i\'d never encountered before. \\n "In contexts in which use of the letter i is ambiguous or problematic, the letter j is sometimes used instead. For example, in electrical engineering and control systems engineering, the imaginary unit is normally denoted by j instead of i, because i is commonly used to denote electric current." - wikipedia (;) \n (**so_what?**) \ni immediately wanted to do something with this newfound datatype (not often you accidentally find one of them) so i thought it might be good to see how they fare in terms of efficiency. i started out with something very simple, i took a few complex and real numbers and doubled them a million times or so and graphed the results. i suspected that the complex numbers would take much longer overall\n
\nwtf (;) \nfor some reason the non-zero real numbers took exponentially longer to calculate (20 seconds??) i couldnt really figure it out but i did realise that i was using the *= operator instead of just *, so the value of x would get exponentially bigger (why that changed the time and like didnt affect the complex numbers is beyond me), which would explain why x=0 followed the same path as the complex x\'s.\n \\n if you zoom in at the start you can see that they follow the same path as the complex numbers initially but very quickly diverge (after maybe 15000 tests). also worth noting that the two non-zero real numbers follow the exact same path for a bit\n \ni would just like to mention now that you shouldnt really look at the heights that the lines reach, but the gradient, as that is a more accurate way of comparing them.\n(;) \n (**other_operations**) \nthe logical next step for this was to check other operations, so i tried with -=, /=, rooting and raising it to itself. nothing gave the same result: \n (**multiplication**) \n \n (**power_of_itself**) \n \n(**all_of_em**) \n \n(note that this doesnt have /= but it was still linear and about in line with the other results) \\n \nthere\'s a bit of a rush from some of them so i ran it again to see if it was just error and eh theres a bit of correlation to look at \\n \n \nnot much to look at really (;) \n (**conclusion**) \ni have left this with more questions than answers which sucks \\n \nthanks for reading yeah']