wood burning stoves*
The moose likes Beginning Java and the fly likes Unsigned numbers Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Unsigned numbers" Watch "Unsigned numbers" New topic
Author

Unsigned numbers

Christopher Young
Ranch Hand

Joined: Nov 02, 2007
Posts: 63
Why doesn't Java have support for unsigned integers/floats?


Technology can never substitute for knowledge.
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11441
    
  16

i'll turn that question around. Why SHOULD java have support for unsigned integers?


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Christopher Young
Ranch Hand

Joined: Nov 02, 2007
Posts: 63
Because there's times when numbers don't have to be negative?
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by Christopher Young:
Because there's times when numbers don't have to be negative?

And signed ints won't work in those situations?


"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
Christopher Young
Ranch Hand

Joined: Nov 02, 2007
Posts: 63
Why is every argument against "just use signed ints" and not an actual reason for why the language is limited in this way?

I understand there are wrap around issues with unsigned ints, but i would also think that negative values for most things would produce an error as well ( and couldn't -1 for unsigned just be changed to "if value = the max for this number", or do negative values for -2 and less produce different results, and then, shouldn't that error checking be up to the programmer in the first place to not use unsigned where needed?).
[ March 27, 2008: Message edited by: Christopher Young ]
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14278
    
  21

Because unsigned numbers are not really necessary and just add an extra dimension of complexity to the Java language. Superficially it might not seem like a big deal to have signed an unsigned variants of byte, short, int and long, but if these were added to Java, then there would have to be added a whole set of rules about conversions and overloading as well.

Suppose that there was an unsigned int type in Java. Would you be able to write two overloaded methods like this:

Now, what if I called that method like this:

method(25);

Which of the two overloaded versions would be called?

This is only one example - there are lots of other issues that you could think of.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Christopher Young
Ranch Hand

Joined: Nov 02, 2007
Posts: 63
True, that could be a problem. But would the solution then maybe just be not to allow two methods of the same type and treat signed/unsigned as the same range in that respect

What about for instances in networking where the program is being passed unsigned numbers? Wouldn't it make sense to have support for that element of programming?
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[Christopher]: True, that could be a problem. But would the solution then maybe just be not to allow two methods of the same type and treat signed/unsigned as the same range in that respect

Well, that might be one solution, but not allowing unsigned data types is another, and that's the one that Java's designers used. It's a solution that results in less rules rather than more rules.

[Christopher]: What about for instances in networking where the program is being passed unsigned numbers? Wouldn't it make sense to have support for that element of programming?

Well, that is supported in some ways. For example the DataInputStream class has methods like readUnsignedByte() which reads a byte and treats it as an unsigned byte, returning the result in an int. The return type needs to be bigger than the base type in this case (i.e. int is bigger than byte) because it needs to be able to handle the additional range of an unsigned byte.

In general the need for unsigned types is fairly rare in Java, and when it comes up, tricks like DataInputStream's methods work well enough.


"I'm not back." - Bill Harding, Twister
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by Christopher Young:
Why is every argument against "just use signed ints" and not an actual reason for why the language is limited in this way? ...

Sorry, I'm not trying to be evasive. My point is that I don't see how this is a "limitation." It's kind of like having an AM/FM radio, and calling it "limited" because all you want is FM.
Stuart Smith
Ranch Hand

Joined: Mar 28, 2008
Posts: 54
Sorry if I did not understand you right here I am a beginner could you not just read it in hexidecimal?

Maybe this can explain the why?

http://darksleep.com/player/JavaAndUnsignedTypes.html

Goes back to the Oak specification and the fact that unsigned arithmatic made C complicated check it out.
[ March 29, 2008: Message edited by: Stuart Smith ]

Dale Carnegie:<br />"Most of the important things in the world have been accomplished<br />by people who have kept on trying when there seemed to be no hope at all."
Kaydell Leavitt
Ranch Hand

Joined: Nov 18, 2006
Posts: 689

Well, that [reading unsigned bytes] is supported in some ways. For example the DataInputStream class has methods like readUnsignedByte()


I found the method readUnsignedByte(), but what about writing an unsigned byte? I didn't find that method in the DataOutputStream class.
Christopher Young
Ranch Hand

Joined: Nov 02, 2007
Posts: 63
I would like to apologize, as well.

