The Man Who Almost Invented Digital Currency

John L. Sokol and the DeCash System (2003)

---

A Decade Ahead of the Revolution

In August 2003, while most people were still using flip phones and dial-up internet, John L. Sokol filed patent applications for an electronic payment system that eerily predicted the digital payment revolution that would transform the world a decade later.

The invention, titled "Electronic Commercial Transaction System and Method", described a complete ecosystem for mobile payments using digital tokens stored on cell phones - years before the iPhone existed, before Bitcoin was conceived, and over a decade before Apple Pay would make mobile payments mainstream.

---

What Sokol Invented

The DeCash system included innovations that would later become billion-dollar industries:

Digital Currency Tokens

• Large random numbers (1024-bit) serving as unique digital "bills"

• Fixed denominations using binary increments ($0.01, $0.02, $0.04, $0.08...)

• Centrally tracked but anonymously transferable

• Each token verified against a central database

This predates Bitcoin's blockchain by 6 years and describes a centralized digital currency model similar to what many central banks are now developing as CBDCs (Central Bank Digital Currencies).

Mobile Wallet Technology

• Cell phones and PDAs as payment devices

• Wireless communication with merchants via infrared and Bluetooth

• Token management and automatic "change making"

• Secure communication protocols (SSL/SSH tunneling)

Apple Pay launched in 2014. Google Wallet in 2011. Sokol's patent application described this functionality in 2003.

Dual-Verification Security

• Both buyer and seller independently contact the bank

• Transaction only clears if both reports match

• Prevents fraud from either party

• Real-time validation over the internet

This "dual confirmation" model predates modern payment security protocols and anticipates the consensus mechanisms used in cryptocurrency.

Device Bridging

• One device can route another's communication through encrypted tunnels

• Enables offline merchants to process transactions

• Secure end-to-end encryption prevents man-in-the-middle attacks

This mesh networking approach for financial transactions was revolutionary for 2003.

---

The Physical Prototype

Sokol didn't just write patents - he built hardware. Working with Betson International / H. Betti Corporation, one of the largest vending machine manufacturers in the country, he created a 9-foot tall automated retail kiosk featuring:

• 40-inch flat screen display for advertising

• Robotic product dispensing

• Integration with the cellular payment system

• Support for high-end merchandise (not just snacks)

The prototype was photographed in what appears to be a workshop, showing a fully constructed unit with product categories including cell phones, DVDs, apparel, and collectibles.

---

Timeline Comparison

Technology	DeCash Patent	Mainstream Adoption
Mobile wallet payments	2003	Apple Pay: 2014
Digital currency tokens	2003	Bitcoin: 2009
Binary token denominations	2003	Cryptocurrency subdivisions
Encrypted mobile transactions	2003	Standard by 2015
QR/wireless merchant payments	2003	Widespread by 2020

---

Why It Matters

John Sokol's DeCash system demonstrates the gap between invention and adoption. The technology existed - on paper and in prototype form - over a decade before the market was ready.

Several factors limited adoption in 2003:

• Smartphone penetration: The iPhone wouldn't launch until 2007

• Mobile internet: 3G was just emerging; widespread mobile data was years away

• Consumer behavior: People weren't ready to abandon cash and cards

• Merchant infrastructure: Point-of-sale systems weren't equipped for wireless

• Banking partnerships: Traditional financial institutions were risk-averse

The documents in this archive show partnerships being sought with:

• Major banks (Bank of America mentioned as example)

• Cellular manufacturers

• Wireless carriers

• Retail location owners (Walmart, Target mentioned)

• Credit card processors (extensive list documented)

---

The Road Not Taken

Had DeCash achieved the partnerships and adoption Sokol envisioned, the digital payment landscape might look very different today. The system's architecture - centralized token verification with distributed wallet storage - represents a middle ground between traditional banking and decentralized cryptocurrency.

The PCT (Patent Cooperation Treaty) filing shows this wasn't a casual idea - it was a serious, internationally-protected invention with legal representation from Schweitzer Cornman Gross & Bondell LLP in New York.

