Open jerry73204 opened 3 years ago
I don't think that Copy
can be implemented for Tensor
because Copy
is for "types whose values can be duplicated simply by copying bits". If you did that with Tensor
you'd end up with both pointing to the same object on the C++ side which would result an extra refcount subraction when the two tch Tensors go out of scope.
@edlanglois I agree with your points. The cloning/coping of Tensor
is correct only when the refcount is increased implicitly, if it is a shallow copy.
Another concern is that whether .clone()
is shallow or deep affects the semantics of ownership. Currently, the self-modifying methods like .absolute_(&mut self)
expects unique ownership. The shallow copy shares the underling data, making the ownership unsound. If libtorch knows concurrent self-modifying operations, just like many other concurrent data structures like dashmap
, it should expect shared ownership.
EDIT: Let's move the discussion to #370.
More thoughts about this thread.
cv-convert
to support third-party type conversions from/to tensors. The issue is somewhat fixed.From<Vec<Vec<T>>>
. The nested vec conversion should be deprecated to fit From
definition. We can provide an fallible constructor from_nested_vec()
as a replacement.
It is due to my closed #198. It is outdated for a while and I think it should be discarded too. Nevertheless, let me leave some concerns about type conversions in current implementation. Some changes would be made as soon as some concerns become clear.
Implicit floating point truncation It is able to divide a
Float
kind tensor with af64
number. It involves implicit f64 to f32 truncation. We might restrict the divisor to bef32
, but it sacrifices the convenience by writingtensor / 2f32
everywhere. I consider a balanced approach is that we allow implicit conversions for+-*/
, and provide explicit method calls that restricts scalar types.Deprecate
From<Vec<Vec<T>>> for Tensor
The std doc saysFrom
must not fail. Also, it is discouraged to build vec of vec to store higher dimensional data because it is prone to error and is less efficient, though this feature is convenient for hacking. We could follow ndarray'sfrom_shape_vec()
or provide a falliblefrom_guessed_vecs()
that make shape guessing explicit.Convenient
Tensor
constructors I wish to havefrom_shape_fn
andfrom_shape_iter
like ndarray. It really saves my time.Third-party type conversion I wish it works with well-known crates without much effort. It's nice we already have
ndarray
. It's better it supportsnalgebra
andimage
. I see introducing them would cause bloating. It could be solved by cargo feature gating or introduce an extra crate for type conversion.Let
Tensor
to beCopy
(and of courseClone
) I see it is a controversial decision. Let me argue that it is valid thatTensor
can beCopy
. My retrospection onClone
andCopy
is that it affects.clone()
is explicit or not. Costly copy should have explicit.clone()
, whileCopy
is suitable for primitive or cheap reference types. IMO, libtorch'sTensor
is a reference to shaped data on device (so we have.shallow_clone()
). We could follow PyTorch's approach to have implicit shallow copy and explicit deep.copy()
method. By havingCopy
onTensor
, we gain some conveniences. We can keepAdd<Tensor> for Tensor
and removeAdd<&Tensor> for Tensor
without bothering the borrow checker. It's also less cumbersome to deriveClone
on struct ofTensor
s.