bugGNU Octave - Bugs: bug #53293, uint64 are truncated

 
 

bug #53293: uint64 are truncated

Submitter:  jpap <jpap>
Submitted:  Tue 06 Mar 2018 07:32:53 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Duplicate Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.2.1 Operating System:  * Mac OS
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 06 Mar 2018 01:57:13 PM UTC, comment #4: 

I think this is a duplicate of bug #45945 (Missing Matlab's special support for int64/uint64 integer literals).

Octave's int64 variables are stored as 64-bit integers, not doubles. The problem is with parsing large integer constants and converting them all to double.

There are a couple of other related reports about 64-bit integers not handled in other contexts:

bug #50743: textscan produces incorrect results for large (64bit) integers

bug #51888: scanf / fscanf / sscanf should be able to return int64 / unit64 values


John W. Eaton <jwe>
Group administrator
Tue 06 Mar 2018 01:36:30 PM UTC, comment #3: 

The NEWS file for Octave 4.4 contains the text



 ** hex2num and num2hex now work for integer and char types and num2hex
    may optionally return a cell array of strings instead of a character
    array.  If given a cell array of strings, hex2num now returns a
    numeric array of the same size as the input cell array.  Previously,
    hex2num would accept a cell array of strings of arbitrary dimension
    but would always return a column vector.


So this is already implemented. Till then you can use something like


uint64(0xFFFFFFFF) * 2^32 + uint64(0xFFFFFFFF)


to get large uint64 vales

D.

David Bateman <dbateman>
Group Member
Tue 06 Mar 2018 11:21:17 AM UTC, comment #2: 

By the way, I see the file NEWS in the dev branch says that
"hex2num and num2hex now work for integer and char types".

So, I guess maybe in the future version we might use
hex2num('63c7a906c1dd187b', 'uint64')
to input a large uint64 number accurately without truncating ?

Anonymous
Tue 06 Mar 2018 11:02:53 AM UTC, comment #1: 

I got the same results in Debian GNU/Linux amd64.

But I think this is NOT a bug.

Because in Octave a numeric constant literal, such as 7189901176607676539, 18446744073709551615, 0xffffffffffffffff, is type of double.
(See also the help text of function "isinteger")
But IEEE754 double only has about 52-bit significant digit. As a result, the lower bits of a large number is actually "truncated by double", not truncated by uint64.
(See also the help text of function "flintmax")

Anonymous
Tue 06 Mar 2018 07:32:53 AM UTC, original submission:  

It looks like Octave is truncating the lower 8-bits of a large uint64 number.  As a result I can't do any simple int64 mathematical operations reliably, nor can I even define an accurate uint64 constant using the `uint64(...)` syntax.


octave:1> uint64(7189901176607676539) - uint64(7189901176607676416)
ans = 0
octave:2> intmax('uint64')
ans = 18446744073709551615
octave:3> uint64(18446744073709551615) - uint64(18446744073709551600)
ans = 0
octave:4> format hex
octave:5> uint64(18446744073709551615)
ans = ffffffffffffffff
octave:6> uint64(18446744073709551600)
ans = ffffffffffffffff
octave:7> uint64(0x63c7a906c1dd187b)
ans = 63c7a9 6c1dd18 0
octave:8> uint64(0x63c7a906c1dd1800)
ans = 63c7a9 6c1dd18 0
octave:9> uint64(0x63c7a906c1dd1000)
ans = 63c7a9 6c1dd10 0


jpap <jpap>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by dbateman (Posted a comment)
  • -email is unavailable- added by jpap (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-06 jwe StatusNone Duplicate
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code