[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #50743] dlmread producing incorrect results fo
From: |
Ben Lapid |
Subject: |
[Octave-bug-tracker] [bug #50743] dlmread producing incorrect results for large (64bit) integers |
Date: |
Thu, 6 Apr 2017 18:02:09 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 |
URL:
<http://savannah.gnu.org/bugs/?50743>
Summary: dlmread producing incorrect results for large
(64bit) integers
Project: GNU Octave
Submitted by: blap
Submitted on: Thu 06 Apr 2017 10:02:08 PM UTC
Category: Octave Function
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: Inaccurate Result
Status: None
Assigned to: None
Originator Name:
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release: 4.0.0
Operating System: GNU/Linux
_______________________________________________________
Details:
Steps to reproduce:
1. (shell) echo 5973459727478852968 > /tmp/1.csv
2. (octave) x = dlmread('/tmp/1.csv', ',', 0, 0)
3. (octave) uint64(x)
>> ans = 5973459727478852608
This issue comes from the fact that dlmread reads doubles
(libinterp/corefcn/dlmread.cc) from the text file.
While I understand this behavior in 99% of the cases, and I agree it should be
defaulted this way, I do think there should be a way to direct dlmread to a
different parse method. See for example scipy's 'genfromtxt' 'dtype' argument.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?50743>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [Octave-bug-tracker] [bug #50743] dlmread producing incorrect results for large (64bit) integers,
Ben Lapid <=