Internals: REAL and String Data Types

Internals: Understanding Sheerpower REALs

The Sheerpower REAL data type is not like the typical floating-point numbers used in other programming languages. Those languages rely on approximate binary representations that introduce subtle rounding errors. Sheerpower instead uses an exact decimal internal format, eliminating binary floating-point errors for decimal fractions and removing the need for defensive programming and epsilon comparisons.

1. REAL: Internal Representation

Sheerpower stores every REAL number as two 64-bit signed integers:

IP — The integer portion of the number (digits to the left of the decimal point), with a maximum magnitude of over a quintillion (10¹⁸).
FP — The fractional portion of the number (digits to the right of the decimal point), stored as an integer scaled by 10¹⁶ to preserve up to 16 decimal digits of precision exactly.

value = 13.599 IP = 13 FP = 5990000000000000 // 0.599 × 10^16 Example with more decimals: value = 3.1415926535897932 IP = 3 FP = 1415926535897932 (exactly 16 digits after decimal)

This separation allows Sheerpower to maintain complete decimal accuracy with up to 18 digits before and 16 digits after the decimal point, deterministically.

In standard floating-point math, "magnitude mismatch" errors occur when numbers of vastly different scales are mixed. For example, adding a micro-transaction to a national balance sheet might result in the smaller value simply disappearing due to the limitations of binary representation—technically known as loss of significance (absorption). By storing the integer and fractional portions separately, Sheerpower REALs prevent magnitude mismatch. You can safely add 1 quintillion and 0.000000000000123 without losing a single digit of precision.

2. Visualizing the Structure

The illustration below shows how a REAL value is stored:

REAL = 13.599

A REAL uses two separate 64-bit integers.

IP (Integer Part)
13

FP (Fractional Part)
5990000000000000

3. High-Precision in Action

Here's a classic example of floating-point failure in other languages:

print (0.1 + 0.2) - 0.3

In C, JavaScript, Python, or Java, this returns:

0.0000000000000000555...

But in Sheerpower, the output is:

Sheerpower gives you exact representation up to 16 fractional decimal places. Anything beyond that uses half-to-even rounding—no "close enough" comparisons, no fuzzy tolerances.

4. Why This is Important

Reliable financial systems — every penny is preserved
Accounting that stays accurate—$0.01 stays $0.01 forever, no drift over millions of transactions
Clean scientific and statistical results
No surprises when comparing REALs — exact match works
Perfect data interchange fidelity — string conversions are mathematically exact with zero precision loss across JSON, CSV, databases, and APIs

Sheerpower REAL stores values using an exact decimal representation with up to 18 digits before and 16 digits after the decimal point. Within this range, results are deterministic and free from rounding error. Calculations requiring greater range or precision may require IEEE doubles or extended-precision libraries.

(Show/Hide Performance Comparisons)

Typical Performance Comparisons—Cycle counts measured on modern x86-64 CPUs; relative ratios are architecture-stable.

**Table 1:** General Decimal Math (No Whole Number Optimizations) — both operands have fractional parts (e.g., `13.599 + 27.384`)
Operation	Sheerpower REAL	Java BigDecimal	Python Decimal	vs Java	vs Python
Addition	3-85 cycles	150-250 cycles	200-400 cycles	50-80×	65-130×
Subtraction	3-85 cycles	150-250 cycles	200-400 cycles	50-80×	65-130×
Multiplication	150-200 cycles	400-900 cycles	800-1500 cycles	2.5-6×	4-10×
Division	300-500 cycles	1500-3500 cycles	2500-6000 cycles	3-12×	5-20×

Notes:

Sheerpower addition worst-case (85 cycles) occurs with carry propagation; typical case is 3-5 cycles.
Java/Python costs include object allocation, context checking, and GC overhead.
Sheerpower operates entirely in registers/stack with no heap allocation.

**Table 2:** One Operand is a Whole Number — one operand has no fractional part (e.g., `13.599 × 100` or `price / quantity`)
Operation	Sheerpower REAL	Java BigDecimal	Python Decimal	vs Java	vs Python
Addition	1-2 cycles	50-60 cycles	200-250 cycles	30-50×	125-200×
Subtraction	1-2 cycles	50-60 cycles	200-250 cycles	30-50×	125-200×
Multiplication	6-10 cycles	80-120 cycles	400-500 cycles	10-15×	50-65×
Division (constant)	25-30 cycles	200-300 cycles	1500-2000 cycles	8-10×	60-70×
Division (cached)	25-30 cycles	200-300 cycles	1500-2000 cycles	8-10×	60-70×
Division (uncached)	130-150 cycles	200-300 cycles	1500-2000 cycles	1.5-2×	12-13×

