Your mathematicaDefinitionOfArcCoth has a branch cut discontinuity in the complex plane, and -1/2 lies precisely along the cut. You can expect the numerical algorithms to give inconsistent results. It woud be nice of Mathematica to issue a warning in such cases, though.
You can expect the numerical algorithms to give inconsistent results.
Mathematica gives the same false result even if you omit the “N”; the issue here is not a matter of any numerical algorithm.
The issue is rather a lack of coordination and communication between the developer who implemented ArcCoth and the person who authored the “Background & Context” section in the docs. As far as I have found, a fix would require no change to the implementation of ArcCoth; a fix would require only a correction to the documentation. I foresee no fix ever happening, though, because the consensus among the community is that wrong is better when wrong is what Mr. Wolfram chooses.
Thank you. If “Back & Context” said what you said, there would be no issue. Instead, “Back & Context” shows a different expression, one unequal to ArcCoth. Along the discontinuity, the discrepancy makes all the difference in the world.
I wasn’t sure what you were trying to do. I couldn’t find your definition for mathematicaDefinitionOfArcCoth at the link you posted. The definition that I used was under Properties and Relations:
TrigToExp[ArcCoth[z]]
Out = -(1/2) Log[1-1/z]+1/2 Log[1+1/z]
But, something appears to be wrong with ArcCoth[-1/2] when N is applied or when using inexact arguments. It stays unevaluated with exact arguments outside of the domain.You should submit a bug report.