Does it have to inherit from a handle object? about mappedtensor HOT 6 CLOSED

Hi @marcsous, the primary use case for MappedTensor is to access existing binary files, and map them to matlab objects. So the handle semantics are inherent to pointing to the same file on disk, in that case. I agree it's slightly less obvious when creating temporary files to store the tensors, but the same semantics hold — if I copy an object, the copy is pointing to the same data on disk as the original object, whether MappedTensor is a handle class or not.

from mappedtensor.

Just to clarify, as far as the MappedTensor is concerned, after you copy it it still points to the same file. The string strRealFilename is identical in the original and the copy - i.e. the string is copied not the file itself. I think this is desired behavior.

If you edit the disp function to show the filename, you can verify this:

      %% disp - METHOD Overloaded disp function
      function disp(mtVar)

          ...
         
         % show fhe filename
        disp(mtVar.strRealFilename)

      end

I get the following:

>> a=MappedTensor(1,'Convert');
>> b=2*a;
>> disp(a)
  MappedTensor object, containing: double [1 1].
  Methods

/tmp/tp92b01e3b_1723_408d_b91a_dfd5f517bc8e

>> disp(b)
  MappedTensor object, containing: double [1 1].
  Methods

/tmp/tp92b01e3b_1723_408d_b91a_dfd5f517bc8e

>> a(1)

ans =

     1

>> b(1)

ans =

     2

from mappedtensor.

Yes, that's what I mean. Even if matlab were to consider the two objects to be different, they would still contain the same data, since they would point to the same file. It makes sense to explicitly declare MappedTensor as a handle class to reflect the underlying operation of the object.

from mappedtensor.

If you rewrote MappedTensor to make an explicit copy of the data file and point to the copy, then it would make sense for it to not be a handle class.

from mappedtensor.

I think the mental block I'm having ;) is that handle class shares all the fields, not just the data field. The cast and scalar multiply functions are risky in this case, as per the example above.

a = MappedTensor(1,'Convert');
b = 2*a;

Here, the variable 'a' silently disappear and points to 'b' instead. So if you have a function that accepts a tensor and modifies it internally then you will lose your original tensor.

a = MappedTensor(1,'Convert');
f = @(x) 2*x;
b = f(a);
a(1)
ans =
     2

I guess it's not what one normally expects from a numerical object (in Matlab at least)!

from mappedtensor.

The thing is, MappedTensor is designed for file-backed lazy data access. At the moment, if you copy a MappedTensor object then the two objects use the same file for data storage, and so contain the same data. Even if they weren't explicitly handle objects, they would still share the same data. But because they weren't handle objects, a user might mistakenly think they were independent, and then be surprised when the data in an object magically changes.

The only solution would be for MappedTensor to explicitly copy the underlying data file every time the object was copied, but since the primary goal was for lazy data access of large data sets, this wouldn't be desirable.

from mappedtensor.