Printable View
Hello all,
I've been puzzled with this question for while now: what is the differences (i.e. advantages of using one over the other, speed, or anything) between using hex values versus decimal values as in this context:
To me, the prefered way would be using decimal since it is much easier to read. However, I see a lot of developers use hex... Just wonder why?Code:'Using hex
Dim X As Integer = &H7B
'Using decimal
Dim X As Integer = 123
Hope someone can shed a light on this.
a computer can read hex faster than decimal. Actually it can read binairie better but that's to hard to read for us so hex is a sort of in between solution.
This is true, and it may give some slight speed advantages back in the 286 processors' days... However, with today's processor speed, I would doubt if you can detect any speed differences... Besides, I haven't seen anyone code written this way:Quote:
Originally Posted by kevin hash
My question is, if using hex helps boosting execution speed, why is it not being used throughout the whole application but mainly just on constant variables?Code:For i As Integer = &H0 To &HFF23
'Do something
Next
Anything else besides speed?
its probably a throwback to the original 8086 + beyond
Computers cannot read hex, binary (when displayed with 0's and 1's), decimal or anything faster.
Hex is used to represent a number in a way where 16's mean something.
Colors have 16 meaning.
ASCII codes have 16 meaning.
So that is the whole reason - the only reason - to ever represent something in hex.
See this thread if you are interested in some reasons.
http://www.vbforums.com/showthread.p...hex+16+columns
These are all just visual representations. Everything is interpreted during the compile process - and of course - stored in binary.
[edit] clarified the "binary" issue in the first sentence [/edit]
As szlammy says, whether you use a decimal representation for your numbers or hexadecimal makes no difference to anything except the way you see the number.
The advantage of hexadecimal is that every two digits represents a byte. A 32-bit number in hex is 8 digits and each pair of digits represents 8 bits or 1 byte. That's much cleaner than a decimal numbers, that have no "connection" to bits and bytes.
Most of the time a number represented in hex takes less memory since it is composed of less 'characters'. I read somewhere that this was the main reason back then. I would imagine that data files are advantageously smaller this way, esp. if memory is more expensive than computing power (like 30 years ago).
That doesn't relate to the original question though. When you're talking about literals in code there is absolutely no difference except the visual difference because it's all binary when compiled.Quote:
Originally Posted by Half
Let's be clear.Quote:
Originally Posted by Half
Nothing is ever stored in hex.
It's only possible to store in binary - that's the whole point of magnetic recording media - whether it's disk, floppy or a 2GB memory stick.
So - we have bytes - 8 bits of memory. That's been a standard "size" for a long long time. Obviously you can store 256 different values in that 8 bit spot.
Now it's what you make those values represent that's important - not hex or decimal - but what they represent.
If you have 256 different characters - letters, numbers, symbols, etc - then you are using that one byte for a single "visual" entity. This is called character encoding.
That's expensive - especially as you said - 30 years ago (actually more like 50 years ago!)...
Back in my Digital PDP-11 mini days we had something called RADIX-50. Goal was basically to only store A-Z and 0-9 (and 6 symbols as well) - that's a lot less then 256 different characters. Since you didn't need all 8 bits to "encode" a character. You could actually store 3 characters in 2 bytes (or a 16 bit WORD).
http://en.wikipedia.org/wiki/RADIX-50
IBM and COBOL make extensive use of COMP fields - compressed numeric fields. If you are only storing digits and a plus/minus sign you can make much better use of the bits - not wasting 8 bits for each encoded character.
As for speed - if there are not machine-level instructions to deal with these encoding schemes they need to be converted to schemes that can be processed.
The real historical use of these odd encoding schemes comes from punch cards.
http://www.cs.uiowa.edu/~jones/cards/codes.html
There you only had 12 rows for each column - so you had better come up with encoding schemes that maximized what you were storing.
And of course that wonderful old media called paper tape
http://www.merrymeet.com/minow/papertape/papertape.html
I've used them all...
I study informatics. And in the hardware class we are now learning about coding , decoding and the difference between all those codes like hex, dec, octa,... But the things you just said are completely new to me. I didn't know that before. Thanks for that:d
You're actually learning about octal?
Very interesting information from veryone, especially Szlamany... So basically, since everything is compiled to machine language, it's pretty safe to assume that regardless of what base we use to code (decimal, hex, octal... you name it), it's not going to make any difference. Is that right?
Yes - that is basically true.Quote:
Originally Posted by stanav
When you assign a value to a variable in code - that literal can be pretty much any base.
Do we know for a fact that the compiler converts hex to bin with the same speed as dec to bin? I quess this would be the single advantage over the one way or the other no matter how small.
Hardly matters, since the conversion happens prior to runtime, but if you are wondering about the IL, all numbers are in hex in IL code. A decimal litteral shows up as Hex.
You would have to examine formulas and techniques for converting from one base to another.
Hex converts to nibbles (half a byte) rather nicely - but I'm not sure how you could determine how the IL hex values get loaded into memory...
Same as any others. ASM doesn't use binary, either, so hex is as far as we need to follow it. A decimal literal in code is converted to a hex in IL, and that's what matters.
But the CPU processes only binary - so the hex literals have to be loaded into binary memory storage - but we are probably talking about op-codes running on the chip anyway to accomplish this.
What is IL?Quote:
Originally Posted by Shaggy Hiker
Intermediate Language. VB.NET, C#, etc. code is compiled to MSIL, which is then compiled to machine code by the .NET Framework as it's executed. It's the .NET equivalent of Java bytecode.Quote:
Originally Posted by kevin hash
thanks for the information
In interpreted languages such as PHP and Perl - the characters need to be converted to a number. I guess you could say that the less characters you need to convert the quicker it will be converted. ;)
What you should however pay attention to is the types of variables you are using. When it comes down to values such as bytes there is an argument that storing them as a 32bit / 64bit integer is quicker than storing them as an 8bit integer as the whole thing can be thrown threw the processor at once. I am not sure of the turth in this but it hardly matters theis days ;).
As for floating point numbers - only use them if you need to. Single precision weighs in at 8 bytes and double prescision at 16 bytes. The whole number also comes in several urls. Floating point operations are somewhat slower than binary operations. :)
From the many participants' inputs in this thread, we can now conclude that it's not making any differences whether we use binary, octal, decimal or hex bases to write literals in our code. Unless someone can give a good reason why we should ever use any bases other than decimal, I'll keep using decimal because it's easier to read (at least with me). And I will mark this thread as resolved for now.
Thanks everyone for sharing your knowledge.
There are some kinds of data where Hex is easier to read, such as colour numbers: &H00FF00 is fully Green (the R and B components are 0, the G component is at the maximum); but the decimal equivalent 65280 isn't anywhere near as clear.
Similar applies to the numbers used by various API's, but in general decimal numbers are the easiest to read.