Text Encoded Base 64 Numbers (Ten64) Adligo Inc.
scott@adligo.com https://github.com/adligo/ten64.adligo.org
Applications and Real-Time Internet Engineering Task Force Ten64 is a positional numeral system for representing numeric values with an alphabet of 64 characters (aka. radix/base 64). However, unlike most positional number systems, the characters are written in ascending (aka. big-endian, network-order) and NOT descending order. The main differences are the use of sextets (six bits) instead of octets (aka. bytes) . Similar to hexadecimal, Ten64 can be used to create binary strings of arbitrary length. Ten64 can encode one or more Modern Western Numbers (aka. Arabic, Vedic), interpreting the characters respective composite big-endian binary as a one or more Modern Western Numbers. The motivation for Ten64 is to encode numbers in a compact and human-readable format similar to Base58. However, Ten64 is designed to be optimized for use with numbers commonly used in identifiers, such as DIDs, DOIDs, IANA OIDs, UUIDs, dates, time(stamp)s, points, and more. Unlike Base58, and more like hexadecimal Ten64 aligns the Modern Western Numerals with the respective big-ending binary (i.e.; 0 → 0, 1 → 1, 2 → 11, etc). Finally, Ten64 provides a disk-based number encoding system for huge numbers and number streams.
Introduction This section is non-normative. Alternative notations and bases have historically been explored to improve human-machine interfaces, ranging from early discussions on binary notations to modern concepts like Hexadecimal, and Bioctal. Ten64 builds on this history by using a 64-character alphabet composed of standard ASCII-7 / UTF-8 characters. In addition to providing a solid manor to represent numbers using characters and their respective binary representations, Ten64 extends these representations with interpretation conventions. These interpretation conventions will likely be specified by some sort of schema system like EJCN (Extensible JSON Classification Notation) Schemas, JSON Schemas or XML Schemas.
Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document aligns with the formal IETF standardization procedures defined by the Internet Standards Process in BCP 9 .
In Ten64, we are targeting human-readable characters in the alphabet but do NOT intend to be human-decipherable. Our definition of these terms MAY be specific to this paper.
Our intended meaning of the term human-readable in Ten64 is that a human will be able to distinguish the characters from each other. We believe the best way of explaining this is with an example where one human would literally read the characters to another human over an audio-only telephone call. For example, the word Adligo is spelled out using a spelled-out phonetic alphabet. Capital A, as in Apple. Small d, as in dog. Small l, as in lake. Small i, as in indigo. Small g, as in golf. Small o as in otter. This is clearly human-readable.
Our intended meaning of the term human-decipherable in Ten64 is that most humans would be able to decipher the character stream. Ten64 does NOT target human-decipherability. We consider human-decipherability to be out of scope and may target another ID/ RFC for this work. Ten64 targets computer-decipherability and will rely on computer algorithms to translate Ten64 into in-memory integer and decimal numbers. In particular;
  • The Ten64 Integer Serialization Algorithm
  • The Ten64 Decimal Serialization Algorithm
Although this is decipherable for some humans who are developers or software architects, this point might seem insignificant. For the vast majority of the population, it is significant. The point is that software tools will generally be used to decipher Ten64.
Special Characters Introduction Ten64 does NOT use the Base64 RFC 4648 alphabet but a alphabet more in line with hexadecimal 0-9,a-k,$,m-z,A-H,+,J-N,!,P-Z, '@' and '_' along with some additional special characters most notably '#','.',',' and ';', '-', and the UNIX Line Feed 10 (0x0A in hexadecimal). It is designed to be human and machine-readable but is really designed to be optimized the reading and writing of numbers for streaming and storage computer systems. The $,+,!, @ and _ symbols were chosen because they human-readable. Theoretically, this system could also be used embed numbers into programming languages in the future. However, usage MAY require the explicit starting character pound '#', and explicit termination semicolon character ';'. It will use a big ending binary system as follows;
Special Characters and Sequence Details # Optional explicit beginning of #Ten64 binary section, use depending on context. #.. The optional explicit beginning of a multiple line Ten64 sequence. . The Decimal, List or Number Space Separator , The Separator for Number Lists ; Optional explicit end of #Ten64 sequence. - The negative indicator, and human-readable separator Whitespace Characters: including Line Feeds, Tabs, Spaces, Return Sequences, etc. MAY be included and MUST cause end of interpretation of the Ten64 sequence. UNIX Line Feeds: UNIX line feeds 10 / hex 0x0A MAY be used to continue a number sequence when the number sequence starts with '#..'. Other Non Alphabet Characters: MAY be included and MUST cause end of interpretation of the Ten64 sequence.
The Ten64 Alphabet Mappings Ten64 Alphabet Mappings
Primary ASCII / UTF8 Modern Western Integer Value Big-Ending Binary Sextet
00000000
11100000
22010000
33110000
44001000
55101000
66011000
77111000
88000100
99100100
a10010100
b11110100
c12001100
d13101100
e14011100
f15111100
g16000010
h17100010
i18010010
j19110010
k20001010
$21101010
m22011010
n23111010
o24000110
p25100110
q26010110
r27110110
s28001110
t29101110
u30011110
v31111110
w32000001
y33100001
x34010001
z35110001
A36001001
B37101001
C38011001
D39111001
E40000101
F41100101
G42010101
H43110101
+44001101
J45101101
K46011101
L47111101
M48000011
N49100011
!50010011
P51110011
Q52001011
R53101011
S54011011
T55111011
U56000111
V57100111
W58010111
X59110111
Y60001111
Z61101111
@62011111
_63111111
The primary Use-Case is simply an upgrade of hexadecimal , where Ten64 provides a more succinct/compressed string of characters. In addition, we target the encoding of numbers (n in the Text Encoded Base 64 Numbers title). Generally, we are also targeting identifiers of all kinds, attempting to make them as short as possible to improve human readability. Finally, we target human-readable compressed identifiers shortening UUID's as follows; # 36 character UUID 00000000-0000-0000-0000-000000000000 # to 27 characers 000000.000.000.000.00000000 # or 22 characters 128/6 0000000000000000000000 # or single or short sequences characters for small numbers 0
Ten64 is designed to be used to encode huge numbers, and is also optimized for this use-case. The 10-6-4 convention suggests huge strings of numbers SHOULD be segmented into segments of ten characters, six characters, and then four characters. In addition, these huge strings MAY be separated by the Unix line feed. This also creates a convention of at MOST 92 characters per line SHOULD be used, it is an effort to improve human readability. #.. 0123456789-abcdef-ghij-k$mnopqrst-uvwyxz-ABCD-EFGH+JKLMN-!PQRST-UVWY-XZ@_012345-6789ab-cdef ghijk$mnop-qrstuv-wyxz-ABCDEFGH+J-KLMN!P-QRST-UVWYXZ@012-345678-9abc-defghijk$m-nopqrs-tuvw yxzABCDEFG-H+JKLM; #.. 0123456789-abcdef-ghij-k$mnopqrst-uvwyxz-ABCD-EFGH+JKLMN-!PQRST-UVWY-XZ@_012345-6789ab-cdef ghijk$mnop-qrstuv-wyxz-ABCDEFGH+J-KLMN!P-QRST-UVWY.XZ@012-345678-9abc-defghijk$m-nopqrs-tuv wyxzABCDEF-GH+JKL-M; The above code illustrates a huge integer number and a huge decimal number. These kinds of Ten64 character sequences MAY be included as strings or as template literals in many programming languages. In addition, these huge numbers MAY be streamed from disk or over the network.
Ten64 is also a system to create BitSlotMaps#1.3.6.1.4.1.33097.1.1.3 (aka, BinaryStrings, BitVectors, BitSets, etc). Numbers are read into memory using the Ten64 integer serialization algorithm. Then the binary integer numbers MAY be reinterpreted per the user's wishes. Ten64 MAY also be used to represent arbitrary octet arrays. Note, conversion to octet arrays is NOT the primary Use-Case of Ten64, and that round tripping between octet arrays MAY introduce issues.
When converting Ten64 binary to an array of octets, all missing bits MUST be filled with zeros. This is to ensure that the binary consists of complete octets .
When converting arrays of octets to the Ten64 alphabet, all '0' characters from the Ten64 alphabet at the right MUST be omitted.
There are a ton of libraries in various languages, for example Java's BigInteger influenced the ECMA Script BigInt . In addition, this ECMA Script BigDecimal implementation is based on Java's BigDecimal. We do NOT expect Ten64 to gain wide adoption over the Modern Western Numeral System, since the Modern Western Numeral System is taught in early elementary schools and used all the way through advanced mathematics classes.
Ten64 significantly reduces the number of characters required for encoding, which saves on disk space in files and on the number of bytes transferred over sockets. Ten64 SHOULD be implemented using a more optimal algorithm to serialize and de-serialize the data than Modern Base-10 Numeral System serialization uses. To create integers from the Ten64 alphabet, algorithms SHOULD use switch statements to convert the Ten64 alphabet into little-endian binary (used in the majority of in memory number systems). Then the algorithms should shift the bits and use the binary and (i.e. &) operator to aggregate the number into integers. This Ten64 Integer Serialization#1.3.6.1.4.1.33097.0.2.4 Algorithm will complete with a O(s) serialization and O(c) de-serialization time cost. Note; s and c represent the sextets and characters in the previous sentence, respectively. Comparison with other algorithms which use various serialization and de-serialization forms to and from the Modern Western Numerical System is generally much slower.
  • Number Conversion Calculator
  • Number Conversion at Instructables
  • Number Conversion at Khan Academy
  • Number Conversion at Lumen
  • Number Conversion at WikiHow
