Prev: 1D to 3D coordinate translation. (No 16 million is right ?!)
Next: x86 Assembly Language FAQ - Microsoft MASM
From: Rod Pemberton on 2 Feb 2010 14:07
"Skybuck Flying" <IntoTheFuture(a)hotmail.com> wrote in message
news:83bbd$4b683ea9$d53371df$10717(a)cache4.tilbu1.nb.home.nl...
> "Single precision: 24 bits"
>

What?! You say that's in the floating point section? Ok...

> 24 bits would mean:
> 2^24 = 16777216

For an unsigned integer in binary, there are 16777216 or 0x1000000 (from
2^24) values within a 24-bit range. 0 (zero) is inclusive in that count.
That means the upper bound is one less: 2^24-1 or 16777215 (0xFFFFFF). The
range is from 0 to 2^24-1.


FYI...

The *PROBLEM* is that you're using decimal values.

Decimal values have no correlation between the representation of a binary
value and the bits used. You should be using hexadecimal for every data
type on a binary computing platform. Use hex for integers - both signed and
unsigned. Use hex for floats. Not binary. Not octal. Not decimal. Each
hexadecimal digit is 4-bits of binary. Everything should be represented as
binary on binary computing platforms. Hexadecimal is the most compact,
accurate, and convenient method to use to represent binary values. I've
seen only _one_ situation in 30 years of programming where hex wasn't the
best choice.

The "match the binary bits" feature of hex means it's easy to memorize the
results for 16-bits in hexadecimal. There are four hex characters at four
bits each for a total 16-bits: bit 0 thru bit 15. You can then use the
memorized results to confirm you've done the math correct for larger 24-bit,
32-bit, 64-bit, values. E.g.,

2^16-1 = 65535 = 0xFFFF (4 characters)
2^16 = 65536 = 0x10000 (5 characters) = 0xFFFF+1 or 65535+1

First, notice the relation of 0xFFFF and 2^16-1. Both can be constructed
from knowing the size is 16-bits. You can construct 0xFFFF knowing the bit
size: (16 bits)/(4 bits per char)=4 hex 'F' characters. Each 'F' hex
character is 4-bits, all bits set. You can then get 2^16 or 0x10000, by
adding one to each, respectively. 0x10000 is 5 characters. Since 0xFFFF
has four characters of 4-bits each, you know 0x10000 is over 16-bits in
size... It can't be a value in your range, although it can represent the
total number of values in the range, zero inclusive.

You were trying to take the sqrt in your other post. Look at it in hex, for
hex numbers of '1' with zeroes:

sqrt(65536)=256
sqrt(0x10000)=0x100
sqrt(0xFFFF+1)=0xFF+1

You cut the number of zero's in half or cut the 'F' hex version in half
keeping the plus one. Note that you shouldn't do sqrt's on other hex values
this way.

Multiplication of '1' with zeroes numbers in hex is easy. Add the zeroes:

0x100 * 0x100 = 0x10000 = 0xFFFF+1

Note that you shouldn't do multiplication on other hex values like this.

Since hex accurately represents binary bits, it's also a benefit when
setting and clearing bits. You'll need to memorize how to construct 4-bit
(nybble) values and their correspondence to the sixteen hex char's.

HTH,


Rod Pemberton
PS. If you really are serious when you ask for help, you might consider
change. First, you might try posting with a new nickname. Why? Because,
Harald, it seems that almost no one is responding to your posts as "Skybuck
Flying". You've been having complete, public conversations with your alter
ego for a few years now... Second, you might try to stop cross-posting to
unrelated groups from Delphi groups. Why? Because, it seems you're the
only one who does that. We'd know it's you. Third, why Delphi? Learn C or
C++ or Java or something that has value.


From: Skybuck Flying on 2 Feb 2010 19:37
No only thing I did wrong was:

8000 * 8000 = 16.000.000 ;) :)

But that's:

8000 + 8000 = 16.000.000 ;) :)

Wrong operator in head ! LOL.

And no hexadecimal is not good...

See germany bank problem where a programmer wrote 10 years in hexadecimal !
;)

Ooops ! =D

Bye,
Skybuck ;) =D


 | 
Pages: 1
Prev: 1D to 3D coordinate translation. (No 16 million is right ?!)
Next: x86 Assembly Language FAQ - Microsoft MASM