IIUC, the OP was surprised by the result of `cumsum(a)` (without the 'native' argument).

This is still the same as it was when it was reported.

It is still different from Matlab's `cumsum` which always returns in native type. But it's more consistent with how `sum` in Octave and in Matlab behaves.

I guess we could leave it as it is if we agree that this is the "better" behavior.

As it is, one could write `cumsum(double(a))` or `cast(cumsum(a), class(a))` to get the same result in Octave and in Matlab. The latter might not work correctly for 64 bit integers in Octave.

If we feel strongly about compatibility, we could change the default in `cumsum` to 'native' instead of 'double'. (Causing an inconsistency between the defaults of `sum` and `cumsum`.)

I slightly tend towards leaving it as it is. But I don't have strong feelings about that.

Re-categorizing as compatibility difference.

The issue indeed seems to be with cumsum: by default, Octave performs the operation as double while Matlab uses the same class as the input and does not provide a mechanism to change this behavior:

>> a = uint8([150 150]);
>> sum(a)

ans =

   300

>> sum(a,'native')

ans =

  uint8

   255

>> cumsum(a)

ans =

  1×2 uint8 row vector

   150   255

>> cumsum(a,'native')
Error using cumsum
Invalid option. Option must be 'forward', 'reverse', 'omitnan' or 'includenan'.

I execute the following code:

a = uint8([150 150]);

% Calulate sum
s1 = sum(a);
s2 = a(1) + a(2);

% Calculate cumulative sum
cs1 = cumsum(a);
cs2(1) = a(1);
cs2(2) = a(1) + a(2);

and I get the following output:

s1 =  300
s2 = 255
cs1 =

   150   300

cs2 =

  150  255

I expected s1 to be equivalent to s2, and cs1 to be equivalent to cs2.