Unsigned primitives - for or against?

[Winston Gutkowski]

Stevens Miller wrote:As ever, Winston is correct.

Beware the false prophet, my son.

which means that this glaring omission in the language

And here I'm going to play the Devil's adovcate (a role, I'm sure, that you are well-versed in):

What glaring omission? Why on earth should I care whether some sub-atomic particle in the language is signed or not, when it makes absolutely no difference to the way it behaves except in terms of an arithmetic result - which, as you've already proved, can easily be converted to an unsigned value - and the only reason it does that is due to other sub-atomic behaviour (usually widening conversion) that I really shouldn't have to worry about.

And the fact of the matter is that you DO have an unsigned numeric value: char. So, if it was so important, why aren't they splattered all over the Java realm in areas they were never really designed for?

All that said, I've often wondered why BigInteger wasn't based on a char[] instead of an int[], because it would have saved the designers a LOT of boilerplate code.

Winston

[fred rosenberger]

i am not an expert on this, but I believe I have heard that java is not great for real-time applications. If it is absolutely critical you know how long your code will take to run (i think one such example is missile guidance systems), you don't want the JVM to pause for a few milliseconds while it does a GC.

[Winston Gutkowski]

fred rosenberger wrote:i am not an expert on this, but I believe I have heard that java is not great for real-time applications. If it is absolutely critical you know how long your code will take to run (i think one such example is missile guidance systems), you don't want the JVM to pause for a few milliseconds while it does a GC.

Good point, but does it actually involve a significant pause? I would have thought that a fair bit of work could be done in a background thread, and then a minimal pause to re-direct a few critical pointers but, like you, I'm no expert on this stuff.

That said, I wouldn't trust any language to be accurate to less than 1/10th of a second, given that the old standard for a "tick" was 1/100th.

Winston

[L Foster]

Stevens Miller wrote:So, we now have, in the library the Byte.toUnsignedInt method, which "supports" treating bytes as unsigned values.

For that alone, I given @Stevens a thumbs up. I work with Image Processing code, where I have to do conversions on things like Tiff and MPG files, on occasion. I also have to shoot buffers back-and-forth to OpenGL. Having to deal with regular bytes, which are signed in Java, means I have to do little tricks like adding 256 to any value less than 0. -1 is really 255. -2 is really 254. These negatives occur simply from reading in values greater than 127. If you can just get stuff and push it as you found it, it may not be a problem, but if you have to treat it as an integer, or combine three bytes together as parts of an int, it can be problematic.

@Joe, I hope you are not overhwelmed by all we have presented here. I also like the brief answer given by @Paul Clapham--more about when you would bother.

I think, too, I have come to think that some of the folks who'd have as little as possible to do with Java, are not put off at having to use (getting to use?) many different languages to solve parts of a given problem. Or, they may like to treat problems in their own setting, instead of trying to exploit a general-purpose language to do every possible thing. Java tries to be very powerful, and very broadly (WORA) of use. If you would like to use (just for example) your FORTRAN for calculations, your 'C' for systems work, your LISP for AI, and your Perl for strings, you may not see a need for Java.

Now this is sort of off-topic, but there are limitations in Java's virtual machine. It has cases of 'Leaky Abstractions'. It gives you java.nio and java.io, but it still has you worrying about filesystem delimiters. I would not mind Java attempting (or hearing why that's impossible) to abstract upon the whole machine.

[Stevens Miller]

Winston Gutkowski wrote:Why on earth should I care whether some sub-atomic particle in the language is signed or not, when it makes absolutely no difference to the way it behaves except in terms of an arithmetic result

Because the result matters. Consider this code:

public class Main
{
    public static void main(String... args)
    {
        byte[] effect = new byte[256];
        
        for (int i = 0; i < 256; i++)
        {
            effect[i] = (byte) (255 - i);
        }
        
        byte[][] image1 =
        {
            {
                10, 0
            },
            {
                0, 0
            }
        };
        
        byte[][] image2 =
        {
            {
                10, 0
            },
            {
                0, 0
            }
        };
        
        for (int r = 0; r < 2; r++)
        {
            for (int c = 0; c < 2; c++)
            {
                image2[r][c] += image1[r][c];
            }
        }
        byte[][] processedImage = new byte[2][2];
        
        process(image2, 2, 2, effect, processedImage);
        
    }
    public static void process(byte[][] image, int rows, int cols, byte[] effect, byte[][] processedImage)
    {
        for(int r = 0; r < rows; r++)
        {
            for(int c = 0; c < cols; c++)
            {
                processedImage[r][c] = effect[image[r][c]];
            }
        }
    }
}

