Hacker News Reader

Comment by HalcyonCowboy | Hacker News Reader

Wouldn’t that last example be incorrect mathematically? For example, if the Int8 was -10 and the UInt16 was 10, what would that casting do? Would a better promotion be Int32 for both? Just curious, Julia is a language I’ve been very interested in using for a long time, just haven’t had the opportunity to sit down and learn yet.

View on HN

> Wouldn’t that last example be incorrect mathematically? For example, if the Int8 was -10 and the UInt16 was 10, what would that casting do?

Well....

Signed integer arithmetic and unsigned integer arithmetic do not differ. At all.

The difference between an Int16 and a UInt16 is not in the 16 defined bits. It's in the infinite number of implicit bits representing place values above 2^15. Those bits are always 0 for the UInt16, but they're identical with the high bit of the Int16.

So it's not clear what it would mean for the result type to be "incorrect mathematically". Mathematically, an Int16 and a UInt16 are the same thing.

However, the path by which you promote the values does matter. I don't know what Julia does. But:

      -10   (Int8) +   10 (UInt16)
      -10  (Int16) +   10 (UInt16)
    65526 (UInt16) +   10 (UInt16)
        0 (UInt16)

is a different result from

      -10   (Int8) +   10 (UInt16)
      246  (UInt8) +   10 (UInt16)
      246 (UInt16) +   10 (UInt16)
      256 (UInt16)

One of those should be the result Julia gives. I tend to hope it's the first one. That would correspond to a promotion strategy of "always expand the type to its full width before converting between signed and unsigned". Expansion (and shift, I guess) is the only operation for which the difference between signed and unsigned is relevant.

> Would a better promotion be Int32 for both?

Probably not; that would imply that when you add two UInt16s together, you expect to get a UInt32 (or UInt17...) back.

It took me a couple of readings to make sure I understood what you were saying, thanks for the reply. I think my misunderstanding was from not knowing Julia and thinking about promotion of values as having a permanent effect on the variables used, which isn’t what’s happening. As well, it requires the user to understand what they’re doing when they’re using an operator that uses automatic promotion, and to think about what they want to happen. For example, if Int8 = -10 and UInt16 = 5, and I’m expecting an answer of -5, then I’ll need to be more explicit to get the number I’m looking for. If I’m expecting 65530, then the implicit promotion works fine. Of course, this is no different from any other programming language that allows addition of differing types.

Great point on the path dependence.

> For example, if Int8 = -10 and UInt16 = 5, and I’m expecting an answer of -5, then I’ll need to be more explicit to get the number I’m looking for. If I’m expecting [65531], then the implicit promotion works fine.

That depends on what you're hoping to do with the number you're looking for. If you wanted -5 as an Int16, the bit pattern would be 1111 1111 1111 1011 or 0xFFFB.

If you wanted 65531 as a UInt16, the bit pattern for that is 1111 1111 1111 1011 or 0xFFFB. You're getting the same result either way. And any values you compute from that result [that is, by arithmetic] are going to be unaffected by whether you labeled the result "Int16" or "UInt16", because that's just a label. If you labeled 0xFFFB a "Snerf", the arithmetic would still be the same.

There are only a very restricted set of places where you need to be explicit about whether you think of your variable as an Int or a UInt:

1. When you're widening it.

2. When you're doing a right shift.

3. When you're formatting it for display to a human.

Yeah, case three was the one I was thinking of, though cases one and two are interesting as well. Number two requires you to think about using an arithmetic or logical right shift, though I'm struggling to think of a situation where you'd be promoting types and then not know what your intent was if you're then doing a right shift. I guess my confusion here is simply related to the idea that if you're getting that deep into binary, you'd probably want to be more explicit about what types you want to promote to, rather than relying on the Julia defaults. It's been a while since I've needed to think deeply about bitwise operations, still just as interesting as I remember.

Yeah, it's a little iffy. Finding a sensible set of promotion rules is hard. I don't know the reason (this was decided before I was involved), but if I had to guess, it would be because unsigned types are much less common, so if the user has them, they probably want to keep them for a reason.

Ah shit, well I guess you found the 0.1%

This is completely off topic here, but the first promotion of Int64 -> Float64 is also iffy as not every Int64 is exactly representable. The Int64 -> Float16 promotion also looks weird to me because Float16 range is so small

You think negative numbers in a signed type are a 1-in-a-1000 case, really?

Silently casting signed integers to unsigned is a terrible idea, and a recipe for bugs. And completely unnecessary to boot, because you could promote Int8 to Int16, and (Int16, UInt16) to (Int32, Int32).

Related, an integer bug that can't be fixed in C is that "unsigned short" promotes to "int" instead of "unsigned int", so this doesn't produce the result you want.

  unsigned x = (unsigned short)65535 * (unsigned short)65535;

(It overflows even though it's less than UINT_MAX, and worse it's UB.)

Reply on news.ycombinator.com