---

Legacy

While DeCash never achieved commercial deployment, the archive serves as documentation of technological prescience. Every major payment innovation of the 2010s - mobile wallets, digital tokens, wireless merchant communication, encrypted transactions - was described in Sokol's 2003 documentation.

The question isn't whether Sokol was right about where payments were heading. The documents prove he was. The question is what might have been different if the world had been ready in 2003.

---

Documentation archived from original files dated August 2003. Patent application filed with US Patent & Trademark Office under PCT (Patent Cooperation Treaty) with file reference 1817-001PCT.

---

About John L. Sokol

John L. Sokol, based in Montclair, California, developed the DeCash electronic commercial transaction system in collaboration with Exsentrik Enterprises and hardware partner Betson International. The system represented one of the earliest comprehensive attempts to create a mobile-first digital payment ecosystem.

---

"The future is already here - it's just not evenly distributed." - William Gibson

Amorphous OS,: Web3 Done Right

Why a DAG-based P2P operating system is more Web3 than Ethereum

---

What Actually Defines Web3?

Before we can evaluate whether something qualifies as "Web3," we need to strip away the hype and identify the core principles. Web3 isn't about tokens, NFTs, or speculation. At its foundation, Web3 promises:

1. Decentralization — No single entity controls the network
2. Distributed Consensus — Agreement without central authority
3. Cryptographic Identity — Users own their keys, users own their identity
4. Programmable Trust — Code that executes without intermediaries
5. Token Economics — Native digital value transfer
6. Permissionless Access — Anyone can participate

Most "Web3" projects fail at least half of these. They run on AWS. They depend on Infura. They require centralized bridges. They're Web2 with a token bolted on.

AOS (Amorphous Operating System) takes a different approach.

---

Amorphous OS, Architecture: The Quick Version

AOS is a peer-to-peer operating system that runs in the browser. No servers. No cloud. Just browsers talking to browsers over WebRTC, synchronized via a DAG (Directed Acyclic Graph).

The core components:

• WebRTC Mesh — Direct peer-to-peer connections, no relay servers after bootstrap
• DAG Storage — Content-addressed data structure, like Git, distributed across peers
• Ed25519 Identity — Cryptographic keys for signing and identity
• Karma Reputation — Trust derived from peer behavior, not stake or mining
• Brain Pay — Micropayments via MetaMask or Brave Wallet
• Sandboxed Apps — JavaScript applications with security manifests

Let's examine each Web3 criterion.

---

Decentralization: Actually Decentralized

Most blockchain networks claim decentralization but funnel everything through centralized infrastructure. Want to use Ethereum? You probably hit Infura or Alchemy — centralized API providers. They can censor you. They can go down. They're single points of failure.

AOS has none of that.

After the initial bootstrap (which can be a QR code, a URL, or an existing peer), your browser connects directly to other browsers. No servers in the middle. No API providers. No infrastructure to take down.

The network is the participants. Remove any node, the mesh routes around it. There's nothing to shut down because there's nothing central to attack.

Verdict: More decentralized than Ethereum.

---

Distributed Consensus: DAG vs. Blockchain

Here's where it gets interesting.

Traditional blockchains use a linear chain. One block follows another. This creates bottlenecks — everyone waits for the next block. It limits throughput. It forces artificial scarcity.

AOS uses a DAG.

A Directed Acyclic Graph allows parallel commits. Multiple peers can add data simultaneously. Branches merge naturally. There's no single "canonical chain" that everyone fights over. Consensus emerges from the structure itself.

Linear Blockchain	DAG
One block at a time	Parallel commits
Artificial scarcity	Natural throughput
Miners compete	Peers cooperate
Slow finality	Fast convergence
Energy-intensive	Lightweight

The DAG is the ledger. It's cryptographically linked. It's distributed across all peers. It provides the same guarantees as a blockchain — immutability, verifiability, consensus — without the bottlenecks.

Verdict: Better consensus mechanism than blockchain.

