Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Hexadecimal Numbers

2 views
Skip to first unread message

GBSNathan

unread,
Sep 23, 2008, 1:52:00 PM9/23/08
to
I am a very new person to the Hexadecimal system.
My problem comes where I am converting decimal to hexadecimal. I have
a conversion chart and have come up with a basic formula for my self
that appears to work. Yet once I get above 255 decimal I am in a
waistland of unsurities. The only conversions charts I have found only
go to F10 which is of course the equivelent of decimal 255. my first
inclination for 256 is 1010 but my question is after 255 is that right
is should by following the pattern be 3 numbers not
4.
My formula is:
Decimal number is 255
255/ 16= 15.9375
round to 15
15*16 = 240
255-240 = 15
255= FF

Decimal number is 256
256/ 16 =16
16*16=256
256= 1010


Pascal J. Bourguignon

unread,
Sep 23, 2008, 3:17:46 PM9/23/08
to
GBSNathan <chucki...@gmail.com> writes:

The essence of positional notation for numbers is the following
formula:


p
___
\ i
N = > Di * B (1)
/__
i=0


B is an integer greater than or equal to two, called the base.
Di are integers between 0 and B-1 inclusive, called the digits.
i is the order, or position of the digit.


For example, one thousand two hundred and thirty four is:

MCCXXXIV = 4 * X^3 + 3 * X^2 + 2 * X^1 + 1 * X^0 = 4321 in base Ten.
MCCXXXIV = 4 * XVI^2 + d * XVI^1 + 2 * XVI^0 = 4d2 in base Sixteen.


Now, if you write B^i outside of the sum:

p p
___ ___
\ i 0 \ i
N = > Di * B = D0 * B + > Di * B (2)
/__ /__
i=0 i=1

so you can factorize B from the sum:

p
___
\ i-1
N = D0 + B * > Di * B (3)
/__
i=1

and you can repeat the process, until i=p:

N = D0 + B * ( D1 + B * (D2 + B * ( .... (Dp-1 + B * Dp)...)))

