<p dir="auto"><em>Original ticket <a href="http://projects.scipy.org/numpy/ticket/1163" rel="nofollow">http://projects.scipy.org/numpy/ticket/1163</a> on 2009-07-09 by trac user onsi, assigned to unknown.</em></p>
<p dir="auto">I'm running version 1.2.1 but this error should also occur in 1.3.0 based on the source currently in the trunk.</p>
<p dir="auto">I try importing the following ascii data stored in "sample.csv":</p>
<p dir="auto">9007200000000000,670927001710,0.010190886[[BR]]<br>
9007200000000001,660927001348,0.00976051[[BR]]<br>
9007200000000002,650883003926,0.009154096</p>
<p dir="auto">using (maximal verbosity for clarity):</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="import numpy
arr=numpy.loadtxt(&quot;sample.csv&quot;,dtype=[('id0',numpy.int64),('id1',numpy.int64),('flt',numpy.float32)],delimiter=',',comments='#')"><pre class="notranslate"><code class="notranslate">import numpy
arr=numpy.loadtxt("sample.csv",dtype=[('id0',numpy.int64),('id1',numpy.int64),('flt',numpy.float32)],delimiter=',',comments='#')
</code></pre></div>
<p dir="auto">I get:</p>
<p dir="auto">[(9007200000000000L, 670927001710L, 0.010190886445343494)[[BR]](<strong>9007200000000000L</strong>, 660927001348L, 0.0097605101764202118)[[BR]](9007200000000002L, 650883003926L, 0.009154096245765686)][[BR]]</p>
<p dir="auto">After some digging, i found the culprit to be the converter used by loadtxt to convert strings to dtypes.  lib.io._getconv (line 352 in trunk) returns:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="lambda x: int(float(x))"><pre class="notranslate"><code class="notranslate">lambda x: int(float(x))
</code></pre></div>
<p dir="auto">as the converter for any dtype that is a subclass of int, which int64 is.  Unfortunately, float does not faithfully reproduce long integers and so 9007200000000001 gets rounded to 9007200000000000.</p>
<p dir="auto">This is fairly serious as int64s are often used as IDs in various numerical/simulation contexts.  Changing the converter to int() should resolve this problem -- though then some error checking needs to take place to ensure that int is fed an integer string.</p>
<p dir="auto"><em>Original ticket <a href="http://projects.scipy.org/numpy/ticket/1565" rel="nofollow">http://projects.scipy.org/numpy/ticket/1565</a> on 2010-07-28 by <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/fengy-research/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/fengy-research">@fengy-research</a>, assigned to unknown.</em></p>
<p dir="auto">Prepare the following file:</p>
<p dir="auto">-------file /tmp/test -----<br>
9223372043271415339<br>
9223372043271415853<br>
9223372043271415612<br>
9223372043271416107<br>
9223372043271415594<br>
9223372043271415836<br>
9223372043761290139<br>
9223372044088967272<br>
9223372044088967273<br>
9223372043925949039<br>
---------end of file-----</p>
<p dir="auto">And run the following code:</p>
<p dir="auto">In [16]: print loadtxt('/tmp/test', dtype='uint64')<br>
-------&gt; print(loadtxt('/tmp/test', dtype='uint64'))<br>
[9223372043271415808 9223372043271415808 9223372043271415808<br>
9223372043271415808 9223372043271415808 9223372043271415808<br>
9223372043761289216 9223372044088967168 9223372044088967168<br>
9223372043925948416]</p>
<p dir="auto">On the other hand, with fromfile(),</p>
<p dir="auto">In [2]: print fromfile('/tmp/test', dtype='uint64', sep=' ')<br>
------&gt; print(fromfile('/tmp/test', dtype='uint64', sep=' '))<br>
[9223372043271415339 9223372043271415853 9223372043271415612<br>
9223372043271416107 9223372043271415594 9223372043271415836<br>
9223372043761290139 9223372044088967272 9223372044088967273<br>
9223372043925949039]</p>
<p dir="auto">Clearly the first few numbers are wrongly converted by loadtxt</p>
<p dir="auto">The problem was tracked to line 453 in numpy/lib/io.py, _getconv. The conversion for np.integer is int(float(x)), which is inexact for large integers.</p>
<p dir="auto">I don't know if a priority of normal is appropriate, as this bug will produce hidden errors in programs that use numpy.</p>