Assignment on Number Systems
My date of birth is 28-03-1979, which translates to the full-date digits 28031979, with the first
three digits being 280.
Introduction and approach:
When converting between decimal, binary, octal, and hexadecimal, I employ a
systematic, repeatable method: I utilize repeated division by the target base (2, 8,
or 16), collecting remainders, and then read the remainders in reverse order to
derive the result. For conversions to octal or hexadecimal, I can also convert
through binary by grouping bits (three for octal, four for hexadecimal). This ensures
precision and is the technique employed in low-level software and embedded
systems (Stallings, 2018). Step-by-step conversion of 280 (decimal) 1) Decimal →
Binary (base 2) — repeated division Divide 280 by 2 and record the remainders until
the quotient reaches 0: 280 ÷ 2 = 140 remainder 0 140 ÷ 2 = 70 remainder 0 70 ÷
2 = 35 remainder 0 35 ÷ 2 = 17 remainder 1 17 ÷ 2 = 8 remainder 1 8 ÷ 2 = 4
remainder 0 4 ÷ 2 = 2 remainder 0 2 ÷ 2 = 1 remainder 0 1 ÷ 2 = 0 remainder 1 ←
stop Read the remainders from bottom to top: 1 0001 1000 → 100011000₂.
(Verification: 2⁸ + 2⁴ + 2³ = 256 + 16 + 8 = 280.) 2) Decimal to Octal (base 8) —
repeated division: 280 ÷ 8 = 35 remainder 0; 35 ÷ 8 = 4 remainder 3; 4 ÷ 8 = 0
remaining 4. Read from top to bottom: 430₈. (Verification: 4·8² + 3·8 + 0 = 256 +
24 + 0 = 280.) 3) Decimal to Hexadecimal (base 16) — repeated division 280 ÷ 16
= 17 remainder 8 17 ÷ 16 = 1 remainder 1 1 ÷ 16 = 0 remainder 1 Read from top
to bottom: 118₁₆. (Verification: 1·16² + 1·16 + 8 = 256 + 16 + 8 = 280.) The
significance of proficiency (two practical applications): Embedded systems and
firmware: Numerous microcontrollers present registers, flags, and memory maps in
binary or hexadecimal format. Interpreting and manipulating bit patterns is crucial
for configuring control bits, applying masks, and developing device drivers.
Networking and debugging involve the examination of IP addresses, MAC addresses,
checksums, packet hexadecimal dumps, and low-level protocol fields, typically
represented in hexadecimal or binary format. Engineers must rapidly adapt to
analyze data, resolve issues, and execute protocols. Compiler/back-end developers,
forensic analysts, and hardware engineers all depend on these conversions.
Comparison of coding representations (ASCII, Unicode (UTF-8), BCD) Criterion ASCII
Unicode (UTF-8) BCD (Binary-coded decimal) Character set size 128 (standard) /
256 (extended) Over 1 million code points (encompasses all scripts) Not a text
character set — encodes decimal digits 0–9 Compatibility Ubiquitous for legacy
English text; direct compatibility with UTF-8 for 7-bit ASCII subset Extensively
supported across contemporary systems and web; backward compatible with ASCII
bytes Utilized in calculators and certain banking hardware; unsuitable for general
text Typical applications Legacy protocols, simple logs, embedded displays Web,
internationalized applications, databases, APIs Financial hardware, decimal
arithmetic where precise decimal representation is essential Efficiency Highly
efficient for plain English (1 byte/character) Variable length: 1–4 bytes per
character; efficient for ASCII-dominant text (1 byte) Inefficient for text; encodes
each decimal digit in 4 bits (potentially wasteful of space) Recommendation for this
task: Unicode (UTF-8). The rationale is that it provides comprehensive character
coverage, essential for devices exchanging multilingual labels or metadata, serves
as the web and modern operating systems' standard, and maintains backward
compatibility with ASCII, ensuring functionality for devices that only support ASCII.
UTF-8's variable-length encoding optimizes space and ensures compatibility
(Unicode Consortium, 2023). Consider a scenario in which the selection of coding is
vital: an international medical records system transmitting patient notes among
clinics across various nations. Utilizing ASCII-only encoding would result in the
corruption of accented characters and non-Latin scripts upon delivery, potentially
altering medicine names or patient identities. This may lead to misinterpretation of
records and clinical inaccuracies. Utilizing Unicode (UTF-8) safeguards all characters
and mitigates data loss; selecting an incompatible older encoding (e.g., EBCDIC or
ASCII-only) may compromise interoperability and patient safety.
References
Stallings, W. (2018). Computer Organization and Architecture. Pearson.
The Unicode Consortium. (2023). The Unicode Standard (Version 15.0). Retrieved from
[Link]