<p dir="auto">Currently (at least on 0.3.11, have checked master docs but not implementation), abs does not behave in a mathematically correct manner: abs(typemin(Int)) == typemin(Int) on my Linux x86-64 machine.</p>
<p dir="auto">This problem plagues the C standard library abs(), llabs(), etc as well due to subtle asymmetry in 2's complement arithmetic. The C standard leaves behavior on INT_MIN, etc undefined, and this is fortunately documented, though easily missed by many programs.</p>
<p dir="auto">I thus see 2 possible approaches:</p>
<ol dir="auto">
<li>Follow the C standard behavior, give no guarantee for abs(typemin), and document it.</li>
<li>Do something special with typemin, and document it.</li>
</ol>
<p dir="auto">I saw the discussion in <a href="https://groups.google.com/forum/#!topic/julia-users/46i-NNUxpa8" rel="nofollow">https://groups.google.com/forum/#!topic/julia-users/46i-NNUxpa8</a>, and did not find an issue on github discussing this.</p>
<p dir="auto">Most users will probably expect <code class="notranslate">abs(x)&gt;=0</code> and failing this assumption will probably create bugs that will be really hard to find (especially for the typical Julia user).</p>
<p dir="auto"><a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/StefanKarpinski/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/StefanKarpinski">@StefanKarpinski</a> suggested to throw an error for these numbers, and that seems like a good option. The problem is that performance will suffer so much that some users might want access to the simple inlinable <code class="notranslate">abs</code> function so that we have to  add a <code class="notranslate">abs_raw</code>.</p>