For some reason, log(2;16^3)
evaluates to 12+9.12440459647775110183e41j
. This, of course, is not true; the real (pun not intended) answer is 12. I checked log(2;16^2)
and log(2;16^4)
which give the expected answers of 8
and 16
respectively. I also checked 2^(12+9.12440459647775110183e41j)
which correctly evaluates to 4096+2.59053785920993634877e37j
and 2^12
evaluates to 4096
.
I am running v0.12 on windows.
Comments (7)

repo owner 
The error already occurs for the natural logarithm (
ln
), on whichlog
is based.This is the relevant code from cmath.cpp
CNumber CMath::ln(const CNumber& x) { HNumber abs = CMath::abs(x).real; CNumber result; result.real = HMath::ln(abs); // Principal Value logarithm // https://en.wikipedia.org/wiki/Complex_logarithm#Definition_of_principal_value auto imag = HMath::arccos(x.real / abs); result.imag = (x.imag.isPositive()  x.imag.isZero()) ? imag : imag; return result; }
The truncation error happens either in the absolute value (here mathematically a noop, but will actually square and then take the square root again) and the arccos, or both.
Some options to improve things here:
 Check if x is real, and use a simplified logic in that case.
 Use
auto imag = HMath::arctan(x.imag / x.real);
instead. Mathematically identical, but stays clear ofarccos
' singularity close to 1. This will require also treating separately the case ofx.real==0
, but not where it is only close.
These options are not mutually exclusive. Personally, I'd rather have rocksolid behaviour in case of real arguments, so I suggest to implement option 1 regardless of option 2.
Unfortunately I no longer have a tool chain setup for SpeedCrunch.

I will try to have a look on it, just for the fun.

repo owner  assigned issue to

Pull request made.

repo owner  changed milestone to 1.0

repo owner  changed status to resolved
 Log in to comment
@Hadrien Theveneau @Pol Welter I believe you guys are in a better position to clarify this one (why the precision error when complex numbers are enabled).