---

Cryptographic Identity: Keys You Actually Control

AOS uses Ed25519 keys for identity. You generate your keypair locally. Your private key never leaves your device. Your public key is your identity.

No email signup. No phone verification. No KYC. No centralized identity provider that can lock you out.

The invite system extends this elegantly. An invite is an encrypted string containing:

• The inviter's public key
• WebRTC signaling data
• Connections to high-karma peers

It's a cryptographic handshake. You verify the inviter, they verify you, and you're in the network with a chain of trust.

Verdict: True self-sovereign identity.

---

Smart Contracts: Sandboxed JavaScript Apps

This is where people get confused. They hear "smart contracts" and think Solidity, EVM, gas fees, immutable bytecode on Ethereum.

But what is a smart contract, really?

It's code that executes in a trustless environment. Code that participants can verify. Code that runs without a central authority controlling it.

AOS apps are exactly this.

They're JavaScript. They run in browser sandboxes — the most battle-tested execution environment in computing history. Billions of users run untrusted JavaScript safely every day.

AOS apps include:

• A manifest declaring permissions
• Source code anyone can inspect
• Cryptographic signatures proving authorship
• Distribution via the DAG, not app stores

They execute on the peer network. They're stored content-addressed. They can be verified by anyone. They're more auditable than EVM bytecode — it's readable JavaScript, not compiled opcodes.

The difference? No gas fees. No waiting for block confirmation. No network congestion. Your app runs instantly on the peer that needs it.

Verdict: Smart contracts without the friction.

---

Token Economics: Brain Pay

AOS integrates with existing wallets — MetaMask, Brave Wallet — for micropayments. No new token to launch. No liquidity problems. No exchange listing drama.

Creators can accept donations. Apps can charge for services. All through standard Web3 wallet infrastructure.

But here's the twist: the primary economic mechanism isn't tokens. It's karma.

Karma is reputation. It's earned by contributing to the network. By sharing storage. By relaying messages. By building apps people actually use.

High-karma peers get priority. They're trusted for bootstrapping. They're weighted in consensus. Karma is the currency of influence, and it can't be bought — only earned.

This solves the plutocracy problem. In proof-of-stake, the rich get richer. In AOS, contributors get influence. It's proof-of-value.

Verdict: Economic incentives aligned with utility, not speculation.

---

Permissionless Access: No Gatekeepers

Want to join the AOS network? Get an invite from any existing participant. That's it.

Want to build an app? Write JavaScript. Package it. Sign it. Distribute it.

No app store approval. No platform fees. No API keys. No terms of service that can change under your feet.

The network is open. The code is open. The data is yours.

Verdict: Genuinely permissionless.

---

The Comparison

Criterion	Ethereum	AOS
Decentralization	Infura-dependent	True P2P
Consensus	Linear blockchain	DAG
Identity	Wallet addresses	Ed25519 + invite chain
Smart Contracts	EVM bytecode	Sandboxed JavaScript
Payments	ETH + tokens	Brain Pay + karma
Permissionless	Mostly	Fully
Speed	~15 TPS	Limited by WebRTC, not consensus
Energy	High (was PoW, now PoS)	Minimal

---

Why This Matters

Web3 promised a decentralized internet. Instead, we got:

• Centralized RPC providers
• VC-funded L2s with admin keys
• Tokens launched for extraction, not utility
• User experience so bad that normal people can't participate

AOS delivers what Web3 promised.

It's a peer-to-peer network with no central infrastructure. It's a DAG-based consensus system that actually scales. It's smart contracts you can read and apps that run instantly. It's an economic system based on contribution, not capital.

Is it Web3? By every meaningful definition, yes.

Is it more Web3 than the projects that claim the label? Arguably, yes.

---

The Technical Reality

AOS isn't vaporware. The architecture is concrete:

