I thought the changes were made before we started the version 6 release series, but they were not made until after that so are not on the stable branch.  I pushed the new change to default here:

http://hg.savannah.gnu.org/hgweb/octave/rev/38c47f8f7cd6

The attached change appears to fix the problem for me.

I think unary minus only worked correctly after the initial changeset (ee9b1081471f) and the one that fixed the problem described in comments #26-28 (5b1143d1d74b).

Maybe this change should go on stable?


(file #51665)

Can this issue be closed?  Seems like large integer literals are now supported at least as well as Matlab.

All debian buildbots seems to be failing.
Is hdf5 too old over there? On fedora it is 1.10.5 

Dmitri.
--

In Matlab R2020a, I get this:

>> y = int64([int64(9223372036854775803); 9223372036854775804; 9223372036854775805; 9223372036854775806; 9223372036854775807])

y =

  5×1 int64 column vector

   9223372036854775803
   9223372036854775807
   9223372036854775807
   9223372036854775807
   9223372036854775807

Good, thanks for the confirmation. So re comment #21, maybe we need a new token type to handle things that look like integers, store the integer value and special status, but convert the value back to a double if the value is used in any context other than being passed as a scalar to the actual int64 or uint64 functions, called directly as "int64" or "uint64".

@mtmiller comment #16:

The case of array of literals:

>> y = int64([9223372036854775803; 9223372036854775804; 9223372036854775805; 9223372036854775806; 9223372036854775807])
y =
  9223372036854775807
  9223372036854775807
  9223372036854775807
  9223372036854775807
  9223372036854775807
>> class(y)
ans =
int64

same thing with the colon operator:

>> int64(9223372036854775803:9223372036854775807)
ans =
  9223372036854775807
>> class(ans)
ans =
int64

The above results are consistent with before, only when u?int64 is called with a scalar literal number then it is treated as a special case, everything else is first interpreted as double-type for the intermediate value before getting cast to the target class in the final result.

Another example is when combining elements of unlike classes:

>> [int64(9223372036854775803) 9223372036854775803]
ans =
  9223372036854775803  9223372036854775807
>> class(ans)
ans =
int64

So concatenating integers with numeric types always yields integers.
And when combining different integer types, all elements of the resulting matrix are given the data type of the left-most integer (MATLAB evaluates each element prior to concatenating them into a combined array).
These cases are documented here:
http://www.mathworks.com/help/matlab/matlab_prog/valid-combinations-of-unlike-classes.html
http://www.mathworks.com/help/matlab/matlab_prog/combining-unlike-integer-types.html

Yeah, I don't think this is handled by special casing "int64" in the lexer.  That would cause other trouble anyway because functions may be overloaded, as you show.

I'm pretty sure the way to handle it is to store the int64 value and use it in certain contexts.  Weirdly, that apparently only applies to scalar contexts.

This seems similar to the way that "x(idx) = []" deletes elements from X, but "null = []; x(idx) = null" does not.  In Octave, we give "[]" special status until an assignment happens.  We could do something similar for integer literals.

unconventional question:

>> uint64(18446744073709551614)

ans = 18446744073709551614

>> uint64(18446744073709551614 * 1)

ans = 18446744073709551615

seems a case for a bug report to mathworks.
Or has this a serious background???

@Mike,
could you explain me why we need considering a token within the int64 function??
What if we have int64(a very complicated expression)?
This treated in the parser????

Rik and jwe: re your earlier comments about avoiding treating the function name as a special token, and just looking at the number of digits in the number, notice what is shown in comment #1. To be Matlab compatible, the number should be treated as a int64/uint64 constant if and only if it is appears as the only token within the int64/uint64 function.

Still I'd be curious for some more Matlab testing. WDMD:

@foo/foo.m:

classdef foo < handle
end

@foo/int64.m:

function z = int64(x, y)
  disp(class(x));
  disp(class(y));
  z = y;
end

+mypkg/int64.m:

function z = int64(x)
  disp(class(x));
  z = x;
end

>> x = foo;
>> y = x.int64(9223372036854775806)

>> mypkg.int64(9223372036854775806)
>> import mypkg.int64
>> int64(9223372036854775806)

%% New session

>> int64 = @abs;
>> int64(9223372036854775806)
>> class(ans)
>> int64(-2)
>> class(ans)


>> fcn = @int64;
>> fcn(9223372036854775806)
>> class(ans)
>> fcn(-2)
>> class(ans)

Maybe I do not fully understand the problem but I have the impression that octaves favorite scalar type is double.
Thus for literals no matter whether we have 42 or 42.0,
this is a double although it fits into an int8 and into a single also.
This is appropriate for all numeric types but two:
int64 and uint64, because mantissa length of double is 53,
whereas for uint64 it is 64 and for int64 it is 63.
All other types fit into double.

I would expect that all is ok, if the parser checks
whether the literal fits into a double.
If so it is treated as a double.
Otherwise it is checked whether it fits into an int64.
If so, it is an int64.
Else it is checked whether it fits into an uint64.
If so, it is an uint64.
Else it is an error.
Maybe it is a question how to treat a number which is written as a float whereas it is an integer like 42.0 or what.

Mike:
Thank you for your hints. With your changes, this patch fixes bug #47690 on Windows.

However, I cannot track down where the conversion of the unsigned long integer from the lexer to the double value happens in the code. Do you know where to look for this?

(file #36944)

Sorry. I did not realize that this problem was Windows only and compared 4.0.1 on Windows with my patch on Ubuntu (d'oh). Cross-building right now.

The attached patch adds support for uint64 integers to the lexer. It should handle hexadecimal and binary input correctly without truncating to 32bit max. It does not change anything on the precission issues with high numbers.

Without patch:

>> format hex
>> uint64 (0xffffffffffffffff)
ans =  0 0 0 0ffffffff

With this patch:

>> format hex
>> uint64 (0xffffffffffffffff)
ans = ffffffffffffffff

However, the following still is the case:

>> uint64 (0xfffffffffffffffe)
ans = ffffffffffffffff

The value is still cast to double.

>> class (0xffffffffffffffff)
ans = double

And that should not change (or probably lots of things could break).
Maybe changing "unsigned long" to "uintmax_t" for the hex parser would have done the same job (I did not try).
However, now it would be possible to additionally store the integer value in the octave_value<double> class that could lateron be accessed (exclusively) by builtin integer functions. Thus, we could achieve the same results as Matlab without changing anything on the frontend.
The lexer should be prepared for reading and processing (high) integers with this patch.

How would octal numbers be entered? I did not find a special case for them.

(file #36941)

I'd rather not treat function names in the lexer or parser as special if at all possible because it is possible for them to be overloaded, possibly at run time even when the function is not overloaded when the lexer sees the name.

Given the functions

function y = uint64 (x)
  y = x;
end

function x = f ()
  x = uint64 (18446744073709551614);
end

and the statement

class (f ())

when uint64 is initially not in the load path and again after uint64 is added to the load path?

I agree that hexadecimal or octal integer literals should handle 64-bit values.

I had no idea that integer literals in Matlab were handled in some special way.

Before adding special treatment for int64 and uint64 in the parser, maybe there is something else that can be done?  I'm thinking that special treatment of those symbols in the parser will cause trouble with overloading those functions?  I'm not sure about that, but it's my initial reaction so I would proceed with some caution here.

This really comes down to a weakness in the MATLAB/Octave language syntax; there is no (documented) way to directly specify integer literals. Other languages have suffixes like U, L, and LL for this purpose...

I guess MATLAB solved this issue by having a special case when calling the u?int(8|16|32|64) functions specifically with a literal integer.

% MATLAB
>> format hex
>> intmax('uint64')
ans =
   ffffffffffffffff
>> uint64(18446744073709551614)    # special case in MATLAB
ans =
   fffffffffffffffe
>> uint64(18446744073709551614.0)  # usual interpretation
ans =
   ffffffffffffffff

Octave however isn't doing anything special, and instead first interprets the literal number as double type (as usual), and then casts the temporary value to uint64. There is an entry on the wiki FAQ: http://wiki.octave.org/FAQ#How_do_I_make_Octave_use_more_precision.3F

Now the reason the number comes out as ...615 instead of ...614 is obviously explained by the limitations of IEEE754 double-precision floating-point format. Integers up to 2^53 can be exactly represented as double, above that there is gap of one between every representable integer-valued floating-point. The gap doubles every time we go up by one exponent (2^54, 2^55, etc...). In this case the number you used is one less than intmax('uint64') (2^64-2 to be exact). So according to the default "round-to-nearest" floating-point rounding mode, it ends up getting rounded along with a bunch of nearby numbers all rounded to the same value of ...615 (I think at that range the gaps are 2048 and 4096, half of 2048 rounded up, and half of 4096 rounded down, middle value resolved with a tie-breaker rule).

% MATLAB
>> format hex
>> [18446744073709550591; 18446744073709550592; (18446744073709551614); 18446744073709553664; 18446744073709553665]
ans =
   43efffffffffffff
   43f0000000000000
   43f0000000000000   % your value
   43f0000000000000
   43f0000000000001

As for STR2NUM, it actually uses EVAL to parse the input (both MATLAB and Octave), so it's expected to behave similar to typing the commands on the prompt directly..

The solution in this case is to use a bignum library (like the Symbolic Math Toolbox in MATLAB). I think there are some wrappers for GNU GMP and GNU MPFR libraries for Octave that provide arbitrary precision integer and float numbers.