Hexadecimal Notation, Default Constructors, Incrementing,

[Dylan Kwon]

Hey everyone, I thought of these questions after taking practice tests.

What does 0xb mean?

As shown in the attached file, do user-created constructors automatically have the default constructor built into them?

What will variable a be after “a = ++a + a++;”? 8 or 9?

[Liutauras Vilda]

Dylan Kwon wrote:What will variable a be after “a = ++a + a++;”? 8 or 9?

If you tell us what the initial value of a is/was, then we could work out.

Equally, you could put that expression in code, execute, and print result, that would be the source of truth.

[Liutauras Vilda]

Dylan Kwon wrote:As shown in the attached file, do user-created constructors automatically have the default constructor built into them?

Once user defined a constructor themselves, there is no default constructor provided by Java. In your file example, there is simply a no-args constructor defined.

[Liutauras Vilda]

Dylan Kwon wrote:What does 0xb mean?

What is the exact question?

[Mike Simmons]

Dylan Kwon wrote:What does 0xb mean?

Your subject line starts with "Hexadecimal Notation", which suggests you already have some idea.  This is a way to represent a number in your program.  The "0x" part is the part that indicates this is hexadecimal notation, not decimal.  Whatever comes after the 0x is the actual value, using hex notation.  In hex the values for 10, 11, 12, 13, 14, 15 are represented by letters a, b, c, d, e, f - so 0xb indicates 11, because b indicates 11.  But it gets more complicated if there is more than one hex digit... 0xf is 15 in decimal, but after that 0x10 is 16 in decimal.  

[Tim Holloway]

When I was at school, one of the featured courses was "DP Math" (DP/Data Processing was the term used for what we call Information Technology these days, allowing for some evolution along the way).

One of the things that we covered in the course was alternate number bases. Which actually was a topic touched on at the grade-school level at the time. Not sure about now.

While "base 10" may seem natural to you, it is anything but. We could have just as easily used base 5. The Mayans had a very effective number notation that ran on Base 20. And even had a zero, which was not true in Europe until comparatively recently. The Greeks and Romans and Egyptions had no zero marker - it can from Hindu/Arabic sources.

And of course, the ancient Mesopotamians calculated freely using 60 as their basis, which we still carry over for common-use angle measurements and hours of the day.

But having numbers is only the start. Sooner or later you likely need to write them down. So Base 10 notation was born, the familiar 0123456789 glyphs. Or, in China/Japan and related countries, the equivalent characters, which I won't attempt to reproduce here. The "Arabic" Arabic numbers likewise, as well as the glyphs used in various alphabets, abugidas, and so forth around the world.

But most computers these days actually are comprised of binary ciruits. On/OFF, 0/1, and numbers in Base 2 (binary) are of course, 0, 1, 10, 11, 100, 101, …

Binary gets unwieldy once you have 16 bits or more, though, so we pick alternative notations, preferably based on powers of 2 in order to make conversion to Base 2 bits easier. For Unix systems, Base 8 (octal) was preferred: 0, 1, 2, 3, 4, 5, 6, 7, 10, 11, 12 … For mainframes, Base 16 was more common, and the fancy name for Base 16 is Hexadecimal. Beause we only have 10 standard digit characters, we stole alphabet letters for the higher numbers, which is how we got 0, 1, 2, 3, …, 8, 9, A, B, C, D, E, F, 10, 11, … 19, 1A, 1B, …

A legacy of the Unix octal notation is that a leading zero on a number indicates to C and later Java compilers that the number isn't decimal, it's octal. So, for example, the number 012 is actually decimal 10. That was extended to allow hexadecimal constants using an "x", so 0x0b is 013 octal, or 11 decimal.

And there you are.

[Dylan Kwon]

Thank you for the help everyone! The bit about hexadecimal history was a pleasant surprise too.

To answer Liutaras' question, a = 3, and the result is 8. The complete code looks like this:

int a = 3; 
a = ++a + a++;

I'm guessing that when a variable is incremented, it doesn't completely change until after the operation. So right after "++a" we have 4 + 3. a becomes 7. Then after "a++" it becomes 8. So incrementing the a on the left side did not change the a on the right side.

[Paul Clapham]

Tim Holloway wrote:One of the things that we covered in the course was alternate number bases. Which actually was a topic touched on at the grade-school level at the time. Not sure about now.

Yeah, the "New Math" was a school thing in the 60's. The mathematician/satirist Tom Lehrer wrote a song about then, explaining how to do arithmetic in base 8: New Math (song). A little web searching will yield suitable Youtube videos.

[Liutauras Vilda]

Dylan Kwon wrote:

int a = 3; 
a = ++a + a++;

I'm guessing that when a variable is incremented, it doesn't completely change until after the operation. So right after "++a" we have 4 + 3. a becomes 7. Then after "a++" it becomes 8. So incrementing the a on the left side did not change the a on the right side.

Not really. Answer is correct though, but the way it arrives at that is different than you described.

int a = 3; 
a = ++a + a++;

++a informally speaking means, increment current value of a and only then place it into expression
a++ means, place current value of a into expression and only then increment

So a starting value of a is 3
a = ++a + a++;

1. So first, increment current value of a and only then place it into expression, so we get:
a = 4 + a++;

2. Then, take current value of a (4) and place it into expression, and only then increment it, so we get:
a = 4 + 4; (= 8)

Now, a value of a got incremented to 5 technically, but that part got discarded (if that's a right thing to say), because we have no more code and the new calculation result got assigned to the same a.