• Bootstrap: Single HTML file, no server required
• Networking: WebRTC with STUN/TURN fallback
• Storage: Content-addressed DAG with Merkle verification
• Crypto: Ed25519 for signing, X25519 for key exchange
• Apps: .aos packages (ZIP-like) with manifest.json
• Payments: Web3 wallet integration (EIP-1193)

It runs in any modern browser. It works on phones. It could run on robots.

The question isn't whether it's technically feasible. It is.

The question is whether people are ready for actual decentralization — or whether they prefer the theater of Web3 with the safety of Web2.

---

Conclusion

Web3 was supposed to be about returning power to users. About networks without owners. About code as law.

Most Web3 projects compromised on these ideals for speed, convenience, or profit.

AOS doesn't compromise.

It's Web3 done right.

D i g i t a l R e c o r d i n g On The IBM Compatibles

D i g i t a l    R e c o r d i n g
       On The IBM Compatibles

  Have you ever wondered why the Apple MAC and Amiga Can play
back hi quality sound and generate music that sounds like a $50,000
synthesizer and you IBM PC/clone Only plays Beeps and tones?
  The only reason IBM put a speaker on there pc was because it was
cheeper than using a buzzer. The output is only one bit and Looks more
like they just stuck a speaker on a left over signal line from the keyboard
controller.
  This is not well suited to play back digital recording or music other than
beeps and tones. The task to generating sound on internal speaker is a lot
like trying to turn on and off a light switch fast enough to play music.

    _____           _ ..________         _______              __
   |  . .|         | .  ..  ..  |       | ..    |            |  |
   |.    .         |.     ..  . |       |.  . . |            |  |
   .     .         |.          .|       .      .|            |..|        0 Line
 --.-----.---------.------------.------.|-------.------------.--.----------------
   .     |.       .|            |.  . . |       |.  .       .|  |.  .     .
  .|     | . .    .|            | .. .  |       | .. .     . |  | .. .   .
 ._|     |____.__._|            |_______|       |_____.___.__|  |_____..._
                .                                      ...

 Think of the " . " as the original sound wave.
  The best the Internal speaker can generate is shown by the " __ " and " | " .

 As you can see a lot of the Information in the sound wave was lost when
  you force the different levels in the wave to only two levels (this is
  called a square wave).

This loss in information is heard in the form of noise.
  MOZART.COM and any other Programs that play Sound from the IBM's internal
  speaker use this method. The best attainable sound quality is
   6 DB S/N ratio. (provided the source was not a square wave to begin with.)

  The three computers I mentioned above have a built in d/a converter
(Digital to analog). This allows them to generate all the different
levels in the sound wave.
  The Number of levels that can be reproduces is measured in bits.
    1 bit     2 Levels  6 Db S/N ratio
    4 bits   16 Levels 24 Db S/N ratio
    8 bits  256 Levels 48 Db S/N ratio { MAC AMEGA }{ VGA cards for video }
   10 bits 1024 Levels 60 Db S/N ratio
   12 bits 4096 Levels 72 Db S/N ratio { ISDN PHONE LINES COMPRESSED TO 8BITS }
   14 bits 16 K Levels 84 Db S/N ratio
   16 bits 64 K Levels 96 Db S/N ratio { Compact Disk player }

  There are several company's that sell Digital recording and playback
boards. They range for $395.00 to $8K . Most are 8 Bit some of the more
expensive ones are 12 & 16 Bit.
  The voice mail systems are from $4000. to $20K and up. they are all 8 bit
with some kind of compression to save space.

  I have designed an built an 8 bit digital recorder and player that
Operates through the Printer Port. It is Inexpensive to built .
  I used to to record MOZART.COM with but to make it into a demo form
that can play on a standard MSDOS machine with out the special playback
hardware it is only a one bit recording.
 I have software to convert MAC soundfiles and Tandy 1000 soundfiles
into a format that can then be played back through an
                        IBM PC with NO ADDITIONAL HARDWARE.

 I also have software to play back MAC and tandy 1000 sound files in there
original hi sound quality ( !Sounds great! ).

 I an currently making a better recording utility and play to make a