Notes:

Constant = compile-time known divisor (e.g., /100 for percentage).
Cached = divisor seen before in runtime cache (common in loops).
Uncached = first time seeing this divisor value.
Sheerpower eliminates 2 of 4 multiplications in mixed whole/fractional multiply.
Java pays object allocation overhead even for whole number fast paths.
Python has no effective whole number optimization in Decimal.

**Table 3:** Both Operands are Whole Numbers — both operands have no fractional parts (e.g., `100 + 50` or `quantity × count`)
Operation	Sheerpower REAL	Java BigDecimal	Python Decimal	vs Java	vs Python
Addition	1 cycle	50-60 cycles	200-250 cycles	50-60×	200-250×
Subtraction	1 cycle	50-60 cycles	200-250 cycles	50-60×	200-250×
Multiplication	3 cycles	60-70 cycles	350-400 cycles	20-23×	115-133×
Division (constant)	5 cycles	110-130 cycles	1200-1500 cycles	22-26×	240-300×
Division (cached)	5 cycles	110-130 cycles	1200-1500 cycles	22-26×	240-300×
Division (uncached)	40 cycles	110-130 cycles	1200-1500 cycles	2.75-3.25×	30-37×

Notes:

Sheerpower reduces to pure 64-bit integer operations (FP portions are zero).
Division uses magic-number multiply-and-shift when the divisor is constant or cached.
Java still pays object allocation tax even though internal computation uses long.
Python uses full arbitrary precision machinery with no special-case optimization.
These cases represent 60-80% of business application arithmetic operations.

Performance Impact Summary

Typical Business Transaction (e.g., invoice calculation)

Operations per transaction: - 2x whole number additions (totaling quantities) - 1x mixed multiplication (quantity x price) - 1x division by constant (tax calculation: total / 100) - 1x decimal addition (subtotal + tax)

Implementation	Cycles per Transaction	Time on a Modern PC	Speedup
Sheerpower REAL	1+1+10+5+3 = 20 cycles	10 nanoseconds	Baseline
Java BigDecimal	50+50+100+110+150 = 460 cycles	230 nanoseconds	23× slower
Python Decimal	200+200+450+1200+250 = 2,300 cycles	1,150 nanoseconds	115× slower

1 Million Transactions

Sheerpower: 20M cycles = 0.01 seconds
Java: 460M cycles = 0.23 seconds
Python: 2.3B cycles = 1.15 seconds

Real-world impact: Processing a million invoices takes 1 second in Sheerpower vs 23 seconds in Java vs 115 seconds (almost 2 minutes) in Python.

Why Sheerpower REALs Only Became Practical Recently

Sheerpower REALs store values using two 64-bit signed integers. This design only became practical, providing high-performance, once 64-bit CPUs became the dominant execution platform.

The 32-bit constraint: In a 32-bit environment, each REAL would require four 32-bit integers to represent the same data. Every arithmetic operation would involve multi-word math, register spills, and helper routines, making exact decimal arithmetic consistently slower than native floating-point hardware.

As a result, most mainstream languages committed early to IEEE 754 binary floating-point (standardized in 1985) or to heap-allocated arbitrary-precision libraries such as BigDecimal (introduced in the 1990s). At the time, fast and portable 64-bit integer arithmetic could not be assumed.

What changed: Modern x86-64 CPUs perform 64-bit integer operations at full register speed. Values in the +/-10¹⁸ range fit cleanly within signed 64-bit integers (limit +/-9.22 quintillion), and native 64-bit multiplication produces 128-bit results that map naturally onto REAL arithmetic.

Why other languages could not pivot: Billions of lines of existing code depend on floating-point defaults, numeric promotion rules, and historical performance assumptions. Backward compatibility effectively locked those languages into their original numeric models.