It's just saying that they're unneccessary to someone who is asking about them seems like an odd argument to use (if the person asking thought it was unneccessary, he wouldn't be asking).

Also a better solution to the method problem would be to treat signed and unsigned as a different thing altogether, kind of like how I couldn't pass a byte off to something that takes an int. But then maybe there'd be casting problems.

So I can kinda see why it was left out, but hasn't C++ solved such problems since they use functions very similar to Java's methods and such?

And there would definitely be some reasons for it, if there needs to be methods to read unsigned bytes and such. I can definitely see it being abused and giving programmers weird errors though when it loops back to 0 or goes to its maximum if it was assigned a negative value.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19723
    
  20

Originally posted by Christopher Young:
but hasn't C++ solved such problems since they use functions very similar to Java's methods and such?

C++ has solved several other problems, like real multiple inheritance and operator overloading. The result is additional complexity.

Java was created to be powerful but not too complex. As a result, some of the features of C++ were dropped.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Kaydell Leavitt
Ranch Hand

Joined: Nov 18, 2006
Posts: 689

i'll turn that question around. Why SHOULD java have support for unsigned integers?


I am trying to develop a database client that talks to a database server which was developed with some of the data-types being unsigned. It's very confusing since there is not a one-to-one mapping of unsigned types to unsigned types.

Because unsigned numbers are not really necessary and just add an extra dimension of complexity to the Java language.


It seems to me that if you're doing everything in Java that this is true. The complexity doesn't go away because Java only has signed integer types; the complexity is pushed to other places such as trying to talk in binary to software that is not written in Java. I only have control over the client end. I have to speak the language that the server speaks and this includes speaking in unsigned integers.

but if these were added to Java, then there would have to be added a whole set of rules about conversions and overloading as well.


I could live without overloading for signed and unsigned types. I know that if unsigned integers were introduced in Java, there would be backward-compatibility issues, but this could be solved by having a compile-time option such as the compile-time option that was introduced along with the keyword "assert".

This is only one example - there are lots of other issues that you could think of.


I don't know what you mean.

What about for instances in networking where the program is being passed unsigned numbers? Wouldn't it make sense to have support for that element of programming?


That's what I'm trying to do too, networking. Java has wonderful support for networking, but we're missing an important element and that is to talk to other programs that use unsigned integer types.

Well, that is supported in some ways. For example the DataInputStream class has methods like readUnsignedByte() which reads a byte and treats it as an unsigned byte, returning the result in an int. The return type needs to be bigger than the base type in this case (i.e. int is bigger than byte) because it needs to be able to handle the additional range of an unsigned byte.

In general the need for unsigned types is fairly rare in Java, and when it comes up, tricks like DataInputStream's methods work well enough.


I follow that there is a solution for reading bytes, but I don't understand how to write an unsigned byte. Maybe, I need to make my own DataOutputStream class and have it "do the right thing".



The link above looks like a solution. I'll have to study this.

Java was created to be powerful but not too complex.


It seems to me that for some problems when you simplify one thing that the complexity arises some place else. This is what is called "inherent complexity". You can move the complexity, but you can't get rid of it.

I suppose that most Java programmers don't care about unsigned integers because they're not talking to programs written in other languages that do have unsigned integers, but I do care because I'm currently writing software that does talk to software that speaks unsigned integers.

Java, as it is now, is like a person who can communicate in English, but is missing some important vocabulary to speak to others who do have more vocabulary, namely, unsigned integers (i.e. C++ and even Pascal now).
[ April 02, 2008: Message edited by: Kaydell Leavitt ]
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[KL]: I found the method readUnsignedByte(), but what about writing an unsigned byte? I didn't find that method in the DataOutputStream class.

That can be accomplished by simply casting to byte:

If the number was in the range [0, 127] then the cast will have no effect. If it's in the range [128, 255] then bit 8 (that is, the ninth bit from the end) will be zeroed. So for example, 255 which is 111111111 becomes 011111111, which is -1 if treated as a signed int. But if you read it as an unsigned int, it becomes 255 again. In other words, signed vs. unsigned is more of an issue when reading - you need to know what numeric range should be assumed for the answer. For writing, you just drop the extraneous bits anyway, and then they don't matter.

[CY]: It's just saying that they're unneccessary to someone who is asking about them seems like an odd argument to use (if the person asking thought it was unneccessary, he wouldn't be asking).

But the question you asked was why doesn't Java have unsigned types. In that context, we're responding why we believe that Java's designers chose to omit them. It's because Java's designers thought they were unnecessary, and generally created more complexity than solved problems. (At least that's what I think they thought, and what several others in this thread think. I think.) Of course you can disagree. There are some problems that would be simpler to solve with unsigned types - and there are other situations where unsigned types create additional complexity with little benefit. It's a question of which effect is more significant. Or since you're asking why Java is the way it is, it's a question of what Java's designers thought was more significant. Whether we agree or not now doesn't change what the designers thought back then.
Kaydell Leavitt
Ranch Hand

Joined: Nov 18, 2006
Posts: 689

...the ninth bit from the end) will be zeroed.....


I don't understand what is meant by the "ninth bit".

A byte is always 8 bits, so how can a byte have "a ninth bit"?
[ April 05, 2008: Message edited by: Kaydell Leavitt ]
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18914
    
  40

Originally posted by Kaydell Leavitt:

I don't understand what is meant by the "ninth bit".

A byte is always 8 bits, so how can a byte have "a ninth bit"?


There is no "ninth bit". Jim is using the concept to try to explain the difference between signed and unsigned arithmetic.

Basically, there is no difference. Everything from boolean arithmetic, to shifting, to the basic addition, subtraction, multiplication, etc. are all the same between signed and unsigned numbers.

This is why "twos complement" is the representation used for integers (and its variants). One of the interesting properties of using "twos complement" is that arithmetic done with it, is identical to, as if the operands were unsigned.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Um, the ninth bit is present in an int (or short or long) in the range [128,255] - which is the range I was talking about, as I stated. Remember, readUnsignedByte() reads eight bits and converts them into an int, not a byte, because it needs one more bit in order to represent values in the range [128,255]. Since Kaydell asked about a method to write an unsigned byte, I assumed this meant a method that reverses the process of readUnsignedByte(), therefore the data to be written should be assumed to be an int in the range [0, 255], not a byte. If it had been a byte in the first place, there would have been no need to cast it as I did.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Unsigned numbers