As
http://projects.scipy.org/numpy/ticket/2179
stated: "Ideally one should be returning other ndarray objects, e.g. numpy scalars in the case of sum(), but this requires a larger rewrite. At least numpy version 1.5.1rc1 did this. The only time the _mmap should be kept (as I am aware of) is when slicing. "
This issue remains not fixed thus opening a separate issue for the above. Taking into account that np.asscalar() called on scalars
(e.g. which would be returned by np.sum on ndarrays) crashes, it becomes impossible to write code agnostic of ndarray/memmap container types.
it is also not clear why array-wide operations on mode='c' memmap'ed arrays which cannot really get reflected in the file storage, remain memmapped and do not result in normal ndarrays, but I guess that would be a separate issue...
Original ticket http://projects.scipy.org/numpy/ticket/2215 on 2012-09-14 by atmention:yarikoptic, assigned to unknown.
As http://projects.scipy.org/numpy/ticket/2179 stated: "Ideally one should be returning other ndarray objects, e.g. numpy scalars in the case of sum(), but this requires a larger rewrite. At least numpy version 1.5.1rc1 did this. The only time the _mmap should be kept (as I am aware of) is when slicing. "
This issue remains not fixed thus opening a separate issue for the above. Taking into account that np.asscalar() called on scalars (e.g. which would be returned by np.sum on ndarrays) crashes, it becomes impossible to write code agnostic of ndarray/memmap container types.
it is also not clear why array-wide operations on mode='c' memmap'ed arrays which cannot really get reflected in the file storage, remain memmapped and do not result in normal ndarrays, but I guess that would be a separate issue...