Sheerpower REALs were designed specifically for the 64-bit era and the demands of large-scale business applications. In the previous 32-bit landscape, managing two 64-bit integers for every numeric operation was computationally prohibitive. By launching in the 64-bit era, Sheerpower was able to adopt exact decimal arithmetic as its default model—delivering deterministic financial precision at native-integer speeds.

Exact REAL Math Across Extreme Magnitudes

// Sheerpower Exact REAL vs. Standard Double Simulation // Purpose: Process 10 million Micro-Fees against a Global Balance // Standard Double-Precision would fail here: // 1. $105 Trillion requires 15 digits of precision. // 2. The micro_fee is at the 5th decimal place. // 3. Total precision needed: 20 digits (exceeds Double's ~16 digit limit). balance = 105_000_000_000_000 // $105 Trillion (IP=105T, FP=0) micro_fee = 0.00001 // For doubles, an "Impossible" binary fraction iterations = 10_000_000 print "Processing 10 million Transactions..." start timer // This loop leverages Register-Speed Integer Math for i = 1 to iterations balance = balance + micro_fee next i print "--- Results ---" print sprintf$("Final Balance: %m", balance) // %m = money format with commas print "Time Elapsed: "; _elapsed; " seconds" // Sheerpower remains exact. if balance = 105_000_000_000_100 then print "Verification: PERFECT. Zero drift after 10 million operations." else print "Verification: FAILED. Precision was lost:"; balance end if

The output:

Processing 10 million Transactions... --- Results --- Final Balance: 105,000,000,000,100 Time Elapsed: .218 seconds Verification: PERFECT. Zero drift after 10 million ops.

5. Summary

Sheerpower's REAL type utilizes a 128-bit fixed-point decimal representation, internally managed as two 64-bit signed integers. By fixing the decimal scale at 16 digits, the architecture provides computational determinism for base-10 fractions, eliminating the representation drift and epsilon comparison requirements inherent in binary floating-point (IEEE 754) math.

