Skip to content

Remove Tensor constructor of Scalar.#10852

Closed
gchanan wants to merge 3 commits intopytorch:masterfrom
gchanan:scalar_no_tensor
Closed

Remove Tensor constructor of Scalar.#10852
gchanan wants to merge 3 commits intopytorch:masterfrom
gchanan:scalar_no_tensor

Conversation

@gchanan
Copy link
Contributor

@gchanan gchanan commented Aug 24, 2018

This is along the way of removing Tensor as a member of the tagged union in Scalar. This simplifies ordering dependencies, because currently Scalar and Tensor both depend on each other (so we introduce a TensorBase). Also, this API isn't particularly useful publicly: we can't autograd through Scalars, so you still need a Tensor overload basically everywhere anyway.

I'm undecided what the final API should be here. We could keep a Tensor constructor on Scalar, but have it generate a local scalar; this is convenient but given this API used to be non-synchronizing, it may not be the best.

For now, I'm just using _local_scalar, which is clear, although we should get rid of the prefix _ if that's the API we intend to promote.

This is along the way of removing Tensor as a member of the tagged union in Scalar.  This simplifies ordering
dependencies, because currently Scalar and Tensor both depend on each other (so we introduce a TensorBase).  Also,
this API isn't particularly useful publically: we can't autograd through Scalars, so you still need a Tensor overload
basically everywhere anyway.

I'm undecided what the final API should be here.  We could keep a Tensor constructor on Scalar, but have it generate
a local scalar; this is convenient but given this API used to be non-synchronizing, it may not be the best.

For now, I'm just using _local_scalar, which is clear, although we should get rid of the prefix _ if that's the API
we intend to promote.
Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gchanan has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

return Scalar(-v.i);
} else {
return Scalar(-Tensor(t));
return Scalar(-Tensor(t)._local_scalar());

This comment was marked as off-topic.

This comment was marked as off-topic.

Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gchanan has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gchanan has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

zdevito pushed a commit to zdevito/ATen that referenced this pull request Aug 25, 2018
Summary:
This is along the way of removing Tensor as a member of the tagged union in Scalar.  This simplifies ordering dependencies, because currently Scalar and Tensor both depend on each other (so we introduce a TensorBase).  Also, this API isn't particularly useful publicly: we can't autograd through Scalars, so you still need a Tensor overload basically everywhere anyway.

I'm undecided what the final API should be here.  We could keep a Tensor constructor on Scalar, but have it generate a local scalar; this is convenient but given this API used to be non-synchronizing, it may not be the best.

For now, I'm just using _local_scalar, which is clear, although we should get rid of the prefix _ if that's the API we intend to promote.
Pull Request resolved: pytorch/pytorch#10852

Reviewed By: ezyang

Differential Revision: D9496766

Pulled By: gchanan

fbshipit-source-id: 16f39b57536b9707132a5a4d915650c381bb57db
petrex pushed a commit to petrex/pytorch that referenced this pull request Aug 27, 2018
* upstream/master: (89 commits)
  move HeatmapMaxKeypointOp unittest to oss
  fix xfails involving literals (pytorch#10905)
  Bag of Distributions doc fixes (pytorch#10894)
  Remove FIXME_zerol() from test_jit.py (pytorch#10900)
  Increase BC for PackedSequence ctor (pytorch#9864)
  Remove ability of Scalars to hold Tensors.
  Begin a bestiary of MSVC/NVCC bugs. (pytorch#10883)
  Prevent JIT from overspecializing to every single size configuration (pytorch#10844)
  Handling failing test on ROCm.
  Update mobile predictor caller's interface
  Cache isContiguous and numel
  Create class constant for string literal 'blob_names'
  Conv BN fusion for 3D conv (pytorch#10239)
  Stop using symbolic override for tracing RNNs (pytorch#10638)
  Add registry to pybind_state (pytorch#10759)
  Remove the nanopb submodule
  Create at::linear (pytorch#10799)
  Refactor THCNumerics and add common math functions for at::Half (pytorch#10301)
  Remove Tensor constructor of Scalar. (pytorch#10852)
  Revert D9492561: [pytorch][PR] Moving the operator argument to the front for kernelPointwiseApply.
  ...
PenghuiCheng pushed a commit to PenghuiCheng/pytorch that referenced this pull request Sep 11, 2018
Summary:
This is along the way of removing Tensor as a member of the tagged union in Scalar.  This simplifies ordering dependencies, because currently Scalar and Tensor both depend on each other (so we introduce a TensorBase).  Also, this API isn't particularly useful publicly: we can't autograd through Scalars, so you still need a Tensor overload basically everywhere anyway.

I'm undecided what the final API should be here.  We could keep a Tensor constructor on Scalar, but have it generate a local scalar; this is convenient but given this API used to be non-synchronizing, it may not be the best.

For now, I'm just using _local_scalar, which is clear, although we should get rid of the prefix _ if that's the API we intend to promote.
Pull Request resolved: pytorch#10852

Reviewed By: ezyang

Differential Revision: D9496766

Pulled By: gchanan

fbshipit-source-id: 16f39b57536b9707132a5a4d915650c381bb57db
@ezyang ezyang added the merged label Jun 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants