open questions:

1. Should we treat python floats as doubles (as numpy does), or as the default scalar dtype (which will usually be float)?
2. Should we do device-type inference from the default dtype? That is, if the default dtype is a cuda type, should torch.tensor(0), torch.tensor(0.) create cuda tensors? (This is moot if we separate out device type from dtype, which we may do)
3. @fritzo @neerajprad I had to make a number of changes to distributions to get it to pass; basically, tensors are treated as is (so many needed to be passed floats instead of ints in the tests), but numbers are transformed into default dtype tensors by broadcast_all; this seems convenient, but leads to Distribution(0) behaving differently than Distribution(torch.tensor(0)) (you would need Distributions(torch.tensor(0.)) to get the same effect. Let me know if you think this is reasonable or prefer something else (like treating numbers as torch.tensor does, so we'd have to change the tests to be something like Distribution(0.).

@pytorchbot retest this please.

Latest commit treats python floats as the default (scalar) dtype instead of doubles.

For 2. above, we now have tests that exercise cuda type inference.

Also, I changed the promoteTypes logic to favor float32 over float64 with the combination (float32, int32) and (float32, int64); I believe @fmassa and @apaszke discussed this before. The particular reason in this case is so that:

torch.tensor(5., 0) uses the default tensor type (to match (torch.tensor(5.)); otherwise, the addition of the long, causes the promote types to return double.

@gchanan I think it's better like this.

Plus, current tensor/number operations in TH use the scalar type anyway, so the Python double type is already casted to float32 when we are using float32 anyway.

IIUC, I think you'll also want to change a couple of the distributions.constraints.* to floats. In https://github.com/pytorch/pytorch/blob/master/torch/distributions/constraints.py#L240:

- positive = _GreaterThan(0)
+ positive = _GreaterThan(0.)
  ...
- unit_interval = _Interval(0, 1)
+ unit_interval = _Interval(0., 1.)

Note that we have separate constraints for integers.