While floating-decimal implementations (like C# decimal or IEEE 754-2008 _Decimal128) offer greater scale flexibility for scientific applications, Sheerpower's split-integer approach is optimized for high-volume transactional logic. It trades dynamic scaling for instruction-level efficiency, mapping decimal arithmetic directly to native 64-bit integer pipelines. This architecture enables near-register speeds for financial calculations.

String Attributes for Efficient Processing

In this advanced discussion, we delve into Sheerpower's memory management and optimization strategies for handling strings efficiently.

Length-Aware Strings
Sheerpower STRING variables store their length internally, allowing immediate length access without scanning for a terminator.
Binary-Safe Content
Since the length is tracked internally, a STRING can include binary data, including embedded null characters.
name$ = "A" + char(0) + "B"
External Compatibility
When passed to routines in other languages, Sheerpower automatically appends a zero terminator for compatibility.
call "c_function" (name$) ! name$ is zero-terminated

Optimized Memory Management

Efficient Buffer Reuse

Sheerpower manages strings by reusing memory buffers, which significantly reduces the overhead of memory allocations and deallocations. For example, if a string holds "The rain in Spain" and is later changed to "Enjoy life", Sheerpower repurposes the existing buffer. In most applications, over 99% of string buffers are reused.

This approach avoids the frequent memory operations that cause performance bottlenecks in other languages.
All strings are over-allocated and virtually mutable, making assignments O(1) operations with no allocation/deallocation cycles.

text$ = "The rain in Spain" // Allocates a buffer text$ = "Hello world" // Reuses same buffer, updates length text$ = "X" // Still uses same buffer

Performance Impact: String assignments become fast, with no memory fragmentation. Sheerpower has no need for a garbage collector.

Comparison with Other Languages

In many languages, every string modification requires a new memory allocation, and the old memory must be deallocated. This cycle introduces overhead, especially in loops.

for i = 1 to 10_000
num$ = str$(i)
next i

Note: In Sheerpower, only one memory allocation is needed for num$. The buffer is reused in each iteration, a stark contrast to languages that could perform 10,000 allocations and deallocations, slowing down performance.

The Chunked Fixed Data Area (FDA) Optimized Memory Manager

Based on research showing 85% of business strings are under 128 bytes, Sheerpower pre-allocates thousands of fixed-size buffers on startup.

Three-Tier Memory Strategy:

Strings <= 24 bytes: Inline storage in descriptor
Strings 25-128 bytes: Pre-allocated FDA chunk (eliminates 85% of malloc/free)
Seven additional optimized string length ranges
Strings > 65536 bytes: Traditional heap allocation

Performance Optimizations Internals

String Interning with Shared String IDs (SIDs)

Sheerpower assigns every unique string value a 64-bit sequential String ID (SID). When a string variable is first created, the runtime generates a new SID for its content. When another variable is assigned the same content—either by direct assignment or by copying—the SID from the source descriptor is copied into the destination descriptor along with the data. In other words, the SID travels with the data.

The SID is stored directly inside the string's descriptor, alongside the string's length, the pointer to its character buffer, and the buffer's current allocation size. Because the SID lives inside the descriptor rather than in a centralized lookup table, Sheerpower avoids global SID-table lookups and enables several powerful runtime optimizations:

String Attributes for Efficient Processing

Descriptor holds length, pointer, current allocation, 24-byte inline buffer, and SID.

String DescriptorA$ stored locally

Value: "Hello"

Length: 5

Pointer: 0x00F3...

Allocation: 24 bytes current buffer size

SID: 982734 (in descriptor)

24-byte inline buffer

Strings up to 24 bytes stay entirely inside the descriptor. No heap allocation needed.

SID 982734 lives in the descriptor with length, pointer, and allocation, so no SID lookup table is required.

Buffer and Interning Behavior

For "Hello" (5 bytes):
inline buffer is used, no heap allocation.

Length <= 24 bytes uses inline buffer.
Allocation tracks current buffer size (here 24 bytes).
SID 982734 marks the content "Hello".
Equality check: compare SIDs, not characters.
Reassigning A$ reuses the same buffer until it outgrows 24 bytes.

Fast equality checks: Compare SIDs instead of scanning characters
Copy elimination: Skip copying when source and target already share SIDs
Hints can be stored along with their SID to avoid re-parsing of previously parsed strings

a$ = "Microsoft" // Gets a new SID, no runtime cost company_b$ = a$ // Inherits SID, no cost after first run company_c$ = company_b$ // Contains what a$ contains and a$'s SID

Copy-on-Write for String Literals

String literal assignments cost almost nothing, as the descriptor simply points to the literal in the compiled code. A copy is only triggered upon modification.

message$ = 'System ready' // Points to literal, no allocation backup$ = message$ // Shares same literal pointer's SID message$ = message$ + ' - OK' // NOW triggers a copy on first iteration only

Intelligent Caching and Hinting System

Sheerpower uses an internal hinting mechanism, leveraging SIDs to remember recent operations and cache results. This enhances efficiency by avoiding redundant processing.

Concatenation Hinting: A cache-sized hint array remembers recent concatenation operations by SID combinations. For repetitive tasks like building SQL queries, subsequent operations become simple cache lookups.

for i = 1 to 1000 sql$ = "SELECT * FROM orders WHERE id = " + customer_id$ // After first iteration, this becomes a cache lookup next

Function Parameter Parsing Cache: Functions like getword$() and geodistance() automatically cache parsing results by string content. If you call getword$(bible$, 1000) and then getword$(bible$, 1001), Sheerpower uses the hint to quickly find the next word without re-reading from the start.

here$ = "40.7128,-74.0060" dist1 = geodistance(here$, "34.0522,-118.2437") dist2 = geodistance(here$, "41.8781,-87.6298") // The 2nd call recognizes cached 'here$' coordinates and avoids the parsing and numeric conversion

Practical Benefits and Use Cases

These transparent optimizations provide the most benefit for typical business application patterns:

Repetitive content (company names, status codes)
SQL query building
Report generation and template formatting
Parsing repeated data formats

Sheerpower's memory management shines in applications where performance is critical, such as real-time data analysis, and large-scale batch processing systems.

Key Takeaway: Sheerpower's string optimizations work transparently to eliminate common performance bottlenecks. Developers write natural code while the runtime automatically optimizes for memory efficiency, eliminates redundant operations, and caches expensive parsing.

By understanding these advanced techniques, you can harness Sheerpower's capabilities to build highly efficient, scalable, and robust applications that handle strings with high performance.

Hide Description

a$ b$ x y

Enter or modify the code below, and then click on RUN

Looking for the full power of Sheerpower?
Check out the Sheerpower website. Free to download. Free to use.