If he’s adding 2π then he must be handling the complex number in polar format, where adding 2π to the angle will change it from a negative to positive value without changing the actual value of the complex number.
Someone was, then someone commented that part out as you can see. So it’s not anymore…
The problem in the end was that the temp variable was used twice. (Which normally should be fine) But, the internal datatype class he has for the BigComplex does not survive re-using of any kind.
(This has been fixed now by using 2 temp variables instead of re-using it which fixed fpPow and fpGamma). (The update can be found in my release thread)
You know, when I saw this I thought “I hope Robert is copying the source to a temp value inside of mul()” because if it does multiple operations in source AND the destination WHEN source IS the destination It will mess the source DURING such operations.
Such kind of thing may be occurring in more parts of the routines.
Yes I have put it on my list of things to check for when continuing refactoring the plugin.
The plugin still also has hundreds of leaks and memory clobbering that need to be tackled. (Its slow process to fix). Luckily most of it is around Exceptions or when feeding Nil inputs into something. So should not be huge issue if peoples code is good.
But in the todays version, Robert validated all the special operations for the BigComplex, as in did actual tests against known correct results. So thats something