However, when converting decimal numbers using Ten64 Decimal Serialization#1.3.6.1.4.1.33097.0.2.5, division is required. Depending on the division algorithm used, this is roughly comparable to serialization and de-serialization of the Modern Western Numerical System covered above.
When drafting Ten64, we went through great lengths to attempt to make it as compatible as possible with the largest number of usage environments. However, it is impossible to have pristine compatibility with such a large variety of usage environments. In short, for use in the REST Programming Style or other URI/HTTP based systems we recommend using Reserved Expansion from URI Template Variable Values with Ten64, ommitting the '#' and ';'.
The following Ten64 alphabet characters MAY have issues with URIs and URI Templates. The following section is in order of usage in Ten64.
The pound symbol is a protected character by the URIs RFC3986 section 3.2. When using Ten64 inside of URIs (aka URLs), the pound symbol MUST be either omitted or escaped with a percent sign '%23'. Additionally, no major conflicts are foreseen with URI Templates.
The minus symbol is an unreserved character by the URIs RFC3986 section 2.3. No special treatment of this character is required for URIs. However, URI Template Variable Names will require encoding as '%2D'.
The dollar sign symbol is a sub-delim character by the URIs RFC3986 section 3.4. It is explicitly permitted in the query component of a URI. Although NOT required by Ten64, some languages MAY require URL encode the dollar symbol. In particular, Bash, PowerShell, PHP, Perl, and Ruby where it is used to trigger variable expansion. Simple String Expansion in URI Template Variable Values MUST encode the dollar sign '$' as '%24'. However, Reserved Expansion in URI Template Variable Values MUST NOT encode the dollar sign '$'.
The plus symbol is a sub-delim character by the URIs RFC3986 section 3.4. It is explicitly permitted in the query component of a URI. However, many languages and libraries (PHP, Python's urllib, Java Servlets) automatically decode this as a space, so it MAY need to be escaped as '%2B'. Simple String Expansion in URI Template Variable Values MUST encode the plus symbol as '%2B'. However, Reserved Expansion in URI Template Variable Values MUST NOT encode the plus symbol '+'.
The exclamation mark is a sub-delim character by the URIs RFC3986 section 2.2. It is explicitly permitted in the query component of a URI. However, many languages and libraries (Express.js, Ruby on Rails, and Django) automatically decode this as a space, so it MAY need to be escaped as '%21'. Simple String Expansion in URI Template Variable Values MUST encode the exclamation mark '!' as '%21'. However, Reserved Expansion in URI Template Variable Values MUST NOT encode the exclamation mark '!'.
The period is unreserved in URIs RFC3986. However, it is often used for relative paths, We do NOT anticipate any compatibility issues.
The semicolon symbol is a sub-delim character by the URIs RFC3986 section 3.4. It is explicitly permitted in the query component of a URI. There may be legacy issues with Python and Java servlets, which have NOT received security patches. The semicolon MAY be omitted or encoded as '%3B'. Simple String Expansion in URI Template Variable Values MUST encode the seimcolon symbol ';' as '%3B'. However, Reserved Expansion in URI Template Variable Values MUST NOT encode the semicolon ';'.
We removed the use of the colon ':' and replaced it with an exclamation point '!', specifically to increase compatibility with the DID specification. However depending on usage, Ten64 MAY still require URI encoding for use with DIDs. did:ten64:abc123
DOID uses Ten64 in a downstream manner, so it is fully compatible with Ten64.
EJCN (Extensible JSON Classification Notation) uses Ten64 in a downstream manner, so it is fully compatible with Ten64.
JSON Strings are fully compatible with Ten64, as they use the backslash character '\' for escaping characters.
Various shells (i.e. Bash) will likely have some compatibility issues due to the dollar sign character '$' use when referenceing ENVIRONMENT_VARIABLES and function parameters. This can be overcome by escaping the dollar sign character '$' with a backslash '\$', or by wrapping the text in single quotes.
XML Strings are fully compatible with Ten64, as they use the are distinct from the big five XML characters '<', '>', '&', '"', and '''.
Ten64 SHOULD be generally compatible with most text files and programming syntax. We have intentionally avoided commonly used characters like brackets, braces and parentheses '[',']','{','}','(',')'. In addition, we have avoided common escape characters '%','&', etc.
The Ten64 character sequences may have additional corresponding meta-data information from various schema sources like;
  • EJCN (Extensible JSON Classification Notation)
  • EJCN (Extensible JSON Classification Notation) Schemas
  • JSON Schemas
  • XML Schemas
Although the definitions of all these schema types are out of the scope of this document, we supply the following interpretation conventions.
The following sequences explode as follows; #0.1; expands to a list of integers 0, 1 which MAY also be interpreted as the decimal 0.1 depending on the context. #0.1.2; expands to a segmented number / list of integers 0, 1, 2. #01.11; expands the a list of integers 64, 65 which MAY also be interpreted as the decimal 64.65 depending on the context. #-1.8; expands to a list of integers -1, 8 and MAY also be interpreted as a decimal -1.8 depending on the context. #-1.-9 expands to a list of integers -1, -9
There are several interpretation Use-Cases for segmented numbers, including Dates, Datetimes, MiliTimestamps, NanoTimestamps, DOIDs, IANA OIDs, Points and more.
Big Decimals (i.e. Java or Javascript type) can be easily represented with Ten64, which encodes the EXACT number of Decimal Places. This provides an alternative to JSON (decimal) numbers which MAY use IETF Single and Double Precision Floating Point numbers, because of the ECMAScript standard . The other alternative is to encode the Modern Western Numerals as strings, and then use something like a BigDecimal or BigDecimal clone to interpret the text data. See the commentary for a deep dive on this topic.
Dates can be greatly condensed using the Segmented Number base class. Dates should be standardized as the year ten64 followed by a dot, and one ten64 character for the month and one ten64 character for the day. For example; #Vv.21; expands to 2023-02-01
Datetimes add the additional timezone, (military time) hour and minute to the date. The timezone, (military time) hour and minute each only take one ten64 character and can be encoded as follows; #Vv.216jR; expands to 2023-02-01 CST 7:53 PM Note j is 19, in military time -12 = 7 PM.
Ten64 supports lists of number separated by commas, each number MAY include whitespace characters on either side of the number; #1,2,3,4; expands to a number list of 1,2,3,4 #1.2.3,4.5.6,7.8.9; expands to a list of 3d points
MiliTimestamps add a single ten64 character for seconds and separate milliseconds with an additional dot. #Vv.216jR1.2; expands to 2023-02-01 CST 7:53:01.2 or with milliseconds expanded PM 2023-02-01 CST 7:53:01.002 PM
NanoTimestamps add an additional dot, as the MiliSeconds can be multiple characters (with values 0-1000), and then multiple ten64 characters representing the additional (0-1,000,000,000) nanoseconds that are NOT tracked as milliseconds. #Vv.216jR1.2.7; expands to 2023-02-01 CST 7:53:01.2.7 PM or with nanoseconds expanded 2023-02-01 CST 7:53:01.002000007 PM
Ten64 can encode 2d, 3d, and Nd points as segmented numbers. # A 3d decimal point #-1.7,-5.2,-7.9;
Time will use the time segments from the Datetime, MiliTimestpan , and NanoTimestamp. # The Date Time #Vv.216jR; expands to 2023-02-01 CST 7:53 PM # vs just the time part #6jR; expands to CST 7:53 PM Note j is 19, in military time -12 = 7 PM.
Arabic, Ghubari, and Vedic as well as many other numeral systems were considered for use in this RFC. We finally settled down on modern the name The Modern Western Numeral System. It appears that numeral systems have influenced each other over the ages, and we will likely continue carbon dating each glyph 0-9 for some time, as we have recently carbon dated the glyph '0'. In addition, even if we do find an older carbon date of a particular glyph, It could take a considerable amount of time to determine if that carbon dating references a different culture than the main culture which recorded the glyph.
  • Origin of the Numerals
  • Carbon Dating Reveals the History of Zero Is Older Than Previously Thought
Before we go on to analytically review the Hindu-Indian Brahmagubta and Islamo-Arabic Ghubari origin of the modern mathematical numeral system which is now regarded as the Western Numeral System.
  • Origin of Modern Mathematical Numeral pg 46
Modern Western Integers are simply integers composed using the Modern Western Numerical System. Modern Western Integers MAY be positive, negative, or zero.
Modern Western Decimal Numbers are simply numbers using the Modern Western Numeral System, which contain a decimal point.
IANA Considerations Adligo Inc. maintains a Private Enterprise Number (PEN) Object Identifier (OID) registered with IANA. The specific OID allocated for the Ten64 serialization format is 1.3.6.1.4.1.33097.8.1. Further documentation regarding this registration is available at: https://adligo.github.io/papers.adligo.com/ietf-rfcs/Ten64.html There are no other IANA considerations for this document.
This section is non-normative. To improve human readability, we replaced these characters with their respective characters. The following chart shows the history of this. 21: lower case 'l' → '$' 44: upper case 'I' → '%' → '+' 50: upper case 'O' → '?' → ':' → '!' 2026-03-28 Replaced the % sign with the + sign to make URI (URL) escaping easier. Replaced the question mark with the colon to make URI (URL) escaping easier, and then later on replaced it with the exclamation point to make Ten64 more compatible with DIDs. Although Ten64 can encode and decode numbers of any size and precision, they are often not human-decipherable. During the creation of this text, there was much discussion about JSON RFCs 4627, 7158, 7159, 8259, JavaScript and ECMA Script Numbers. S Morgan believes that a separate document should be created to address the serialization/de-serialization (aka encoding/decoding) which uses text representing the Modern Western Numeral System specifically. He also suggests something like the following; 12 → int, long or ECMA BigInt, Language specifies. 12.78 → Java BigDecimal style numbers or a new BigNumber type f12.78 → 32 bit IEEE 754 / Java single floating point decimal numbers d12.78 → 64 bit IEEE 754 / Java double floating point decimal numbers Although the current state of the JSON RFC 8259 specification is fairly clear, it has a muddied past, which has created confusion and varying interpretations (i.e. GSON, Jackson and others). This starts with the usage of the term JavaScript in the title, the JS in JSON. It took some time for an actual JavaScript-like specification to emerge as ECMA Script which specifies IEEE 754-2019 Floating Point Numbers. These challenges and issues are not traceable to a single standard, but instead the result of the interaction between at least three standards bodies the IEEE, IETF and ECMA International , and the history of JavaScript and Netscape [2] [3] . As a side note, the ECMA Script 262 website chews up enough resources (processor/RAM I didn't benchmark it?) that it slows down and crashes browsers on my computer with 64 GB of RAM. However, for the brave people who want to click on these direct links;
  • ECMA Script 262 Section 6.1.6 Numeric Types
  • ECMA Script 262 Section 6.1.6.1 Language Types Number Type
  • ECMA Script 262 Section 21 Numbers and Dates
In some ways, these serialization issues appear to be fixed in part by more modern RFC's including the following;
  • CBOR RFC 8949 which simply uses a binary format to transfer the floating-point numbers.
  • HTTP Structured Fields RFC 9651 which does not target text but HTTP or really UIRs RFC 3986 and puts a tight limitation on decimal numbers, only allowing three decimal digits, which isn't compatible with Bitcoin and other wider decimal number formats.
The culmination of these points result in ubiquitous usage of string wrappers for numbers in tools like JSON, which forces the various parsers to get it right all the time; { "myJSONDecimalNumber": "12.3" } This essentially defeats the purpose of having a (decimal) number type in JSON. In addition, printing floating point numbers has been challenging historically. Which has led to the Ryū algorithm, which greatly reduced the time cost (asymptotic complexity) of printing floating point numbers in various JVM environments. Ryū itself improved on the previous How to Print Floating-Point Numbers Accurately paper by Guy L. Steele Jr. and Jon L White, and was eventually adopted by the JCP. Casual readers are encouraged to watch the Ryū video. Then ask themselves the philosophical question: What do you want to see from the following pseudo-code? var f : ieee754Float = f0.3 print(f) Some people would prefer Option A '0.3' while others (i.e. S Morgan) would prefer Option B '0.300048828125'. S Morgan thinks Option B is simpler, likely much faster to print and also provides a more accurate representation of what is actually stored in RAM without any rounding. In addition, since the Java BigDecimal style isn't actually a standard from any of these standards bodies, except for maybe the JCP. This means we don't actually have a solid standard for serializing money (i.e. USD, YEN, BTC, etc). Finally, after reading all of this and the citations to ANSI Math X3.274-1996 - X3.274-1996 AM 1-2000 section 74 in the Java 23 BigDecimal source code, (S Morgan) started to ponder: Is all of this mantissa stuff just too complex? S Morgan: From more of a philosophical Category Theory perspective; Are we actually usually doing discrete mathematics and have just added decimal places to help us read the natural numbers? For example, USD currency serialization and mathematical operations are actually using a natural number of cents. Perhaps we should just run with that and do much of our math with BigIntegers , BigInts, and then reformat the string representation with a decimal point. This would likely give most intuitive users who are just learning programming, math or both for the first time a much lower barrier to entry when performing most elementary to high school math, programming and serialization. A new BigNumber convention could be created on top of this idea leveraging the ISO/IEC 10967 integer datatype section 5.1 / International Math Standard. var b : BigNumber = 12.57 println(b) println(b.toDiscreteString()) println(b.hasDecimalPoint()) var i : BigNumber = -∞ println(i) println(i.hasDecimalPoint()) var c = BigNumber = 0.3 println(c) println(c.toFloat()) // should output the following text 12.57 1257 true -∞ false 0.3 0.300048828125 Then this new BigNumber type could potentially be used as the basis for further text-encoding number work with the Modern Western Numeral System. Finally, an open question. What should we do with fractions/repeating numbers (aka. connected overlines) (i.e. 0.̅0̅1̅2̅3̅4̅5̅6̅7̅8̅9 or 1/7 = 0.̅1̅4̅2̅8̅5̅7 ), another new BigFraction type perhaps? # Github Markdown for Connected Overlines 0.̅0̅1̅2̅3̅4̅5̅6̅7̅8̅9 1/7 = 0.̅1̅4̅2̅8̅5̅7
Finally, note that most of the Github style Markdown to RFC style XML conversion, and citations were generated by Gemini. Also, Gemini Deep Research, found ISO/IEC 10967 / A International Math Standard , and other content that I didn't track. Finally, note I dictated most of this paper using various voice-to-text AI software, which has given much of it a strangely verbal style. Feel free to reach out if you would like to correct, modify or add anything to this paper.
Normative References American National Standards Institute - ANSI Home American National Standards Institute (ANSI) Decimal Arithmetic Specification, version 1.70 - Appendix A: The X3.274 subset IBM Corporation Information Technology - Programming Language REXX InterNational Committee for Information Technology Standards (INCITS) Information Technology - Programming Language REXX InterNational Committee for Information Technology Standards (INCITS) American Standard Code for Information Interchange (ASCII) American Standards Association The Base58 Encoding Scheme Digital Bazaar Base58 is a group of binary-to-text encoding schemes used to represent large integers as alphanumeric text. It is designed to be human-friendly by excluding visually ambiguous characters. The Base16, Base32, and Base64 Data Encodings Bitcoin: A Peer-to-Peer Electronic Cash System BitSlotMaps Adligo Inc Carbon Dating Reveals the History of Zero Is Older Than Previously Thought Smithsonian Magazine Category Theory 1.1: Motivation and Philosophy Concise Binary Object Representation (CBOR) Universität Bremen TZI ICANN The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. Decentralized Identifiers (DIDs) v1.0 Digital Bazaar Digital Bazaar Danube Tech Avast Digital Bazaar Discrete Mathematics: An Open Introduction, 4th Edition University of Northern Colorado doid.adligo.org: Domain Oracle Identifiers Adligo GitHub Repository ejcn.adligo.org: Extensible JSON Classification Notation Adligo GitHub Repository EJCN (Extensible JSON Classification Notation) Schemas Adligo The EJCN schema system. GitHub Repository Endianness Wikipedia contributors IEEE Standard for Floating-Point Arithmetic IEEE This standard specifies interchange and arithmetic formats and methods for binary and decimal floating-point arithmetic in computer programming environments. The IEEE 754 Floating-Point Standard Gordon College MAT342 Numerical Analysis Course Material IEEE Floating Point Numbers Florida State University Department of Scientific Computing Resource Adaptive Floating-Point Summation and Arbitrary Precision Floating-Point Arithmetic University of California at Berkeley Algorithms for exact addition and multiplication of floating-point numbers, and their use in robust geometric predicates. IEEE 754: Standard for Floating-Point Arithmetic Wikipedia Wikipedia, The Free Encyclopedia Printing floating-point numbers quickly and accurately with integers Structured Field Values for HTTP Cloudflare The Varnish Cache Project This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". Hexadecimal Wikipedia Contributors Private Enterprise Numbers (PEN) IANA IANA Registry Institute of Electrical and Electronics Engineers (IEEE) IEEE IEEE Standard for Floating-Point Arithmetic IEEE Internet Engineering Task Force (IETF) IETF Elements of Information Theory Stanford University Stratify, Inc. JavaScript Wikipedia Contributors The Java Community Process(SM) Program - Home Java Community Process (Oracle Corporation) The application/json Media Type for JavaScript Object Notation (JSON) JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. The JavaScript Object Notation (JSON) Data Interchange Format JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The JavaScript Object Notation (JSON) Data Interchange Format JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The JavaScript Object Notation (JSON) Data Interchange Format JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. JSON Schema: A Media Type for Describing JSON Data Structures JSON Schema defines the media type "application/schema+json", a JSON-based format for describing the structure of JSON data. JSON Schema asserts what a JSON document must look like, what shapes it can take, and what values are valid. Computational complexity of mathematical operations Wikipedia Wikipedia, The Free Encyclopedia Information technology -- Language independent arithmetic -- Part 1: Integer and floating point arithmetic International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) A Mathematical Theory of Communication Bell System Technical Journal Natural number Wikipedia contributors Network byte order and host byte order IBM Origin of Modern Mathematical Numeral – 0, 1, 2, 3, 4, 5, 6, 7, 8, 9: the Hindu-Indian-Brahmagubta, The Islamo-Arabic or the West? Mubi North Education Authority, Mubi North Local Government Area, Adamawa State – Nigeria Browser History: Netscape Netscape's Rise and Fall: A Browser Wars History Netscape Wikipedia contributors Decimal to Binary Converter: 756 RapidTables How to Convert From Decimal to Binary Instructables Instructables Science and Tech Category Large Number Decimal to Binary Khan Academy Video Tutorial: Algebra / Alternate Number Bases Converting Between Bases Lumen Learning A comprehensive guide to positional numeration systems, detailing methods for converting between decimal and non-decimal bases. Waymaker Mathematics for Liberal Arts How to Convert from Decimal to Binary WikiHow WikiHow Technology Category OData Version 4.01. Part 1: Protocol OASIS OASIS OASIS Why we use base-10 almost everywhere than base-60 which was first invented method? ResearchGate Community Architectural Styles and the Design of Network-based Software Architectures University of California, Irvine Radix Wikipedia contributors ASCII format for Network Interchange The Internet Standards Process -- Revision 3 Key words for use in RFCs to Indicate Requirement Levels UTF-8, a transformation format of ISO 10646 Ambiguity of Uppercase vs Lowercase in RFC 2119 The JSON Data Interchange Format Ryū: fast float-to-string conversion Ryū: Fast Float-to-String Conversion (PLDI 2018) Octet Wikipedia Contributors Numeral system: Positional systems in detail Wikipedia contributors Sextet Wikipedia Contributors Ten64DecimalSerialization: A Concrete Algorithm for 64-bit Decimal Representation Adligo A algorithm for the deterministic serialization and deserialization of signed integers of various types into a string format suitable for high-performance computing and data transmission. Adligo Algorithm Specification Series Ten64IntegerSerialization: A Concrete Algorithm for 64-bit Integer Representation Adligo A algorithm for the deterministic serialization and de-serialization of various Decimal numbers into a string format suitable for high-performance computing and data transmission. Adligo Algorithm Specification Series UTF-8, a transformation format of ISO 10646 Alis Technologies Uniform Resource Identifier (URI): Generic Syntax URI Template Universally Unique IDentifiers (UUIDs) This specification defines UUIDs (Universally Unique IDentifiers) — also known as GUIDs (Globally Unique IDentifiers) — and a Uniform Resource Name namespace for UUIDs. W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes Informative References Java Platform, Standard Edition v21: Class BigInteger Oracle Corporation Java Platform, Standard Edition v21: Class BigDecimal Oracle Corporation Java Standard Library BigDecimal: Arbitrary-precision decimal arithmetic STZ-IDA NPM Package Bioctal: Hexadecimal 2.0 Community Origin of the numerals Department of Physics, Faculty of Sciences, Ferhat Abbas University
Sétif 19000 Algeria
Letters to the editor: On binary notation ACM ECMAScript 2025 Language Specification Ecma International Google Gemini: Scalable Multimodal Models Emergent Mind Google Gemini Deep Research: AI for Complex Tasks i10X Gson: A Java serialization/deserialization library to convert Java Objects into JSON and back Google GitHub repository Jackson: Main Portal page for the Jackson project FasterXML, LLC GitHub repository Language and Style Guide for IETF Authors Internet Engineering Task Force (IETF) Style guidelines for the preparation of Internet-Drafts and RFCs, covering English usage, technical terminology, and document structure. IETF Author Resources Representation of dates and times ISO Carbon Dating Reveals the History of Zero Is Older Than Previously Thought Smithsonian Magazine Smart News Extensible Markup Language (XML) 1.0 (Fifth Edition)
The author wishes to acknowledge , who was instrumental in providing meticulous scrutiny to this project. Although he disagreed and MAY still disagree with much of it, the discourse was wonderful and fully worthwhile.