Sergey B Kirpichev

Now garbage examples return nans, but the rest is same.

> The 0 > 0 is because the error message uses "%g". That's the only place in the code that uses that. Is there a better alternative? @asmeurer, this seems...

> It appears to be a roughly linear relationship (bisection should converge exponentially, so this makes sense). 1. There a other solvers. 2. bisection shouldn't converge exponentially, ~~rather the newton...

> Not sure why you think that. I was thinking of https://en.wikipedia.org/wiki/Rate_of_convergence > maxsteps=1.7*dps seems to do the trick (maybe it can be a bit tighter; I'm guessing the theoretical...

@fredrik-johansson, I'm not sure why this issue was closed. Could you please explain why? Do you think there is support for signed zero? I don't think it's even can be...

> there is potential benefit in mpmath being more compatible with IEEE 754 And within different contexts (fp vs mp). > You can't really use signed zeros for branch cuts...

> This is not a bug. That depends... Most people, probably, recognize ``-2-0j`` as a rectangular notation (i.e. as an equivalent of ``complex(-2, -0.0)``), while in the Python this actually...

> This is the reason we have (1±0j) * 1 = (1+0j) No. The reason is that ``1-0j=complex(1,0)-complex(0,0)=1+0j``. To get ``complex(1, -0.0)`` with imaginary literals you should use cumbersome syntax...

Here is a draft pr: #768

Diofant tests on the above patch: https://github.com/diofant/diofant/pull/1391 (PASS)