All this does is take every element in a big (2D, not that it matters, really) array and indirect it through another array, storing the result in another array. In actual practice, this code would create a negative copy of a gray-scale image (a vastly complex special effect, for which I expect to be hearing from Spielberg's purchasing department, any day now ). As written above, it runs fine. But, change Lines 15 and 25 as below:

public class Main
{
    public static void main(String... args)
    {
        byte[] effect = new byte[256];
        
        for (int i = 0; i < 256; i++)
        {
            effect[i] = (byte) (255 - i);
        }
        
        byte[][] image1 =
        {
            {
                100, 0
            },
            {
                0, 0
            }
        };
        
        byte[][] image2 =
        {
            {
                100, 0
            },
            {
                0, 0
            }
        };
        
        for (int r = 0; r < 2; r++)
        {
            for (int c = 0; c < 2; c++)
            {
                image2[r][c] += image1[r][c];
            }
        }
        byte[][] processedImage = new byte[2][2];
        
        process(image2, 2, 2, effect, processedImage);
        
    }
    public static void process(byte[][] image, int rows, int cols, byte[] effect, byte[][] processedImage)
    {
        for(int r = 0; r < rows; r++)
        {
            for(int c = 0; c < cols; c++)
            {
                processedImage[r][c] = effect[image[r][c]];
            }
        }
    }
}

and you get this:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -56
at unsignedbyte.Main.process(Main.java:52)
at unsignedbyte.Main.main(Main.java:43)
C:\Users\smiller\AppData\Local\NetBeans\Cache\8.1\executor-snippets\run.xml:53: Java returned: 1
BUILD FAILED (total time: 0 seconds)

which, as you've already proved, can easily be converted to an unsigned value

Good point. Let's do that at Line 50:

public class Main
{
    public static void main(String... args)
    {
        byte[] effect = new byte[256];
        
        for (int i = 0; i < 256; i++)
        {
            effect[i] = (byte) (255 - i);
        }
        
        byte[][] image1 =
        {
            {
                100, 0
            },
            {
                0, 0
            }
        };
        
        byte[][] image2 =
        {
            {
                100, 0
            },
            {
                0, 0
            }
        };
        
        for (int r = 0; r < 2; r++)
        {
            for (int c = 0; c < 2; c++)
            {
                image2[r][c] += image1[r][c];
            }
        }
        byte[][] processedImage = new byte[2][2];
        
        process(image2, 2, 2, effect, processedImage);
        
    }
    public static void process(byte[][] image, int rows, int cols, byte[] effect, byte[][] processedImage)
    {
        for(int r = 0; r < rows; r++)
        {
            for(int c = 0; c < cols; c++)
            {
                processedImage[r][c] = effect[image[r][c] & 0xFF];
            }
        }
    }
}

Now things work again, so why am I still grousing? Here's why: that inner loop had 14 bytecode instructions in it to begin with. Adding that subatomic "& 0xFF" pads it to 16, adding 14% to the code in my inner loop, for no good reason.

...and the only reason it does that is due to other sub-atomic behaviour (usually widening conversion) that I really shouldn't have to worry about.

What makes you think you'd have to start worrying about it? Adding unsigned types wouldn't change the behavior of any code that didn't use them.

And the fact of the matter is that you DO have an unsigned numeric value: char. So, if it was so important, why aren't they splattered all over the Java realm in areas they were never really designed for?

Because upcasting the signed bytes to unsigned chars offers no advantages over upcasting them to ints, which is what everybody does. The advantage to unsigned bytes is not that they are unsigned, per se. It is that they can handle the range [0, 255], which signed bytes cannot, unsigned chars can, signed shorts can, and signed ints can. Thus, the fact that chars are unsigned is actually irrelevant. Signed chars, were they to exist, would work just as well as ints for "solving" this problem. Once you've got a native type that can hold the values [0, 255], all my problems go away, as Java does all its math as ints anyway, because (correct me if I'm wrong) the JVM manipulates shorts, chars, and bytes as though they were ints (which means that any real gains I would expect from unsigned bytes would also call for a change in the way the JVM pushes and pops things off its stack, and I know better than to expect that's ever going to happen).

As we've discussed before ( ), it doesn't take a lot of code to get around this glaring omission of Java. But... it's a constantly annoying aspect of the language that I have to deal with because of the lonely, overlooked work I do. I never had to deal with this nonsense in Good Olde C, and, when you are trying to process thirty frames of data containing 3.7Mb each, every single second, stuff that pointlessly adds 14% more code to your inner loops is not trivial.

[Stevens Miller]

L Foster wrote:I work with Image Processing code, where I have to do conversions on things like Tiff and MPG files, on occasion. I also have to shoot buffers back-and-forth to OpenGL. Having to deal with regular bytes, which are signed in Java, means I have to do little tricks like adding 256 to any value less than 0. -1 is really 255. -2 is really 254. These negatives occur simply from reading in values greater than 127. If you can just get stuff and push it as you found it, it may not be a problem, but if you have to treat it as an integer, or combine three bytes together as parts of an int, it can be problematic.

Good thing this forum is mostly text and not live video, 'cause I'm getting all misty-eyed and weepy, just reading this.

Finally, someone else who understands what it is I have to go through...

[Winston Gutkowski]

Stevens Miller wrote:Now things work again, so why am I still grousing? Here's why: that inner loop had 14 bytecode instructions in it to begin with.

Jeez. really? And that darn JVM, that presumably takes milliseconds to load and intialise, not to mention the classes required to make your program work, don't enter into that (probably peco-second based) equation?

So, what you're telling me is that a single use: the modular result of an arithmetic function - and moreover, it's use as an index - for which unsigned ints can't possibly have been intended, is sufficient reason to double the number of primitives in Java ... things which were arguably a mistake to begin with?

Clearly Microsoft think the way you do, since C# supports them; but given their track-record on writing software - let alone operating systems - you'll forgive me if I don't bow down three times to their decision.

The fact is that, for every major integral transformation other than division, signed 2's complement numbers behave exactly like unsigned ones. It's one of the reasons we love 2's complement. So the business of being a 'result' only comes to light when we look at it.

And how many times do we tell beginners on this site that what an object contains is NOT the same thing as what it looks like to us puny humans.

Don't worry, I'm just enjoying playing the Devil here. As an old C bod, I quite like unsigned numbers too.

But you're going to have to come up with something better than 14% to convince me that we're right.

Winston

[Winston Gutkowski]

L Foster wrote:I work with Image Processing code, where I have to do conversions on things like Tiff and MPG files, on occasion.

Which, to me, simply speaks to the power of the language. Do you really think that number/image crunching is what it was designed for?

Winston

[Stevens Miller]

Winston Gutkowski wrote:And that darn JVM, that presumably takes milliseconds to load and intialise, not to mention the classes required to make your program work, don't enter into that

No, since that's all one-time overhead.

(probably peco-second based) equation?

Now you're being hyperbolic. Even modern desktop computers don't do anything in a picosecond.

So, what you're telling me is that a single use: the modular result of an arithmetic function - and moreover, it's use as an index - for which unsigned ints can't possibly have been intended, is sufficient reason to double the number of primitives in Java ... things which were arguably a mistake to begin with?

The only such arguments I have heard in over 40 years of programming have been from people defending the lack of unsigned native integer types in Java. (And I don't know of anyone asking for unsigned floats or doubles.)

I don't believe the "intended" uses of a value are relevant. Moreover, if you do image processing, you do this kind of thing a lot. (Let me write that again: you do this kind of thing a lot.)

Further, I believe your criticism inverts the issue: I am not saying this very common, very useful, very obvious way to deal with image data justifies adding more primitive types to Java. Rather, I am saying that, in light of this very common, very useful, very obvious way to deal with image data, no one has ever been able to provide a convincing justification for leaving them out.

Clearly Microsoft think the way you do, since C# supports them; but given their track-record on writing software - let alone operating systems - you'll forgive me if I don't bow down three times to their decision.

No one would ask you to do that in this context, as it was never Microsoft's decision. When C was devised, one of Dennis Ritchie's goals was to rewrite Unix in C, something he knew would be easier with unsigned types than without them. Suggesting that Microsoft's preservation of unsigned types somehow trumps Dennis Ritchie's wisdom is an example of the logical fallacy of the "straw man." You are saying unsigned types are bad because Microsoft chose to retain them in C#, when no one has said C# is an example worth considering. C, on the other hand, is arguably the language most influential over the basic lexical stucture of languages like Java. And, we know from what the Java designers have said, that the decision was deliberately made to keep unsigneds out of Java. It wasn't a case of not thinking about it. It was a case of thinking about it and making the wrong choice based on a faulty assumption: that most programmers don't understand unsigned numbers. That's not supported by evidence nor experience, nor does it matter because those who only need signed types need not ever prepend their declarations with "unsigned." Those of use who need them can use them, and everyone else can go on as they wish, unconcerned with what we're doing.

The fact is that, for every major integral transformation other than division, signed 2's complement numbers behave exactly like unsigned ones. It's one of the reasons we love 2's complement. So the business of being a 'result' only comes to light when we look at it.

In that regard, I stand on my example. Image processing does that kind of thing all the time. (I'm told this is an issue for cryptographers, too, but I have no expertise in that area.)

And how many times do we tell beginners on this site that what an object contains is NOT the same thing as what it looks like to us puny humans.

That speaks to a level of abstraction that's not available to us here. I get my image data in packed 32-bit sets of unsigned bytes. I have no choice about that, so dealing with them in that form is something I cannot avoid. I could unpack those bytes into objects that, with appropriate methods, relieved me of ever having to consider their format again, and I would agree that would be good OO practice. But, once again, I must point out that I am in a hurry, with only 1/30th of a second between me and the next frame of nearly four megabytes that I must process. When my computer can unpack four million unsigned bytes into four million signed integers in a picosecond, I'll do it. Until then, I don't want to spend a single cycle manipulating data for any purpose other than moving towards my end result, even if that means treating my pixel values as the non-opaque, unsigned bytes they are.

But you're going to have to come up with something better than 14% to convince me that we're right.

Both I and L Foster already have: we both find it annoying, distracting, inefficient, and error-prone to have to keep putting things like "b & 0xFF" and "b < 0 ? b + 256 : b" everywhere, when unsigned bytes would (and, in other languages, effortlessly and harmlessly do) let us just say "b." Since the addition of unsigned native integer types would have no effect whatsoever upon anyone who doesn't need them, I'm baffled as to why anyone opposes them.

[Winston Gutkowski]

Stevens Miller wrote:Now you're being hyperbolic. Even modern desktop computers don't do anything in a picosecond.

No I'm not. You're talking about instructions measured in CPU cycles, which have been measured in picoseconds for a few years now - for what is 10 Gigahertz if not 10 cycles per nanosecond, or 100 picoseconds. And furthermore, we're talking about the difference in time between doing it with a signed or an unsigned integer.

Further, I believe your criticism inverts the issue: I am not saying this very common, very useful, very obvious way to deal with image data justifies adding more primitive types to Java. Rather, I am saying that, in light of this very common, very useful, very obvious way to deal with image data, no one has ever been able to provide a convincing justification for leaving them out.

No, I'd say you're inverting the argument. The language does not have unsigned integers. And presumably you knew this when you started on your image processing project. You also knew that the language probably wouldn't be able to process such data as fast as C++:
(a) because it doesn't compile to machine code.
(b) because it doesn't have the unsigned datatypes you want, which prevents you from doing an incredibly derived piece of logic easily.
and yet you still went ahead and did it in Java. I wonder why.

Paradoxically, you then moan about the one thing in the language which is likely to be the least of your worries: the number of picoseconds difference between the time it would take you to do it the way you'd like, and the amount of time it actually takes with the extra '&' inside an expression that is already evaluating the indices for and accessing, and assigning to elements in two separate two-dimensional arrays.
Now I'm no optimizer, but I find it tough to believe that '& 0xff' would make a 14% difference to all that. But you're the experts...

That speaks to a level of abstraction that's not available to us here.

That's true. But if the argument is "Java should have unsigned primitives" we're also talking about changing a language whose designers you already admit decided consciously NOT to include them; so you need to come up with a pretty good case for doing it.
And as far as I can see it, yours is that you want it for a very specific reason: The result of an arithmetic calculation can be used as a modulus index without manipulation.
Now if that ain't derived, or Knuth's root of all evil, I don't know what is.

we both find it annoying, distracting, inefficient, and error-prone to have to keep putting things like "b & 0xFF" and "b < 0 ? b + 256 : b" everywhere, when unsigned bytes would (and, in other languages, effortlessly and harmlessly do) let us just say "b." Since the addition of unsigned native integer types would have no effect whatsoever upon anyone who doesn't need them, I'm baffled as to why anyone opposes them.

Weirdly enough, I don't feel particularly strongly about it one way or the other, but I certainly don't find the "annoying" argument sufficient cause for changing things; and I assume that you're both good enough programmers to normalise the kind of code that might cause errors.

So let's add them: uint, ulong and ubyte. I presume that that we'd then need to agree on stipulations for widening and narrowing conversions for every possible combination of our (now) 8 integer types, not to mention between them and float and double, and of course all possibilities of autoboxing and unboxing.
On which subject: we'd also have to add three new wrappers that implement Number, which of course would also need to be changed to implement three new 'to' methods for our new unsigned types. Tell me: what should the result of Short.valueOf(-1).toUnsignedInteger() be?

Oh, and what about arrays. Presumably they should now allow uints inside square brackets, but what does that mean? Are values higher than 2³¹ now allowed, or should the value be implicitly cast to an int? And if the latter, doesn't that defeat your reason for wanting uints in the first place?

Like I say, I like unsigned types, but to me they're a convenience, not a necessity. The only types Java needs are the ones it's got.

Winston

[L Foster]

Since this topic is now "for or against", I will state flatly that if the unsigned primitives could be added without too great a penalty to other aspects of the language (things like performance, memory overhead, etc.), I would advocate adding them. Not having them has not killed any project I have tried, but it has complicated matters, making it easier to make mistakes by forgetting about the distinction.

If these primitives are never added, I will not feel compelled to switch.

@Winston, good call moving this to another thread.

[Paul Clapham]

That 14% code penalty for unsigning a byte -- there's more of that sort of thing because you're using Java. For example every time you use an array entry, something which you (Stevens) do a lot in that posted code, Java checks that the array index you used isn't out of range for that array. Other languages don't do that, they make you responsible for not going outside the array. Another penalty for using Java, this time in code which isn't visible to you.

[Campbell Ritchie]

Penalty? Ass opposed to the reward of being able to go beyond the bounds of your array and read the following memory location? That is what can happen in C/c++

[Winston Gutkowski]

L Foster wrote:@Winston, good call moving this to another thread.

Paul's actually, but I don't mind taking the credit.

Winston

[Winston Gutkowski]

L Foster wrote:Since this topic is now "for or against", I will state flatly that if the unsigned primitives could be added without too great a penalty to other aspects of the language ... I would advocate adding them.

Oddly enough, having started out on the fence, I'm now firmly in the enemy camp.

However, having had a night to mull on it, if the question was turned around to: "should the founding fathers of Java have made byte unsigned?", I think my answer would be 'yes'.
They already gave us an unsigned type (char), so it seems to me they could have easily said that byte was unsigned as well.

However, not having done a vast amount of byte-crunching in my career, I don't honestly know whether there are any advantages to having a signed byte or not.

Another question: Has anybody ever used shorts? It seems a remarkably useless type to me, but maybe I've just never done the kind of stuff that needs 'em.

Winston

[Stevens Miller]

Well, I think we've all had our say(s) on this, so I'll conclude my contribution by saying I still have not heard a reason why leaving unsigned ints out of Java served any useful purpose, and I will eagerly await the PM from Winston with the link to the place selling 10GHz desktop computers.

[Stevens Miller]

Winston Gutkowski wrote:Has anybody ever used shorts?

Not to continue the debate, but answer the question: there are a number of video formats that are encoded as shorts. This, and Winston's earlier reminder that opacity is a good thing, have me thinking that the difficulties appurtenant to image processing in Java are really examples of Paul's early observation: Java isn't the best at, "low-level messing around with hardware," which is really what I'm doing as I try to keep up with a real-time stream of raw video data coming from a camera. In RGB mode, you tend to get a stream of unsigned bytes, three per pixel. In (any one of several) YUV mode(s), that's commonly reduced to 16 bits per pixel with a trick based on the fact that our eyes are more sensitive to differences in brightness than to differences in color. Thus, the brightness at every pixel is sent from the camera, but (depending on the flavor of YUV you are using) the color might be averaged across two pixels horizontally, vertically, or both. This may sound like a ghastly way to treat otherwise exact image data, with the effect being that an image has fringes of color, blurry borders, and so on. However, it is virtually universal in consumer video, including the sharp pictures DVD players produce (don't know about Blu-ray). There are a number of advantages to YUV encoding, but a big one is that it shaves off a full third of the stream required to send an image. Thus, if you are willing to work in YUV space, your camera will not be delivering a stream of unsigned bytes. It will be delivering a stream of unsigned shorts. Again, if you don't mind the overhead involved in converting them to ints, you could do that and treat them as such ever after. But, in the first instance, you'll be getting them as a stream of shorts.

[Winston Gutkowski]

Stevens Miller wrote:It will be delivering a stream of unsigned shorts.

Ah, but an unsigned short does exist. It's called a char.

Winston

[Winston Gutkowski]

Stevens Miller wrote:Well, I think we've all had our say(s) on this, so I'll conclude my contribution by saying I still have not heard a reason why leaving unsigned ints out of Java served any useful purpose, and I will eagerly await the PM from Winston with the link to the place selling 10GHz desktop computers.

No, you're right. I assumed that since my 2 year old laptop, which was by no means expensive, was an i7 2.4, that they would have certainly cracked 5 by now; but it seems they're going for ever more cores rather than clock speed, and even the top ones are still only around 4, with one (an AMD) rated at 5.

Winston

[Stevens Miller]

Winston Gutkowski wrote:I assumed that since my 2 year old laptop, which was by no means expensive, was an i7 2.4, that they would have certainly cracked 5 by now; but it seems they're going for ever more cores rather than clock speed, and even the top ones are still only around 4...

It's a tricky parameter to make sense of. The "CPU" speed of a computer is, at best, the speed with which it is altering the CPU's state. It is typically unrelated to the (much slower) speed at which the CPU can read or write its memory (that's around 800 MHz, last time I looked, though, if you move 64 bits at a time, it's like a 6.4GHz machine that moves one byte at a time). Further, not only might there be multiple cores, but each one could be doing prefetch, conditional pre-calculation, reordering of instructions, and all kinds of other voodoo that make it nearly impossible to turn the CPU speed into any kind of operations-per-second metric. I haven't been involved in hardware issues for a long time, but, back when the first machines to have 1 GHz processors came out, some of my colleagues scoffed at such numbers, saying they were based on what a machine that could not do any prefetching, etc., would need to be clocked at to achieve the same effective rate of through-put. Also (and, again, I don't know how much of an issue this is today) microcoded machines typically took several cycles to complete one machine instruction. I know little about the JVM, but Intel processors still need more than one cycle to execute most of their instructions.

Further, physics plays a role here. The late Grace Hopper used to hand out "nanoseconds" at her speeches. These were copper wires, about eleven inches long. Her point was that electricity is slow (a bit slower in copper than light is in free space). An electric pulse can't even make it one foot in a nanosecond. As a picosecond is one-thousandth of a nanosecond, an electric pulse will only be able to make it about one-quarter of a millimeter in that time. This means that, if we ever build a CPU with a 1,000 GHz bus, the limiting factor in performance will be the length of the wires connecting the memory to the CPU. We might solve that problem with advances in integrated circuitry, but the industry isn't relying on it. It's relying on advances in concurrent methodologies (hence those multiplying cores we now see everywhere).

Fortunately for me, image-processing offers lots of opportunities to apply concurrency, so I'm pretty safe. Anyone whose problem requires them to process value A before they are able to process value B, however, is pretty close to the limit of what faster computers are going to be able to help them do.

[Stevens Miller]

Winston Gutkowski wrote:

Stevens Miller wrote:It will be delivering a stream of unsigned shorts.

Ah, but an unsigned short does exist. It's called a char.

True, but I actually misstated that, a bit. One tends to think of the data on a YUV stream as being in 16-bit quantities, but that's really a side-effect of the fact that you tend to get pairs of brightness ("luma") samples, and pairs of color ("chroma") samples. The pairs (in most formats, not all) come in packed 16-bit quantities, so it makes a mild sense to treat them as shorts. One could, however, treat them as bytes and do just as well. The business of converting these things to the final RGB triplets you ultimately need is a bit of a horror, involving the reversal of the expressions that gave you the original YUV values:

Y = 0.299*R + 0.587*G + 0.114*B
U = B - Y
V = R - Y

Now, here, signed bytes almost make sense, because U and V are typically encoded as bytes with values on the real range [-1.0, 1.0], where 128 maps to zero.

A lot of code (and hardware) does this conversion back and forth from RGB space and YUV space by table-lookups, so that array indirection business gets to rear its head here, too. (Back before wide-address machines were common, it was all done by direct computation. But, a 24-bit value only indexes a 16Mb table, and 16Mb ain't diddly anymore. Kind of a game-changer in my world, when that became the case.)