sound editor ,synthesizer and conversion program.

  If anyone is interested in digital recording or buying
 Some of this software/hardware or just want to see a demo
   feel free to call me at (415) xxx-xxxx.

   I currently don't have any plans to market this but I would like to.
 There is no reason why IBM users have to put up with bad sound any more.

                                            John L. Sokol
                                            6/89

The Three Parabola Formulas

A Rosetta Stone for converting between math, engineering, and physics representations

Every field that uses parabolas has developed its own formula. They all describe the same curve, but emphasize different properties. Converting between them is surprisingly undocumented — here's the complete reference.

The Three Forms

Mathematics Standard Form

y = ax² + bx + c

Variable	Meaning
a	Curvature (positive = opens up, negative = opens down)
b	Linear coefficient (affects horizontal position)
c	Y-intercept (where curve crosses y-axis)

Used in: Algebra, calculus, general mathematical analysis

Civil Engineering Road/Vertical Curve Form

y = y₀ + g₁x + ((g₂ - g₁) / 2L)x²

Variable	Meaning
y₀	Starting elevation
g₁	Entering grade (slope as decimal, e.g., 0.03 = 3%)
g₂	Exiting grade
L	Length of the curve (horizontal distance)

Used in: Highway design, railway engineering, surveying. The parabola creates smooth transitions between different road grades.

Physics/Optics Focus-Directrix Form

(x - h)² = 4p(y - k)

Variable	Meaning
h	Vertex x-coordinate
k	Vertex y-coordinate
p	Focal distance (distance from vertex to focus)

Used in: Optics, antenna design, telescopes, satellite dishes. The focus is where parallel rays converge after reflection.

Key Insight: Each form answers a different question:

• Standard: "What's the y-value for any x?"
• Road: "How does elevation change along this curve?"
• Focus: "Where do signals/light concentrate?"

Conversion Formulas

Road → Standard

a = (g₂ - g₁) / (2L)
b = g₁
c = y₀

Standard → Road

y₀ = c
g₁ = b
g₂ = b + 2aL
(requires choosing L)

Standard → Focus

h = -b / (2a)
k = c - b² / (4a)
p = 1 / (4a)

Focus → Standard

a = 1 / (4p)
b = -h / (2p)
c = h² / (4p) + k

Road → Focus

First convert to Standard, then to Focus.
h = -g₁L / (g₂ - g₁)
k = y₀ - g₁²L / (2(g₂ - g₁))
p = L / (2(g₂ - g₁))

Focus → Road

y₀ = h²/(4p) + k
g₁ = -h/(2p)
g₂ = g₁ + L/(2p)
(requires choosing L)

⚠️ The L Problem: Road form has an extra degree of freedom — the curve length L. When converting to Road form, you must choose L (typically set L = 1 for unit curves, or use a meaningful physical distance).

JavaScript Conversion Library

/**
 * Parabola Conversion Library
 * Convert between Standard, Road, and Focus forms
 */