( This is what is called the Horner Form of a polynom.
http://reference.wolfram.com/mathematica/ref/HornerForm.html )


N = D0 + B * ( D1 + B * (D2 + B * ( .... (Dp-1 + B * Dp)...)))

We can identify this form to the quotient of N divided by B:

N = r + B * q

with r = D0
and q = ( D1 + B * (D2 + B * ( .... (Dp-1 + B * Dp)...)))

So we can easily find the digits of a number in base B, just by
repeatitively taking the quotient and remainder of a division by B.

N0 = N
D0 = remainder of N0 divided by B
Q0 = quotient of N0 divided by B

Ni = qi-1
Di = remainder of Ni divided by B
Qi = quotient of Ni divided by B

we can stop when the quotient Qi = 0.

And since the digits are found from d0 up to dp, we need to reverse
their order to have the most significant digits first.

(defun convert-to-base (N B)
(reverse
(loop
:for Ni = N :then Qi
:for Di = (rem Ni B) ; remainder
:for Qi = (truncate Ni B) ; quotient
:collect Qi
:until (zerop Qi))))


C/USER[27]> (convert-to-base (from-roman "MCCXXXIV") (from-roman "X"))
(1 2 3 4)
C/USER[28]> (convert-to-base (from-roman "MCCXXXIV") (from-roman "XVI"))
(4 13 2)


Notice that we don't convert directly from a representation in base B1
to a representation in base B2. The representation in base Ten of the
number MCCXXXIV is the sequence of digits (1 2 3 4). But to compute
the representation of that number in base Sixteen, we don't process
its representation, the digits 1, 2, 3 and 4, but the number MCCXXXIV
itself.


And of course, to convert from a representation in base B to a number,
you just apply the formuala (1) above.

(defun convert-from-base (digits B)
(loop
:while digits
:for n = (pop digits) :then (+ (* n b) (pop digits))
:finally (return n)))


C/USER[39]> (format nil "~@R" (convert-from-base '(1 2 3 4) (from-roman "X")))
"MCCXXXIV"
C/USER[40]> (format nil "~@R" (convert-from-base '(4 13 2) (from-roman "XVI")))
"MCCXXXIV"


And don't be misled by the fact that most computer programs do convert
automatically numbers represented in base Ten.


By the way:

256 in base Ten = Sixteen^2
= 1*Sixteen^2 + 0*Sixteen^1 + 0*Sixteen^0
= 100 in base Sixteen.

C/USER[43]> (convert-to-base (from-roman "CCLVI") (from-roman "XVI"))
(1 0 0)


--
__Pascal Bourguignon__ http://www.informatimago.com/

NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may
technically be entitled to claim that this product is
ten-dimensional. However, the consumer is reminded that this
confers no legal rights above and beyond those applicable to
three-dimensional objects, since the seven new dimensions are
"rolled up" into such a small "area" that they cannot be
detected.

jellybean stonerfish

unread,
Sep 23, 2008, 4:02:11 PM9/23/08
to
On Tue, 23 Sep 2008 10:52:00 -0700, GBSNathan wrote:

>The only conversions charts I have found only
>go to F10 which is of course the equivelent of decimal 255.

Your chart is wrong if it shows F10 as equal to decimal 255

> Decimal number is 255
> 255/ 16= 15.9375
> round to 15
> 15*16 = 240
> 255-240 = 15
> 255= FF

When adding in hex, you carry the same as you do in decimal.

DECIMAL
9 + 1 is 10
99 + 1 is 100
999 + 1 is 1000
9999 + 1 is 10000

HEX
F + 1 is 10,
FF + 1 is 100,
FFF + 1 is 1000,
FFFF + 1 is 10000

Mensanator

unread,
Sep 23, 2008, 9:09:19 PM9/23/08
to
On Sep 23, 3:02 pm, jellybean stonerfish <stonerf...@geocities.com>
wrote:

Or any other base for that matter.

OCTAL
7 + 1 is 10
77 + 1 is 100
777 + 1 is 1000
7777 + 1 is 10000

SLOT MACHINE ARITHMETIC
(Orange Lemon Bar Bell Cherries)

Cerries + Lemon is LemonOrange
CherriesCherries + Lemon is LemonOrangeOrange
CerriesCherriesCherries + Lemon is LemonOrangeOrangeOrange
CerriesCerriesCherriesCherries + Lemon is LemonOrangeOrangeOrangeOrange

Josh Sebastian

unread,
Sep 23, 2008, 10:54:37 PM9/23/08
to
GBSNathan wrote:

> I am a very new person to the Hexadecimal system.
> My problem comes where I am converting decimal to hexadecimal. I have
> a conversion chart and have come up with a basic formula for my self
> that appears to work. Yet once I get above 255 decimal I am in a
> waistland of unsurities. The only conversions charts I have found only
> go to F10 which is of course the equivelent of decimal 255. my first

I assume that's a typo. 255 is (as you show below) FF hex.

> inclination for 256 is 1010 but my question is after 255 is that right
> is should by following the pattern be 3 numbers not
> 4.
> My formula is:
> Decimal number is 255
> 255/ 16= 15.9375
> round to 15
> 15*16 = 240
> 255-240 = 15
> 255= FF

OK, so far so good.

> Decimal number is 256
> 256/ 16 =16
> 16*16=256
> 256= 1010

Here's a mistake. It's not two tens written next to each other. It's a one
followed by two zeroes: 100.

Here's a better algorithm.

16|256
----
16 r0
|
\/
16|16
--
1 r0
|
\/
16|1
--
0 r1

That's long division with remainders. You stop when you get a quotient of 0.

Now just write the remainders in reverse order: 100. So 256 decimal is the
same as 100 hex. Let's try another one that doesn't work out so neatly.
What's 1453 decimal written in hex?

16|1453
----
90 r 13

16|90
--
5 r 10

16|5
--
0 r 5

Now we have 5 10 13. But each of those must be a single digit. Well, what's
10 decimal in hex? A. And what's 13 decimal in hex? D. So we get 5AD.

This works for converting between any two bases, as long as you know how to
do arithmetic in the source base. The reason it works is because of what
place value notation means. As another pointer alluded, "5AD hex" means (in
decimal notation) 5 * 16 * 16 + 10 * 16 + 13. If you look, the operations
of the algorithm I showed you are the exact opposite of that. That's how it
converts between "place value notation" in one base to "place value
notation" in another base.

--
Josh

sp...@spam.de

unread,
Sep 24, 2008, 4:55:05 AM9/24/08
to
GBSNathan <chucki...@gmail.com> wrote:
> My problem comes where I am converting decimal to hexadecimal. I have

in order to check your calculations you could run a program like
http://www.ihr.uni-stuttgart.de/fileadmin/user_upload/autoren/ph/adakurs/ak00280a.txt

stan

unread,
Sep 25, 2008, 4:01:23 PM9/25/08
to
Pascal J. Bourguignon wrote:
> GBSNathan <chucki...@gmail.com> writes:
<snip>

> The essence of positional notation for numbers is the following
> formula:
>
>
> p
> ___
> \ i
> N = > Di * B (1)
> /__
> i=0
>

Did you do the formula by hand or use an app?
Sorry for the off topic noise folks.

Pascal J. Bourguignon

unread,
Sep 25, 2008, 6:09:25 PM9/25/08
to
stan <smo...@exis.net> writes:

For such a small formula, I did it by hand.

Otherwise, you could use maxima:
http://maxima.sourceforge.net/


(%i5) N = sum( D[i] * B^i, i,0,p);
p
====
\ i
(%o5) N = > D B
/ i
====
i = 0

(%i7) N = integrate(sum( D[i] * B^i, i,0,p) / (p + 1) ,p,0,Q);
Is Q positive, negative, or zero?

positive;
p
====
\ i
> D B
Q / i
/ ====
[ i = 0
(%o7) N = I ----------- dp
] p + 1
/
0


--
__Pascal Bourguignon__ http://www.informatimago.com/

HANDLE WITH EXTREME CARE: This product contains minute electrically
charged particles moving at velocities in excess of five hundred
million miles per hour.

stan

unread,
Sep 28, 2008, 3:07:48 PM9/28/08
to

Thanks, I use maxima but the output ascii isn't really much better than
the input words or maybe even the latex input. I'm talking strictly
about the presentation here, not the workings of maxima, of course.

I never had any luck but I think nroff and neqn were supposed to be able
to produce some output but I never had the motivation, time, need, ...
to get it working.

Last week that changed and I had a need but not the time so I did it by
hand myself. I made a mental note to add finding a real solution to my
rainy day list.
>

dearcilla

unread,
Sep 29, 2008, 11:57:15 PM9/29/08
to
On Sep 24, 4:55 am, s...@spam.de wrote:

> GBSNathan <chuckie72...@gmail.com> wrote:
> > My problem comes where I am converting decimal to hexadecimal. I have
>
> in order to check your calculations you could run a program likehttp://www.ihr.uni-stuttgart.de/fileadmin/user_upload/autoren/ph/adak...

Or the Windows calculator...

robin

unread,
Oct 14, 2008, 8:42:14 AM10/14/08
to
"GBSNathan" <chucki...@gmail.com> wrote in message
news:6b5e4550-ac77-44f9...@f63g2000hsf.googlegroups.com...

The corrrect computation is:

255 / 16 = 15 remainder 15
15 / 16 = =0 remainder 15

Thus 255 = FF

256 / 16 = 16 remainder 0
16 / 16 = 1 remainder 0
1 / 16 = 0 remainder 1
Thus 256 = 100 (base 16)

0 new messages