Int64*Uint64

[Keno]

This doesn't seem like the intended behavior. Are we accidentally trying to do the multiplication in Uint64?

julia> -1*uint64(1)
ERROR: InexactError()
 in * at promotion.jl:159
```?

[stevengj]

promote_type(Int,UInt) == UInt.

I personally dislike this behavior, similar to the C behavior that unsigned*signed == unsigned (which is even worse — C unsigned is downright dangerous because there is no error if you multiply an unsigned integer by a negative one, it just wraps around to a positive result).

[StefanKarpinski]

@stevengj, what would you prefer? I'm pretty open to any kind of persuasive argument here and now is a good time to change this kind of thing.

[stevengj]

I would prefer Signed * Unsigned = Signed. Argument: in ordinary math, negative * positive = negative. Deviating from this just to get an extra 1 bit of width in the case of positive values seems unpleasant to me.

(In the days of 16-bit integers, 1 bit was a big deal and maybe this was worth it. Nowadays, it seems a poor tradeoff.)

[stevengj]

Google "mix unsigned signed C" for lots of examples of how following C's promotion rules leads to grief. As a result, a lot of people recommend that you just don't use unsigned types in C (google "don't use unsigned").

[Keno]

At the very least the current behavior is inconsistent:

julia> -1*uint32(1)
-1

[ViralBShah]

The argument presented earlier was that when you use unsigned integers, you have a good reason for doing so and you want them to persist.

I personally prefer Steve's suggestion here.

[Keno]

I think that argument is fine but it doesn't work well with the checked conversion from integers to unsigned integers.

[StefanKarpinski]

What I suggested elsewhere in passing was having Int * UInt = Int and checked for overflow. Thus, if you want to do unchecked arithmetic you'd have to explicitly cast one of the arguments, as in (a % UInt) * b or a * (b % Int). That's not too terribly inconvenient to write. The advantage I can see for choosing to return an Int rather than UInt is that it can be value-correct for smaller more common arguments, including when the signed argument is negative – at the cost of not being able to represent large positive products. I think that's a good tradeoff, personally.

[rfourquet]

UInt64 are integers modulo 64 with positive representatives, so a positive Int64 can be directly interpreted as one of them, it's less clear for a negative Int64 (but I would prefer unchecked conversion if this is faster).
I like that promote_type(Int,UInt) == UInt but would want also promote_type(Int,UInt32) == UInt32.

[StefanKarpinski]

@stevengj, I googled "mix unsigned signed C" as you said and found a few relevant links:

• http://blog.regehr.org/archives/268 : not relevant – we do signed-unsigned comparisons correctly.
• http://stackoverflow.com/questions/2084949/arithmetic-operations-on-unsigned-and-signed-integers: ditto.
• http://stackoverflow.com/questions/50605/signed-to-unsigned-conversion-in-c-is-it-always-safe : more relevant, but could be mooted by doing the arithmetic checked and similar issues apply to adding an unsigned value to a large signed value.

This article http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/ phrases my argument quite nicely:

It is very easy to underflow the minimum value of an unsigned int (i.e. zero). It is much more difficult to underflow or overflow the minimum or maximum value of a signed int

So in general, I do agree that it is probably better to produced an Int for mixed UInt/Int arithmetic, but I'm not sure that most of the C horror stories are really relevant to the argument.

[StefanKarpinski]

I think that performance concerns are a bit of a false problem here – mixed type operations are not very common in high-performance code and if you really need that speed, you can just use a % Int to convert a UInt to Int with wrapping explicitly.

[StefanKarpinski]

Which would lead to a slightly philosophical question of why it's ok for Int/Int arithmetic to overflow but not Uint/Int arithmetic.

[toivoh]

+1 for Int * UInt to produce an Int.

[stevengj]

Where I have personally seen the current behavior as being undesirable is that often a Uint is used to represent the length of an array or a portion thereof, e.g. when an external C library returns a length as size_t. Suppose you want to access the array as A[offset + i * stride] where i = 0:length-1. i is a UInt if length is, so the code won't work if stride is negative. At least in Julia it will throw an exception. (In C, if you have 32-bit i and stride on a 64-bit machine, then the indices will wrap around to positive values and a segfault will ensue.)

(This came up in implementing FFTW, and is why we ended up using ptrdiff_t/intptr_t rather than size_t to represent transform sizes.)