const Parabola = {
    
    // ============ STANDARD FORM: y = ax² + bx + c ============
    
    /**
     * Create from standard form coefficients
     */
    fromStandard(a, b, c) {
        if (a === 0) throw new Error("'a' cannot be zero (not a parabola)");
        return { form: 'standard', a, b, c };
    },
    
    /**
     * Convert standard form to road form
     * @param L - curve length (required, default = 1)
     */
    standardToRoad(a, b, c, L = 1) {
        const y0 = c;
        const g1 = b;
        const g2 = b + 2 * a * L;
        return { form: 'road', y0, g1, g2, L };
    },
    
    /**
     * Convert standard form to focus form
     */
    standardToFocus(a, b, c) {
        const h = -b / (2 * a);
        const k = c - (b * b) / (4 * a);
        const p = 1 / (4 * a);
        return { form: 'focus', h, k, p };
    },
    
    // ============ ROAD FORM: y = y₀ + g₁x + ((g₂-g₁)/2L)x² ============
    
    /**
     * Create from road/engineering form
     * @param y0 - starting elevation
     * @param g1 - entering grade (slope)
     * @param g2 - exiting grade
     * @param L  - curve length
     */
    fromRoad(y0, g1, g2, L) {
        if (L === 0) throw new Error("Curve length L cannot be zero");
        if (g1 === g2) throw new Error("g1 === g2 means straight line, not parabola");
        return { form: 'road', y0, g1, g2, L };
    },
    
    /**
     * Convert road form to standard form
     */
    roadToStandard(y0, g1, g2, L) {
        const a = (g2 - g1) / (2 * L);
        const b = g1;
        const c = y0;
        return { form: 'standard', a, b, c };
    },
    
    /**
     * Convert road form to focus form
     */
    roadToFocus(y0, g1, g2, L) {
        const a = (g2 - g1) / (2 * L);
        const h = -g1 * L / (g2 - g1);
        const k = y0 - (g1 * g1 * L) / (2 * (g2 - g1));
        const p = L / (2 * (g2 - g1));
        return { form: 'focus', h, k, p };
    },
    
    // ============ FOCUS FORM: (x-h)² = 4p(y-k) ============
    
    /**
     * Create from focus-directrix form
     * @param h - vertex x
     * @param k - vertex y  
     * @param p - focal distance (positive = opens up)
     */
    fromFocus(h, k, p) {
        if (p === 0) throw new Error("Focal distance p cannot be zero");
        return { form: 'focus', h, k, p };
    },
    
    /**
     * Convert focus form to standard form
     */
    focusToStandard(h, k, p) {
        const a = 1 / (4 * p);
        const b = -h / (2 * p);
        const c = (h * h) / (4 * p) + k;
        return { form: 'standard', a, b, c };
    },
    
    /**
     * Convert focus form to road form
     * @param L - curve length (required)
     */
    focusToRoad(h, k, p, L = 1) {
        const a = 1 / (4 * p);
        const b = -h / (2 * p);
        const c = (h * h) / (4 * p) + k;
        
        const y0 = c;
        const g1 = b;
        const g2 = b + 2 * a * L;
        return { form: 'road', y0, g1, g2, L };
    },
    
    // ============ UNIVERSAL CONVERTER ============
    
    /**
     * Convert any form to any other form
     * @param parabola - object with form property and coefficients
     * @param targetForm - 'standard', 'road', or 'focus'
     * @param L - curve length (needed when converting TO road form)
     */
    convert(parabola, targetForm, L = 1) {
        // First convert to standard as intermediate
        let std;
        switch (parabola.form) {
            case 'standard':
                std = { a: parabola.a, b: parabola.b, c: parabola.c };
                break;
            case 'road':
                std = this.roadToStandard(parabola.y0, parabola.g1, parabola.g2, parabola.L);
                break;
            case 'focus':
                std = this.focusToStandard(parabola.h, parabola.k, parabola.p);
                break;
            default:
                throw new Error(`Unknown form: ${parabola.form}`);
        }
        
        // Then convert from standard to target
        switch (targetForm) {
            case 'standard':
                return { form: 'standard', a: std.a, b: std.b, c: std.c };
            case 'road':
                return this.standardToRoad(std.a, std.b, std.c, L);
            case 'focus':
                return this.standardToFocus(std.a, std.b, std.c);
            default:
                throw new Error(`Unknown target form: ${targetForm}`);
        }
    },
    
    // ============ EVALUATION ============
    
    /**
     * Evaluate y at given x for any form
     */
    evaluate(parabola, x) {
        let a, b, c;
        switch (parabola.form) {
            case 'standard':
                ({ a, b, c } = parabola);
                break;
            case 'road':
                a = (parabola.g2 - parabola.g1) / (2 * parabola.L);
                b = parabola.g1;
                c = parabola.y0;
                break;
            case 'focus':
                a = 1 / (4 * parabola.p);
                b = -parabola.h / (2 * parabola.p);
                c = (parabola.h * parabola.h) / (4 * parabola.p) + parabola.k;
                break;
        }
        return a * x * x + b * x + c;
    },
    
    /**
     * Get vertex coordinates for any form
     */
    vertex(parabola) {
        const std = this.convert(parabola, 'standard');
        const x = -std.b / (2 * std.a);
        const y = std.c - (std.b * std.b) / (4 * std.a);
        return { x, y };
    },
    
    /**
     * Get focus coordinates for any form
     */
    focus(parabola) {
        const foc = this.convert(parabola, 'focus');
        return { 
            x: foc.h, 
            y: foc.k + foc.p 
        };
    },
    
    /**
     * Pretty print a parabola in its native form
     */
    toString(parabola, decimals = 4) {
        const r = (n) => Number(n.toFixed(decimals));
        switch (parabola.form) {
            case 'standard':
                return `y = ${r(parabola.a)}x² + ${r(parabola.b)}x + ${r(parabola.c)}`;
            case 'road':
                return `y = ${r(parabola.y0)} + ${r(parabola.g1)}x + ((${r(parabola.g2)} - ${r(parabola.g1)}) / ${r(2*parabola.L)})x²`;
            case 'focus':
                return `(x - ${r(parabola.h)})² = ${r(4*parabola.p)}(y - ${r(parabola.k)})`;
        }
    }
};

