[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #50238] sum, cumsum, etc. mishandle integer in
From: |
Markus Mützel |
Subject: |
[Octave-bug-tracker] [bug #50238] sum, cumsum, etc. mishandle integer inputs |
Date: |
Tue, 3 Aug 2021 07:31:27 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36 Edg/92.0.902.62 |
Update of bug #50238 (project octave):
Item Group: Incorrect Result => Matlab Compatibility
Release: 4.2.0 => dev
_______________________________________________________
Follow-up Comment #4:
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.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?50238>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/