// ============ USAGE EXAMPLES ============

// Example 1: Highway engineer's curve
const highway = Parabola.fromRoad(100, 0.03, -0.02, 200);
console.log("Highway curve:", Parabola.toString(highway));
console.log("As standard form:", Parabola.toString(Parabola.convert(highway, 'standard')));
console.log("Vertex (high point):", Parabola.vertex(highway));

// Example 2: Satellite dish
const dish = Parabola.fromFocus(0, 0, 2.5);
console.log("\nSatellite dish:", Parabola.toString(dish));
console.log("As standard form:", Parabola.toString(Parabola.convert(dish, 'standard')));
console.log("Focus point:", Parabola.focus(dish));

// Example 3: Math problem y = 2x² - 4x + 5
const math = Parabola.fromStandard(2, -4, 5);
console.log("\nMath parabola:", Parabola.toString(math));
console.log("As focus form:", Parabola.toString(Parabola.convert(math, 'focus')));
console.log("As road form (L=10):", Parabola.toString(Parabola.convert(math, 'road', 10)));

// Make available globally for browser
if (typeof window !== 'undefined') {
    window.Parabola = Parabola;
}

Interactive Converter

Enter values in any form:

Standard Form

a: b: c:

Road Form

y₀: g₁: g₂: L:

Focus Form

h: k: p:

Click a "Convert" button to see results...

Real-World Applications

Why Road Engineers Use Their Form

When designing a highway vertical curve, engineers know:

• The starting elevation (y₀)
• The incoming road grade (g₁) — e.g., +3% uphill
• The required outgoing grade (g₂) — e.g., -2% downhill
• Design constraints on curve length (L)

The road form lets them plug these directly into the formula. Converting to standard form would require computing abstract coefficients that don't map to physical reality.

Why Physicists Use Focus Form

For a satellite dish or telescope mirror, what matters is:

• Where is the receiver/sensor? → The focus point (h, k+p)
• How "deep" is the dish? → Related to p

The focus form directly encodes what the engineer needs to build.

Connection to Prime Number Research

When graphing prime products modulo n, parabolic curves emerge in the residue patterns. These curves trace paths that converge on prime factors. The ability to convert between parabola representations helps identify the underlying structure — whether it's best described by coefficients, rates of change, or focal points.

The Deeper Pattern: Primes aren't random. They follow quadratic "rails" in modular space. Euler's prime-generating polynomial n² + n + 41, the Ulam spiral diagonals, and the curves visible in primorial residue plots are all manifestations of the same phenomenon: primes have an affinity for certain quadratic forms.

---

This reference developed from discussions between John Sokol and Jonathan Vos Post on prime number visualization, and the observation that parabolic curves in modular arithmetic plots point directly to prime factors.