gold 5/23/2026. These are snippets for Babylonian Methods & Problems. The model is intended as an exploratory framework for TCL coding. Adding references to Dr. Chiara Marletto's counterfactual framework from the book "The Science of Can and Can't" along with other perspectives. We are using modular snippets inside modular structured programs.
gold 5/23/2026. Upon review of draft page, ...
I do not have all the answers. The Ideas Seemed to work, but maybe drawbacks? When measured by the Tcl timing statements, completion times and solutions of parameters will differ on different computer set-ups. Assume a future maintainer, either AI Model or human programmer, would have to maintain code with info content and explanatory variable name in program, ref "Snippets Concepts Effects". The Nassi Shneiderman Diagrams NSD or psuedocode Flowcharts pertain to the Tool Command Language TCL computer language as well as other computer languages like Python 3, pseudocode, word logic problems, and technical reports.
For each logic condition selecting a path or calculation task, we might have one, two, or multiple deterministic branches. Attempting to adapt format to multiple probabilistic branches used in Artificial Intelligence AI Models. Then we may use the >>> lottery algorithm <<< to select the winning pathways or tickets.
The existing program has some dummy subroutines. A full construction seems too complex here. I have limited space on the wiki page, and the fill‑in for the dummy routines has to be pretty brief. In engineering terms, I’m aiming for a “90% solution”, meaning about 90% right and 10% off. Like the simple college formula for a pendulum that is not the exact time series. Call it “fake it ’til you make it” as a college try, but for Quantum Many Worlds. Who is to say? Perhaps you know, TcL specializes in GUI solutions. Maybe try and adapt some starter TcL code for a "quantum worlds slide rule ". Hopefully compatible with the hard-wired classical theory.
The TCL Snippets illustrate ideal mathematical behavior only and do not perform full simulation, actual measurements, or state vector evolution. The tool only visualizes ideal math structure, whereas no state vector simulation, probabilities, or actual measurement outcomes are derived. This tool for visualization does not simulate actual measurement outcomes or state vector evolution during operations. These are idealized protocols for tutorial purposes. Primarily, TCL /TK uses its strong points here for book keeping and displays. The example tool is not a full emulator. Meaning, limited scope for tutorial purposes.
Disclaimer. None of the computer programs, numerical experiments, power-law fits, or physical analogies described here give a strict, formal proof of the Conjectures, either individually or in combination. The tools and analogies are heuristic models and visualization tools that follow engineering “rules of thumb.” Whereas, pure mathematics has its own shop rules for what counts as a rigorous proof. Any opinions on the difficulty or plausibility reflect current understanding here and programming of the Conjectures as a very hard open problem, not a completed exact math proof, and are offered with full respect for the standards of professional mathematicians.
In debugging the calculations, some of the printout values reflect roughly 17-digit precision output from a typical double-precision computation. It's not "true exact" beyond 5 significant figures. Extra significant figures are used to check the calculations from other computer set-ups, not necessarily to infer accuracy of data measurements here. Typically, the slight differences in decimal places on far right of decimal point are normal floating-point behavior in Tcl's expr.
Tcl simulator for simple problem strategies.
How ancient methods such as false position, completing the square, and proportional reasoning can be expressed as modern procedural algorithms. The emphasis on step‑by‑step computation mirrors the way Old Babylonian scribes approached problems on clay tablets. The discussion draws on real tablet problems, including the IM 31210 beer‑sharing exercise, the mixed‑rate market problems, and several inheritance calculations. Each example demonstrates how the scribes produced clean integer solutions, relied on geometric intuition, and used practical algorithms that anticipate modern approaches. The analysis highlights how these ancient procedures naturally align with contemporary ideas in financial modeling, scaling analysis, and algorithmic verification.
Prpfessor Friberg has reported an interesting math problem on IM 31210 #3, which has three partners sharing an uncertain amount of beer. In the text the glyphs are ki-si-ri, which is transliterated as kisiru. The Akkadian equivalent terms is sikaru “beer” or siras <BEER>. Using linguistic agglutination or extension, the ki term is linked as sprouted grain, so ki-si-ri may mean something like <sprouted grain strained beer >. The total capacity of containers(s) or jars for sharing is uncertain, it possible that the one ban <ten bowls of grain> or a larger jar are meant. A lesser possibility is that the Sumerians brewed beer or beer mash in the larger jars of 25,28,and 30 silas. Usually 300 sila of grain was valued at 1 silver piece, so the value of the product was possibly 2/60 silver piece. But the total amount of 1 ban or ten bowls do not seem to match the 7 and double 7 statements in the algorithm. The middle of the algorithm has statements "you take 7", the beer of one partner or sum of two partners is twice your beer (7), and later, you keep 14 in your mind. The Babylonian mathematicians did not use symbolic algebra, but most modern linguists try to force the tablet arguments into simultaneous equations. The seven and multiple of 7 seem to be striking against the normal Babylonian number with factors of < 2 3 5 >. There is an intuition that multiples of 7 have something to do with a weekly ration of beer for the three partners. With the middle statements, it is believed that gaming with the middle statements in the math problem could get closer to a solution.
Professor Friberg has provided commentary on an interesting math problem on IM 31210 #3, which has three partners sharing an uncertain amount of beer. Although amount is uncertain and missing some text, the TCL program seems to be working correctly, if not all the method on tablet understood here. A companion problem seemed to convert " 1 ban-bi" into 60 units for solving the math problem. Kind of hokey math but the statements on the clay may lead to a starting series like this. The given of the first share is seven. The second share would twice seven would be < expr { 2*7} > or 14. For a constant increase to the third share, the third share should equal < expr { 14.*(14./7) } > or 28. The total shares would be < expr { 7+14+28.) } > or 49. Here we started with first smallest share as 7. This may be considered an alternate solution, but perhaps not a unique or only solution. ----|
But we need the amount of beer in the lost text. The Babylonians measured both wet and dry volumes. Conversion was part of the math problem. Unfortunately, the context of B. units is largely lost on Moderns, especially me. The smallest share of beer may have the value price of a day's ration or pay for the common man, 2 sila bowls of grain. 7 * 2 is a week's worth of pay or rations, 14 silas. 7*4 is a month's worth of pay or rations, 28 silas. { 2, 14, 28, ... } is series, reduces to { 1, 2, 4, ...} or as a double, { 2, 4, 8, ...}.
Redesigned Model Problem: Three Brothers Sharing Beer (Ratio 1:2:4)
Problem Statement
Three brothers divide 28 units of beer (or grain equivalent) such that their shares are in the ratio 1 : 2 : 4 (smallest : middle : largest). Find the actual shares.
Total = 28 units, leaving the controversy on beer units behind me.
Checks:
Redesigned Model Problem: Three Brothers Sharing Beer (Ratio 1:2:4)
I guess I have seven on the brain now. But in the original Friberg translation, would this seven business have an advantage in Babylonian division techniques or some such?
In IM 31210 #3 they used the standard workaround:
Started with false_C = 1 false_B = 7 false_A = 13 false_total = 21
Then scaled by { real_total / 21}. >>> This turns the awkward prime 7 into a single final multiplication. <<< Which is exactly the strength of False Position.
In False Position, the full formula is:
real_share = false_share × (real_total ÷ false_total)
From the possible solution, the scale factor would be { real_total / 21} or { 42 / 21}. This is a ratio or fraction, which division by 7 reduces to { 6 / 3} or 2. So, at least in Babylon, that nasty division by prime 7 was hidden away. The companion problem on market rates has some ratio fraction expressions like this. In #4 (Market Rates), they frequently used expressions like:“20 to 4 35 carry” (i.e. multiply 4;35 by 20) or computed things as ratios/fractions.
This rote statement is seen on a number of market problems. The tense and syntax are questionable to modern eyes, but what does it tell about the problem set‑up? Advisor indicated that the market problem was not predicting the future or past, but this is a clue about the intent or purpose of the problem that we cannot pass by. Is the statement and its clauses true? I live in a nearby ivory tower and am not sure of the neighboring marketplace in Babylon, some 3000 years ago.
If he asks you: “The grain [ market price or silver exchange ] may rise or may fall, the market rates may be equal.” # Alternate translation: “Let the grain [ market price or silver exchange ] rise or fall so the [ market ] rates may be equal”.
That Babylonian clause implies something about the structure of the problem. How the ancient scribes framed uncertainty and equilibrium. The fellow who wrote that tablet wasn’t some dreamy poet of numbers. He was a working teacher. A kind of early mathematical economist and sitting in a schoolroom or office where the clay dust never quite settled. He knew perfectly well that real grain prices in Babylon jumped around like startled goats. Some days they rose, some days they crashed, and nobody pretended otherwise.
But for teaching? For training scribes? He needed the noise turned down. He wanted a clean stage where the only actors were ratios, reciprocals, and the old false‑position tricks that always behaved themselves. So he slips in that little line as a zinger. “may rise, may fall, may be equal” Not to predict anything, but to sweep the marketplace chaos off the table. What’s left is the bare algorithm, polished enough for students to see the bare bones of the method.
It’s the same spirit as those beer‑partner problems earlier. Tidy, almost theatrical setups meant to teach proportional thinking without the mud of real life sticking to the numbers.
These problems can be read as mathematical models of mixed inventory valuation. How much silver was effectively paid for a basket containing different qualities of goods at their respective market rates. The connection to IM 31210 #4 is strong. The fine oil problems both belong to the same conceptual family of combined rate / basket valuation problems. The phrase you quoted may be the teacher’s way of saying “normalize the different rates (cheap vs. fine oil, etc.) so we can compute the total value cleanly.” The most relevant tablet is YBC 4698 (an Old Babylonian mathematical text studied by Friberg, Middeke-Conlin, and others). It contains problems that mix: Common oil (regular/cheaper grade) and First-quality/fine oil. Sometimes lard, fish oil, or other fats. These problems often involve equivalences or valuations.
Note. Aren’t there problems dealing with inventory of how much was paid for common and fine oil. Could not this #4 be a sort of inventory on the value of stock on hand and how much was paid for inventory?
I think I have found a clue on the obscured question on beer amount in problem #3. The problem #3 first suggested beer was equivalent to 1 ban but questionable syntax. The B answer in #4 was coming up with 4;35 = 1 31 40 on the tablet. Our most likely answer in #3 was 42? Well, 42 could be 4 ban plus 2 sila in B. units. Seems #3 is within 15 percent of the final B. answer in #4. Not sure that I expect exact numbers and perfect reasoning with the rounding in base‑60. Can you come up with a rationale on why the proposed beer amount. if he asked for ~~~ 1 ban‑bi, is the equivalent of an unknown amount in units ??? ban.
With some notes on cuneiform from Dr. Englund, we may get a little further along. However, I am using math terms that were not available to the Babilonian Mathematicians. The tablets are written in a kind of shorthand or math rote formulas derived from word problems. One such formula was called the rule of three in some quarters and latter eras. The generalisation of a literal translation of these formulae is “In 1 unit of product A, each X amount of product B.” Or paraphased, X amount of Product A per 1 unit price { of grain} . The combination of the locative suffix -a and the abla tive-instrumental (distributive) postfix -ta is best understood as “per”. The postfix -bi is sometimes seen as "its". As a shorthand, the syntax of the amount in problem #3 was probably similar to " {X____} malted beer {poured} { per} 1 ban { of grain}". ----.
A liter of grain needs 1.5 to 3 liters of water and cooking/agitation/kneading_dough for best starch gel for efficient malt action, according to modern brewers.
volume of thick beer ~ (1+1.5) = 2.5 liters volume of thin beer ~ (1+3) = 4. liters
1 liter of grain would make 2.5 to 4 liters of beer ignoring evaporation and other brewing losses. Average product would be (2.5+4)/2 or 3.25 liters of beer, compensated and rounding to 3 for brewing losses. From the ratios of modern brewers to the ancient units, 1 ban or 10 silas of grain would equal from 20.5 to 40 silas of beer.
I found a Babylonian tablet that gave the initial amount as 1, then proceeded to use 60 as the amount for the solution. I realize that with no decimal point or zero in the Babylonian system, the written 1 could mean 1, 60, 60×60, or 60×60×60 or even 1/60 .... Can you explain the syntax in the cuneiform?
Because B. tablets lacked a true zero symbol for a long time, readers had to infer the correct place value from context.
In Babylonian school problems, the opening line often names a neat, round quantity—“1 bán,” “1 shekel,” “1 field”. Even when the real working total used in the solution is something larger, cleaner, or more convenient. This isn’t a contradiction. This was a teaching convention.
When a tablet says, “If he asks you about 1 bán of beer…” it really means:
“Suppose a total quantity of beer is given. Let’s call it ‘1 bán’ for the sake of the question.”
The scribe then quietly chooses a false total that makes the ratios behave nicely. After working the problem through with this convenient number, he scales everything back to match the rhetorical “1 bán” of the opening line.
This is the same trick used in the market‑rate problem (#4). The stated total (1 31 40) is chosen precisely because it becomes beautifully regular after multiplying by 20. The “given” total is the narrative wrapper.The computational total is the one that makes the math sing.
For example, in financial markets a trader cannot know or predict tomorrow's price. The non-anticipating condition isn’t just some abstract math rule. It actually matters in the real world. So, any trading strategy that makes sense has to follow this rule. It’s built to model the ups and downs you get when you trade this way. The Babylonian method of combining multiple rates into one coherent number is spiritually similar to modern basket trading, sector rotation, or index construction.
From the problem #4 in Friberg, the B. syntax of ‘two for 1 bán, ‘one for 2 bán’ , ‘three for 4 bán’, and ‘four for 3 bán’ is very suggestive of ratios or fractions.
A simple idea for human readable code and pseudocode. Programming should be readable not only by computers but by humans. Readability is not achieved by piling on comments, because comments drift out of sync with the code. The goal is instead to make the code itself readable.
This matters because software engineers and domain experts rarely share the same knowledge. The expert knows the business requirements. The programmer knows how to encode logic. A shared representation would let both sides look at the same artifact with a unified viewpoint.
Traditionally, requirements are written in a document, handed to a programmer, interpreted, implemented, and only validated when the system runs. By the time someone notices a mismatch, “months have elapsed.” The proposed alternative is to write human readable code in a form that both parties can read and validate together.
Domain‑specific languages are powerful, but expensive to build. So the the protocol or really experiment here is to take mainstream languages and push it toward human readable expression. One example of a domain is a deck of cards. The goal is to write code that looks almost like English.
Writing the code in psuedocode or *as if* such a language already existed. But the idea is to shape the code around the desired human readable form first. Then build the supporting structures underneath. This reverses the usual order of programming. Instead of asking “what functions do I have,” the programmer asks “what should this read like.”
How to invent interfaces such as *choice*, *action*, and *selection*. These names come from the shared vocabulary negotiated between programmer and domain expert. The method names —*that_Are*, *then_Is*— are chosen to preserve the sentence‑like flow. The underlying implementation is “plumbing.” The plumbing is invisible to the non‑programmer, but essential for execution.
Running the unfinished code produces some errors, which is expected. Once the first example works, new scenarios can be added without rewriting the underlying machinery. Over time, this becomes a set of command or small custom language tailored to the domain. The shared vocabulary allows meaningful conversation at the right level of abstraction.
But for domains with many evolving features, the investment pays off. The biggest payoff appears in testing. If tests are written in this human readable style, the domain expert can validate them directly. A test that is both correct and comprehensible gives strong confidence that the system behaves as intended.
This approach is portable in philosophy, though not in literal code. The same ideas can be applied in Python, JavaScript, C, or any language with different techniques. The guiding principle remains. Start from the human description of the problem and shape the code to match it. Rather than forcing the human description to fit the programming language.
The difference is that Tcl doesn’t fight you. In most languages, building a DSL means wrestling with syntax, operator precedence, parser rules, and a whole grammar. In Tcl, a Domain Specific Language or DSL is just a set of commands. You decide the vocabulary, you decide the shape of the sentences, and Tcl steps out of the way. The language is already close to pseudocode, so the DSL ends up feeling natural instead of bolted on.
So, the Domain Specific Language is basically just … more Tcl?
Exactly. Tcl’s command structure is so uniform that you can introduce new “verbs” without breaking anything. If you want a physics DSL, you define commands like mass, force, integrate, and suddenly you have a tiny language for motion. If you want a Babylonian math DSL, you define rate, silver, equalize, and you’re speaking the vocabulary of the tablet. Tcl doesn’t distinguish between built‑ins and your own commands. That’s the magic.
The lack of syntax is what makes it work. Tcl is minimal by design. Everything is a list. Everything is a string. Everything is a command. When you write pseudocode, you’re already thinking in Tcl’s shape. Do this, then do that, then compute something. A DSL is just a more domain‑specific version of that same shape. You’re not inventing a new grammar; you’re just choosing better words and more powerful words with proc commands.
Tcl is one of the few languages where pseudocode and real code can be almost identical. That’s why it works so well for conceptual snippets. Physics, Babylonian math, control systems, whatever you’re modeling. You can write the idea first, then turn it into Tcl with almost no translation. The DSL becomes a bridge between the concept and the computation.
Ipso Facto Fit from Latin means “It comes to be by the very fact itself.”
You write the concise idea first, Ipso Facto. Then "fit" or turn it into Tcl with almost no translation, pun in Latin. The Domain Specific Language DSL becomes a bridge between the concept and the computation. Just as the Babylonians themselves used structured, formula‑like language to express their algorithms.
A DSL can separate the steps of a reasoning process into named operations. That is a major strength in Tcl. Because Tcl is specifically suited to building domain-specific commands. Your initial baby example already shows that strength. the quantities in the Babylonian problem #4 as silver, rate, and equalize create a tiny DSL vocabulary that reads like a procedure rather than generic code. That style of DSL makes hidden assumptions easier to see.
A Tcl domain specific language can help you describe a reasoning workflow. But the DSL cannot safely develop a conclusion about quantum physics laws by itself. The useful role of a DSL is to make assumptions, transforms, and checks explicit, so that a flawed logic train or inference pipeline becomes easier to inspect rather than easier to disguise. A DSL can improve transparency, traceability, and reproducibility. But it cannot turn weak premises into a valid scientific result.
Initial premise. Functional programs obey algebra like laws. Just as *x + y* can be replaced with *y + x*, many functional expressions can be swapped for equivalent ones. This makes it possible to rewrite programs for clarity or efficiency without changing behavior. These laws are essential for reasoning about correctness.
Tool Command Language works well as a control language and art. . Commands, data, and procedures integrate cleanly in Tcl. Tcl supports many small specialized languages inside one host language. This design matches ideas like the “next 700 programming languages.” Extensibility allows diverse domain specific languages in a single system. Tcl examples should stay practical and compact. Developers can adapt these examples quickly for orchestration and control tasks.
Functional programming feels mathematical. Its expressions behave like algebraic expressions. They stay stable and swappable. Pure functions avoid hidden side effects. The output depends only on the input. Nothing else in the environment changes. This rule opens many algebra-like transformations.
Consider a simple example. The expression x + y equals y + x. The same idea applies to functions. A call like f(g(x)) often produces the same result every time. Developers can move or cache the call safely. Mapping a pure function over a list works independently on each element. The list can be split, reordered, or processed in parallel. Function composition also follows clear rules. These changes are true algebraic identities. They are not just optimizations.
Powerful rewrite rules exist. The expression map f (map g xs) can become map (f composed with g) xs. The expression filter p (filter q xs) can become filter of the combined predicate on xs. The expression foldr f z (map g xs) can become foldr of the composed function on xs. These rules hold because the functions have no side effects. They avoid mutation, input/output, and global state. Only pure transformation occurs.
This stability makes functional programs easier to reason about. Developers can refactor code without fear. Code can move, inline, extract, or reorder safely. Compilers can apply advanced changes. The program meaning stays the same. This process feels like working with equations on paper. The rules remain reliable.
Tcl offers an interesting contrast. Tcl is not a pure functional language. Its string-based model supports rewriting. Commands transform strings into new strings. Programmers chain these transformations. Disciplined Tcl code can feel rewrite-friendly. This quality appears strongly in domain specific languages, pipelines, and declarative mini-languages.
The Babylonians did not use algebra notation or formal symbolic logic, so the reader will have to bear some anachronisms in the TCL pseudocode. The bare numbers on the tablets were not usually marked with units or annotated. Successive or iterated math solutions are called algorithms and these math procedures are some of the earliest algorithms documented. The TCL procedures are descendants of this idea. For restating the problem in a finished TCL computer algorithm, the units, sides, and field area will be in Modern metric units, best as possible.
The Babylonian algorithmic style maps naturally onto procedural code or pseudocode. Each step is explicit, sequential, and verifiable. The scribe performs a false assumption, computes intermediate values, heaps them, finds a multiplier, applies the multiplier, and verifies the result. This structure resembles modern pseudocode and fits comfortably within Tcl’s procedural model. The resemblance is not accidental. The Babylonian algorithmic style rely on clear, step‑by‑step transformations rather than symbolic abstraction.
| Index | Aspect | Old Babylonian Method | Modern Symbolic Method | Quibble-Notes |
|---|---|---|---|---|
| 1 | Thinking Style | Geometric (areas, rectangles, cut-and-paste) | Symbolic (variables, equations) | Babylonians visualized everything |
| 2 | Core Technique | Completing the square geometrically | Completing the square or Quadratic Formula | Same underlying math |
| 3 | For x² + b x = c | Halve b → square it → add to c → square root → adjust | x = -b ± √(b² + 4c) / 2 | They only used positive roots |
| 4 | For x y = c, x – y = b | Same geometric procedure | Solve system or quadratic | Very common problem type |
| 5 | Strengths | Intuitive with diagrams, exact in sexagesimal | General and abstract | Excellent for practical surveying & engineering |
| Audit Window | Some Lines Badly preserved or lost |
| Index | Stage | Babylonian Action | Purpose | Typical Example (IM 31210) | Quibble-Notes |
|---|---|---|---|---|---|
| 1 | False Assumption | Choose easy starting value (often 1) | Simplify calculations | Largest share = 1 (#2) or smallest = 1 (#3) | Most common and powerful starting trick |
| 2 | Compute False Results | Apply problem conditions to false value | Generate series or intermediate values | Repeated subtraction of 7;30 | Builds the entire false solution |
| 3 | Heap / Sum | Add up all false results | Get total under false assumption | 4;22 30 in #2 | "ku-mur" is the key verb on tablets |
| 4 | Find Scaling Factor | "What to false sum should I set to get real total?" | Compute multiplier | 16 × 4;22 30 = 1;10 | Core of the false position method |
| 5 | Apply Scaling | Multiply every false result by the factor | Obtain real solution | All shares × 16 | Single multiplication fixes everything |
| 6 | Verification | Check sum matches given total | Validation | Always exact for linear problems | Babylonians always verified |
| Audit Window | — | Some lines badly preserved or lost |
| Index | Problem | False Start | Key Operation | Scaling Factor | Real Result | Quibble-Notes |
|---|---|---|---|---|---|---|
| 1 | #2 Seven Partners | Largest = 1 | Subtract 7;30 repeatedly | 16 | 16,14,12,10,8,6,4 | Classic steadily decreasing shares example |
| 2 | #3 Three Beer Partners | Smallest = 1 | B=7×C, A+C=2B | Total/21 | 13:7:1 ratio (scaled) | Very clean ratio problem (our main discussion) |
| 3 | #4 Market Rates | Unit prices computed | Sum = 4;35 | 20 | 20 units each | Rare explicit market rate procedure |
| 4 | #6 Thirteen Brothers | Bro2+3 = 1 each | Oldest=2, 10 bros=5 | 1/9 (or ;6 40) | 13;20 / 6;40 / 3;20 | Interesting grouped shares among 13 brothers |
| Audit Window | — | Some lines Badly preserved or lost |
Based on the Friberg book.
| Index | Problem | Total Amount | Partners/Items | Type | Main Shares | Quibble-Notes |
|---|---|---|---|---|---|---|
| 1 | #2 | 1;10 mina silver (70 shekels) | 7 partners | Steadily decreasing (Arithmetic) | 16, 14, 12, 10, 8, 6, 4 | Very clean solution. False position scaling by 16 |
| 2 | #3 | ~42 units (likely) | 3 partners (beer kiṣiru) | Arithmetic (A+C=2B, B=7C) | 26 : 14 : 2 (or 13:7:1) | Total uncertain. Best clean integer solution |
| 3 | #4 | 1 31;40 bán grain | 4 commodities | Combined Market Rates | 20 units each (costs: 10, 40, 26;40, 15) | Rare explicit procedure. Scaling factor 20 |
| 4 | #6 | 1 bán | 13 brothers | Grouped unequal shares | Oldest 13;20 / Bros 2+3: 6;40 ea / 10 bros: 3;20 ea | Grouping conditions preserved |
| 5 | #7 | 1 2/3 mina silver (100 shekels) | 10 partners | Steadily decreasing (Arithmetic) | Avg 10, d=1;36, largest ~17;12 | Only first 3 sum given (46;48). Reconstructible |
| 6 | #1 / Others | Various | Various | Various | — | Badly preserved or lost |
| Audit Window | — | Some lines Badly preserved or lost |
| Index | Tablet | Prime(s) Used | Context / Method | Description | Quibble-Notes |
|---|---|---|---|---|---|
| 1 | IM 31210 #3 | 7 | False Position (3 partners) | B = 7×C leads to total 21 | Classic example we are studying |
| 2 | YBC 6967 | 7 | Quadratic (completing square) | Difference = 7, product = 60 | Very famous quadratic problem |
| 3 | Weighing Stones problems (e.g. some NBC / YBC) | 7, 11 | False Position for weights | Choose false value 7 or 11 | Irregular divisors handled via FP |
| 4 | Some algebra texts (Høyrup) | 7, 11, 13, 14, 17 | Linear & quadratic problems | "Irregular" divisors appear | Scribes accepted them when problem required |
| 5 | Plimpton 322 (indirect) | Various | Pythagorean triples | Some triples involve irregular factors | Not pure FP but related advanced math |
| Index | Step | Babylonian Action | Sexagesimal Result | Modern Equivalent | Quibble-Notes |
|---|---|---|---|---|---|
| 1 | Half the difference | Halve (x – y) | 3;30 | b/2 | Geometric "moiety" |
| 2 | Square it | (Half-difference)² | 12;15 | (b/2)² | Added area of small square |
| 3 | Add to product | Product + (b/2)² | 1,12;15 | c + (b/2)² | Completing the square |
| 4 | Take square root | √result | 8;30 | √(c + (b/2)²) | Side of completed square |
| 5 | Add & Subtract | Root ± half-difference | 12 and 5 | Solutions | Two positive roots |
| Audit Window | Some Lines Badly preserved or lost |
| Index | Step | Geometric Action | Sexagesimal Operation | Modern Equivalent |
|---|---|---|---|---|
| 1 | Half coefficient | Cut the protruding side in half | b/2 | b/2 |
| 2 | Square the half | Add small square | (b/2)² | (b/2)² |
| 3 | Add to given area | Complete the large square | c + (b/2)² | Completing the square |
| 4 | Take square root | Side of completed square | √c + (b/2)² | Square root |
| 5 | Adjust | Add/subtract half coefficient | Solutions | x = -b/2 ± √... |
| Audit Window | Some Lines Badly preserved or lost |
Scribe Rules of Thumb, deduced from extant Babylonian math problems.
| Index | Problem Type | Preferred Method | Method Reason | Tablet Examples | Quibble Notes |
|---|---|---|---|---|---|
| 1 | Square + sides = area | Completing the Square | Direct geometric fit | YBC 6967, BM 13901 | Most common quadratic type; strong visual intuition with areas |
| 2 | Length + width and product | Difference of Squares | Natural L-shape construction | TMS VII #2, YBC 4714 | Very frequent in field division problems |
| 3 | Two numbers, sum & product | Difference of Squares | Classic “two numbers” problem | BM 13901, Str 368 | Pedagogically central method in OB schools |
| 4 | Square minus sides = area | Completing the Square (subtract) | Rare but symmetric | BM 13901 | Less common, requires careful sign handling |
| 5 | Near-square fields | Difference of Squares | Small corner term easy to handle | Susa tablets (TMS) | Practical for real land surveying work |
| 6 | Coefficients easy to halve | Completing the Square | Regular sexagesimal numbers | YBC 6967 | Scribes strongly preferred even coefficients |
| 7 | Strong geometric visualization | Completing the Square | Areas and sides directly manipulable | BM 13901, YBC 6967 | Reflects Babylonian preference for geometric thinking |
| 8 | Abstract / pure number problems | Difference of Squares | Works well without geometric model | BM 13901 | Used when geometric interpretation is less obvious |
Scribe Rules of Thumb, deduced from extant Babylonian math problems.
| Index | Problem Type | Preferred Method | Method Reason | Tablet Examples | Quibble Notes |
|---|---|---|---|---|---|
| 1 | Partnership / inheritance division | False Position + Scaling | Simple ratios between shares | IM 31210 #3 (Beer) | Classic teaching problem; very common |
| 2 | Multiple partners with complex ratios | False Position (convenient small sum) | Easy to heap then scale | IM 31210 #3 | False total often 21 or 7 for clean scaling |
| 3 | Mixed commodities with different rates | Combined Market Rate (reciprocals) | Convert rates to unit prices then combine | IM 31210 #4 | Core of "grain may rise or fall" problems |
| 4 | Different quality goods (fine vs common) | maḫārum + Combined Rate | Make values equal before valuation | YBC 4698 (#3–5, #12–14) | "Make equal" (ib₂-sa₂) is the key step |
| 5 | Inventory valuation of mixed stock | maḫārum + Unit Values + Scaling | Compute total silver/grain equivalent | YBC 4698 | Practical merchant / administrator skill |
| 6 | Given total grain/silver, find quantities | Unit Price + Scaling Multiplier | Determine proportional distribution | IM 31210 #4 | Uses "What to ... should I set?" phrasing |
| 7 | "Grain may rise or fall, rates may be equal" | Combined Market Rate + Scaling | Normalize different rates for one total | IM 31210 #4 | Didactic formula for equalization |
| 8 | Need clean integer final shares | Adjusted False Position | Choose false values that divide evenly | IM 31210 #3 (with 42 or 28) | Babylonian aesthetic favors nice numbers |
| Index | Aspect | Market Rate Problem (#4) | Brothers / Partners Problems | Quibble-Notes |
|---|---|---|---|---|
| 1 | Core Technique | False position + scaling multiplier (20) | False position + scaling multiplier | Very strong family resemblance |
| 2 | Summation Step | Heap unit prices → 4;35 | Heap false shares (e.g. 4;22 30) | Identical Babylonian phrasing ("ku-mur") |
| 3 | Multiplier Discovery | "What to 4 35 should I set..." → 20 | "What to X should I set..." → scaling factor | Almost identical procedure |
| 4 | Mathematical Object | Reciprocals (market rates → unit prices) | Direct shares / arithmetic relations | Market version needs extra reciprocal step |
| 5 | Structure | Parallel computations for 4 commodities | Sequential subtraction or simple ratios | Market is more "horizontal" |
| 6 | Type of Progression | Not arithmetic | Mostly arithmetic (steadily decreasing) | Clear difference in flavor |
| 7 | Visualization | Harder to represent as bars | Very natural as vertical bars / grids | Partners easier for engineers |
| 8 | Overall Relation | Related but distinct | Related but distinct | Same conceptual family, different tools |
| Audit Window | Some Lines Badly preserved or lost |
| Index | Commodity | Market Rate | Babylonian Calculation | Sexagesimal | Decimal | Quibble-Notes |
|---|---|---|---|---|---|---|
| 1 | 1 | 2 for 1 bán | reciprocal(2) × 1 = 0;30 × 1 | 0;30 | 0.5 | Standard reciprocal; very clean |
| 2 | 2 | 1 for 2 bán | reciprocal(1) × 2 = 1 × 2 | 2 | 2.0 | No reciprocal needed (rec.1 = 1) |
| 3 | 3 | 3 for 4 bán | reciprocal(3) × 4 = 0;20 × 4 | 1;20 | 1.333... | 1;20 = 4/3 exactly |
| 4 | 4 | 4 for 3 bán | reciprocal(4) × 3 = 0;15 × 3 | 0;45 | 0.75 | 0;45 = 3/4 exactly |
| Audit Window | All | — | — | 4;35 | 4.5833… | Combined basket price (one of each) |
| Index | Category | Details | Quibble-Notes |
|---|---|---|---|
| 1 | Pros (Similarities) | Same false-position + scaling engine<br>Same economic division theme<br>Same pedagogical language | Strong evidence they come from same scribal training |
| 2 | Pros | Both train proportional reasoning and linear scaling | Core Babylonian mathematical strength |
| 3 | Cons (Dissimilarities) | Market requires reciprocal arithmetic | Partners mostly use subtraction / ratios, Market feels more advanced |
| 4 | Cons | 4 different item types vs people with relations | Different constraints , Not the same algorithm |
| 5 | Verdict | Cousins, not twins — same toolkit, different applications | They belong to the same recombination text for good reason |
| Audit Window | Some Lines Badly preserved or lost |
| Index | Aspect | Old Babylonian Method | Modern Algebra Equivalent | Quibble-Notes |
|---|---|---|---|---|
| 1 | Notation | Rhetorical / Verbal steps ("take", "heap", "tear off") | Symbolic (x, y, equations, formulas) | Babylonians used no variables or equals sign |
| 2 | Core Technique | False Position (assume value 1, scale at end) | Direct solving / substitution / matrices | Extremely common on IM 31210 and other tablets |
| 3 | Linear Equations | False position or averaging | ax + b = c → x = (c-b)/a | Very effective for partnership & inheritance problems |
| 4 | Quadratic Equations | Geometric "completing the square" (cut-and-paste) | Quadratic formula x = -b ± sqrt(b²-4ac) / 2a | They solved many quadratics without symbolic form |
| 5 | Systems of Equations | False position + successive scaling | Gaussian elimination or substitution | Seen in IM 31210 #3 (3 partners) |
| 6 | Arithmetic Progressions | Repeated subtraction of constant difference | a + (n-1)d formula | Heavily used in #2 and #7 (steadily decreasing shares) |
| 7 | Market / Rate Problems | Reciprocal tables + proportional scaling | Weighted averages or linear combinations | IM 31210 #4 is a classic example |
| 8 | Visualization | Geometric diagrams, grids, areas | Graphs, coordinate geometry | Babylonians thought geometrically |
| 9 | Strengths | Practical, algorithmic, accurate for positives | General, abstract, works for all cases | Babylonian math was highly effective for daily use |
| 10 | Limitations | No general formulas, case-by-case recipes | Highly general and symbolic | No negatives or abstract proofs |
| Audit Window | Some Lines Badly preserved or lost |
| Index | Problem Type | Babylonian Approach | Modern Approach | Quibble-Notes |
|---|---|---|---|---|
| 1 | Three Partners (#3) | False values 1-7-13 → scale by total/21 | Set up system: A+B+C=T, A+C=2B, B=7C → solve | Very clean false position example |
| 2 | Seven Partners (#2) | Start with 1, subtract 7;30 repeatedly, scale by 16 | Arithmetic sequence sum formula | Classic steadily decreasing shares |
| 3 | Market Rates (#4) | Compute reciprocals, sum, find multiplier 20 | Solve linear system or use matrix | Rare explicit surviving procedure |
| 4 | General Linear | Trial value + proportional correction | Symbolic solving or matrices | False position is precursor to modern iteration |
| 5 | Quadratic | Cut rectangle, add square, take root | Quadratic formula or completing square | Geometric intuition was very strong |
| Audit Window | B. did not use formal symbolic math | Some Lines Badly preserved or lost |
| Index | Aspect | Old Babylonian Market Rate (#4) | Medieval / Pencil-Paper Scratch Method | Quibble-Notes |
|---|---|---|---|---|
| 1 | Workflow Style | Compute each term separately → Heap (sum) → Find multiplier → Distribute | Break problem into partial sums → Add them → Scale or adjust | Strong superficial similarity |
| 2 | Intermediate Results | 30, 2, 1 20, 45 → sum 4 35 | Partial products or sums written aside | Looks like "working notes" |
| 3 | Summation | "Heap them" (ku-mur) explicitly written | Adding column of numbers on scratch paper | Very similar visual process |
| 4 | Scaling Step | Find 20 × 4 35 = 1 31 40, then multiply each line by 20 | Find common factor then distribute | Almost identical logic |
| 5 | Medium | Clay tablet — permanent, careful layout | Pencil & paper / dust board — temporary, erasable | Babylonian version is more formal |
| 6 | Purpose | Combined market rate / proportional allocation | General multi-step arithmetic (merchants, surveyors) | Both practical economic math |
| 7 | Risk of Confusion | Can look like early "addition of partial sums" | Medieval galley or scratch methods | Easy to mistake one for the other at first glance |
| Audit Window | Some Lines Badly preserved or lost |
| Index | Item / Step | Babylonian Calculation | Sexagesimal | Decimal | Quibble-Notes |
|---|---|---|---|---|---|
| 1 | Rate Fine Oil (i₃-sag) | 3 sila per shekel | 3 | 3 | First-quality oil |
| 2 | Rate Common Oil (i₃-geš) | 12 sila per shekel (1 bán 2 sila) | 12 | 12 | Regular / cheaper grade |
| 3 | Unit Price Fine Oil | reciprocal(3) | 0;20 | 0.333... | 1/3 shekel per sila |
| 4 | Unit Price Common Oil | reciprocal(12) | 0;5 | 0.0833... | 1/12 shekel per sila |
| 5 | Combined Price (1 sila each) | 0;20 + 0;5 = heap | 0;25 | 0.4167 | Cost of one "basket" |
| 6 | Scaling Multiplier | 1 ÷ 0;25 | 2;24 | 2.4 | False position / division step |
| 7 | Quantity of each oil | 2;24 × 1 sila | 2;24 sila | 2.4 sila | Equal quantity purchased |
| 8 | Silver Cost - Fine Oil | 2;24 × 0;20 | 0;48 | 0.8 shekel | Higher value oil |
| 9 | Silver Cost - Common Oil | 2;24 × 0;5 | 0;12 | 0.2 shekel | Lower value oil |
| 10 | Total Silver | 0;48 + 0;12 | 1 | 1.0 shekel | Balances exactly to 1 gin₂ |
| Audit Window | Purpose | Mixed oil inventory valuation | — | — | Practical merchant / administrative exercise |
| Index | Item / Step | Babylonian Calculation | Sexagesimal | Decimal | Quibble-Notes |
|---|---|---|---|---|---|
| 1 | Rate Fine Oil (i₃-sag) | 3 sila per shekel | 3 | 3 | First-quality oil — higher value |
| 2 | Rate Common Oil (i₃-geš) | 12 sila per shekel | 12 | 12 | Regular grade — lower value |
| 3 | Unit Value Fine Oil | reciprocal(3) | 0;20 | 0.333... | Silver value per sila of fine oil |
| 4 | Unit Value Common Oil | reciprocal(12) | 0;5 | 0.0833... | Silver value per sila of common oil |
| 5 | Combined Value (1 sila each) | 0;20 + 0;5 = heap | 0;25 | 0.4167 | Value of one mixed "basket" |
| 6 | Scaling Multiplier | 1 ÷ 0;25 | 2;24 | 2.4 | How many baskets fit in 1 shekel |
| 7 | Inventory Quantity (each type) | 2;24 sila of fine + 2;24 sila of common | 2;24 sila | 2.4 sila | Assumed equal stock on hand |
| 8 | Inventory Value - Fine Oil | 2;24 × 0;20 | 0;48 | 0.8 shekel | Book value of fine oil stock |
| 9 | Inventory Value - Common Oil | 2;24 × 0;5 | 0;12 | 0.2 shekel | Book value of common oil stock |
| 10 | Total Inventory Value | 0;48 + 0;12 | 1 | 1.0 shekel | Total silver equivalent of mixed stock |
| Audit Window | Purpose | Mixed oil inventory valuation | — | — | Practical merchant / administrative exercise |
| Index | Context | Akkadian / Sumerian | Meaning in Practice | Typical Use in YBC 4698 | Quibble-Notes |
|---|---|---|---|---|---|
| 1 | Geometry | šutamḫurum / ib₂-sa₂ | Construct a square (“make confront itself”) | Square roots, areas | Foundational algebraic term |
| 2 | Economics / Valuation | maḫārum / ib₂-sa₂ | Make quantities equal in value/weight | Oil problems #3–5, #12–14 | Core of combined rate exercises |
| 3 | Procedure Step | ib₂-sa₂-ma sa₁₀ | “I made equal and bought” | Fine vs common oil | Links equalization to purchase |
| 4 | Relation to Other Tools | With reciprocals + scaling | Normalize different rates → combined value | Inventory valuation | Bridges false position & market rates |
| 5 | Modern Analogy | — | Weighted equalization or basket pricing | Mixed-grade inventory | Precursor to unit pricing & indexing |
| Index | Rule of Thumb | When to Use | Practical Effect | Quibble-Notes |
|---|---|---|---|---|
| 1 | Start with 1 | Almost always (linear problems) | Keeps arithmetic simple | Most common Babylonian choice |
| 2 | Prefer smallest or largest as false = 1 | Arithmetic progressions & ratios | Avoids early fractions | See IM 31210 #2 and #3 |
| 3 | False total often = sum of coefficients | When ratios are given | Predictable denominator | In #3 → 13+7+1 = 21 |
| 4 | Accept irregular primes (7,11,13…) | When problem forces them | Scale at the end | 7 in IM 31210 #3 is problem-driven |
| 5 | Scaling factor usually "regular" | Look for easy reciprocals | Makes final shares nice | 16 in #2, 20 in #4, 2 in #3 |
| 6 | Quick bound check | Before full calculation | Average share × n ≈ total | Helps verify reasonableness |
| 7 | For n equal partners | False total = n × false_share | Scaling factor = total / n | Simplest case |
Note. These rules of thumb help constrain the solution space and give you quick intuition before doing the full calculation. Exactly as the Babylonians did mentally or on scratch tablets.
Note. This table is used as a work around for missing lines on tablets.
| Index | Rule of Thumb | Formula / Heuristic | Example (7 brothers) | Quibble-Notes |
|---|---|---|---|---|
| 1 | Average Share | Total / n brothers | 70 / 7 = 10 shekels | Quick sanity check |
| 2 | Largest Share (approx) | Average + (n-1)/2 × step | ~16–18 | Elder bias |
| 3 | Smallest Share (approx) | Average - (n-1)/2 × step | ~4–6 | Youngest bias |
| 4 | False Position Sum | Often near n × average (false) | 4;22 30 for n=7 | Very useful predictor |
| 5 | Good False Start | 1 for extreme (largest/smallest) | Largest=1 in #2 | Minimizes fractions |
Note. These rules of thumb help constrain the solution space and give you quick intuition before doing the full calculation. Exactly as the Babylonians did mentally or on scratch tablets.
Note. This table is used as a work around for missing lines on tablets.
| Index | Quantity | Lower Bound Estimate | Typical / Average Estimate | Upper Bound Estimate | Quibble-Notes |
|---|---|---|---|---|---|
| 1 | Average Share | Total / n | Total / n | Total / n | Most reliable starting point |
| 2 | Largest Share (Elder) | Average | Average + 0.4×Average | Average + 0.8×Average | Elder bias common |
| 3 | Smallest Share (Youngest) | 0.1 × Average | 0.3 × Average | 0.6 × Average | Often much smaller |
| 4 | Common Difference (step) | Average / (n+1) | Average / (n-1) | Average / (n-2) | For steadily decreasing shares |
| 5 | False Position Sum | n/2 | n × (false largest / 2) | n × false largest | Strong lower bound predictor |
| 6 | Scaling Factor | 2 | 8 to 20 | 30+ | Usually a regular sexagesimal number |
| 7 | Total Parts (in ratio problems) | n | Multiple of key ratio (e.g. 21) | — | See #3 with factor 7 → 21 parts |
Note. This table is used as a work around for missing lines on tablets.
| Index | Rule of Thumb | When to Use | Practical Effect | Quibble-Notes |
|---|---|---|---|---|
| 1 | Always reduce to “square + sides” form first | All quadratic problems | Standard starting shape for completion | Most common on Old Babylonian tablets |
| 2 | Halve the coefficient of the linear term | When you have “square + sides = area” | Gives the width of the rectangles to add | Critical step — Babylonians did this mentally |
| 3 | Add the square of the half-coefficient | To complete the large square | Creates a perfect square whose side is easy to take | This is the geometric “completion” |
| 4 | Take the square root of the completed square | After adding the small square | Yields the side of the large square | Use tables of squares or approximation |
| 5 | Subtract the half-coefficient from the large side | To find the larger unknown | Gives one root directly | Most common case (positive root) |
| 6 | Add the half-coefficient to the large side | When you need the smaller unknown | Alternative root or check | Used when two positive solutions exist |
| 7 | Prefer problems where half-coefficient is regular (easy reciprocal) | Coefficient divisible by 2, 3, 4, 5, 6… | Keeps all numbers in sexagesimal without awkward fractions | Scribes chose problems accordingly |
| 8 | Check by multiplying the two sides | After solution | Verify original area | Quick mental or scratch-tablet check |
Note. These rules reflect the standard Babylonian geometric approach. Transform the quadratic into a square plus rectangles, complete the square by adding a small corner square, then extract roots geometrically.
Note. The method works for equations of the form
x² + b * x = c or x² – b * x = c
| Index | Real Total | Scaling Factor | Smallest (1) | Middle (2) | Largest (4) | Quibble-Notes |
|---|---|---|---|---|---|---|
| 1 | 28 | 4 | **4** | **8** | **16** | Excellent clean integers. Recommended. |
| 2 | 35 | 5 | **5** | **10** | **20** | Also very clean. Slightly larger. |
| 3 | 42 | 6 | **6** | **12** | **24** | Very nice Babylonian-friendly number |
| 4 | 21 | 3 | **3** | **6** | **12** | Smallest practical integer set |
| 5 | 14 | 2 | **2** | **4** | **8** | Minimal reasonable total |
Note. These are computer "permutations" of the math problem #3, not from clay tablets.
Note. If one removes the integer restrictions and integer share mandate of Babylonian Base 60 math, there appears an infinite number of possible problems similar to Beer Problem #3 in the TCL code.
| Index | Real Total | Scaling Factor | Smallest (1) | Middle (2) | Largest (4) | Quibble-Notes |
|---|---|---|---|---|---|---|
| 1 | 28 | 4 | 4 | 8 | 16 | Excellent clean integers. Recommended. |
| 2 | 35 | 5 | 5 | 10 | 20 | Very clean. Slightly larger. |
| 3 | 42 | 6 | 6 | 12 | 24 | Nice Babylonian-friendly number. |
| 4 | 49 | 7 | 7 | 14 | 28 | Good mid-range total. |
| 5 | 56 | 8 | 8 | 16 | 32 | Clean and practical. |
| 6 | 63 | 9 | 9 | 18 | 36 | Very nice round shares. |
| 7 | 119 | 17 | 17 | 34 | 68 | Close to 120 target. |
| 8 | 126 | 18 | 18 | 36 | 72 | Clean multiple near 120. |
| 9 | 182 | 26 | 26 | 52 | 104 | Close to 180 target. |
| 10 | 189 | 27 | 27 | 54 | 108 | Clean and balanced near 180–200. |
| 11 | 238 | 34 | 34 | 68 | 136 | Close to 240 target. |
| 12 | 245 | 35 | 35 | 70 | 140 | Very clean near 240. |
| 13 | 294 | 42 | 42 | 84 | 168 | Close to 300 target. |
| 14 | 301 | 43 | 43 | 86 | 172 | Clean multiple near 300. |
Note. These are computer "permutations" of the math problem #3, not from clay tablets.
Note. If one removes the integer restrictions and integer share mandate of Babylonian Base 60 math, there appears an infinite number of possible problems similar to Beer Problem #3 in the TCL code.
| Index | Aspect | Purpose | Quibble-Notes |
|---|---|---|---|
| 1 | Educational | Train scribes in proportional arithmetic and reciprocals | Part of standard scribal curriculum |
| 2 | Practical | Handle real economic situations (buying multiple goods with fixed silver) | Equivalent to calculating "basket prices" |
| 3 | Algorithmic | Practice "compute each rate → sum → scale" method | Very similar to partner division problems |
| 4 | Not Predictive | No evidence of forecasting future prices | No link to astronomical data for prediction |
| 5 | Context | Administrative / merchant training | Scribes worked for temples, palaces, and merchants |
Note. The Babylonian method of combining multiple rates into one coherent number is spiritually similar to modern basket trading, sector rotation, or index construction.
| Index | Method | Rote Statement | Description and Purpose | Typical Example (Tablet) | Quibble-Notes |
|---|---|---|---|---|---|
| 1 | Heap Them (Accumulation) | Heap them together (ku-mur) | Add all computed parts back together to confirm they equal the original total | IM 31210 beer sharing or inheritance shares | Most common and reliable check. Ensures proportionality |
| 2 | Return (Reversal) | Return to the original (restore the total) | Reverse operations or recompute from the answer to recover the starting quantity | Inheritance problems or YBC 6967 quadratic roots | Detects arithmetic errors by working backwards |
| 3 | See if It Balances (Equality) | See if it balances (check the account) | Compare result against known constraints or each other for exact equality | Market rate problems (IM 31210 #4 or YBC 4698 oil) | Final validation step. Scribes always performed this |
| 4 | Square Completion Check | Complete the square and inspect sides | After geometric manipulation, verify areas or sides match | YBC 6967 quadratic (difference 7, product 60) | Geometric intuition check using areas |
| 5 | False Position Validation | Test the assumption and adjust if needed | Plug final scaled values back into original conditions | IM 31210 #2 seven partners or #3 three partners | Iterative refinement until error vanishes |
| 6 | Quick Bound Check | Average share times number of partners | Compare estimated average against total for reasonableness | Brother problems with steadily decreasing shares | Mental sanity check before full scaling |
| Audit Window | Some Lines Badly preserved or lost |
| Index | Babylonian Technique | Modern Speculative Use | Creative Interpretation | Quibble-Notes |
|---|---|---|---|---|
| 1 | Combined Market Rate (Sum unit prices) | Basket Index / Sector Rotation | Calculate a "market basket strength" index | Like a primitive Dow Jones or commodity index |
| 2 | Reciprocal Calculation (Unit Price) | Relative Value / Strength | Strong rate = cheap asset | "igi" as inverse valuation metric |
| 3 | Scaling Factor (20× in #4) | Leverage / Position Sizing | How much exposure you can afford | Determines portfolio allocation |
| 4 | "Heap" (Sum of costs) | Total Portfolio Risk | Combined exposure across assets | Early form of portfolio variance |
| 5 | False Position + Scaling | Scenario Analysis | Test different total capital levels | Stress testing different market regimes |
Added extensions below for more creative uses.
| Index | Babylonian Element / Step (IM 31210 #4) | Modern Creative Use | Purpose | Quibble-Notes |
|---|---|---|---|---|
| 1 | Market Rates (e.g. "2 for 1 bán", "3 for 4 bán") | Yield / Units per unit capital (earnings yield, momentum score, etc.) | Measure relative attractiveness of each asset | The raw "market rate" input — core data feed |
| 2 | Compute Unit Price (igi × quantity) | Normalize to Cost per Unit | Make dissimilar assets comparable | Classic Babylonian reciprocal ("igi") technique |
| 3 | Heap (ku-mur) — Sum of unit prices | Build "Combined Market Cost Index" | Create single valuation number for the whole basket | The heart of Babylonian market rate method |
| 4 | Find Scaling Factor ("What to heap should I set?") | Overall Exposure / Leverage Decision | Determine how much total capital to deploy | The key "multiplier" decision — position sizing |
| 5 | Multiply each unit price by scaling factor | Asset Allocation / Portfolio Construction | Distribute capital proportionally across assets | Final "how much of each to buy" step |
| 6 | (Creative Extension) Track scaling factor + rates over time | Momentum & Market Regime Detection | Detect shifts between cheap/expensive or bullish/bearish regimes | Modern addition — turns static exercise into dynamic tool |
| 1 | Compute reciprocals for each rate | Normalize asset attractiveness | Makes different assets comparable | "igi" technique |
| 2 | Heap the unit prices | Build Combined Market Index | Single valuation number | Core innovation |
| 3 | Find scaling factor | Determine overall exposure | Position sizing / risk control | The "what should I set" step |
| 4 | Multiply each by scaling factor | Asset allocation | Portfolio construction | Final distribution |
| 5 | (Extension) Track over time | Momentum & regime detection | Early warning system | Modern creative addition |
Note. The Babylonian method of combining multiple rates into one coherent number is spiritually similar to modern basket trading, sector rotation, or index construction.
Note. These Snippets on Theoretical Physics are a set, not stand alones. Recommend read all of the set.
Note. The ink is hardly dry on some of these papers. Don't know what gems are hidden, if I dig deeper.
+----------------------------------------------------------------------------------+
| THREE PARTNERS SHARING BEER (kisiru vessels) |
| |
| A (largest partner) + B ("my" share) + C (smallest) = TOTAL |
| |
| Key relations from tablet: |
| A + C = 2 x B ("their kisirus are twice my kisiru") |
| B = 7 x C ("seven ... of one is my kisiru") |
| |
| Solution ratios --> A : B : C = 13 : 7 : 1 (total 21 parts) |
+----------------------------------------------------------------------------------++----------------------------------------------------------------------------------+
| RECOMMENDED SOLUTION -- Total = 42 units |
| |
| Partner Share Check |
| ───────────────── ─────────── ────────────────────────────── |
| Largest (A) 26 A + C = 26 + 2 = 28 = 2x14 |
| Middle ("my" B) 14 B = 7xC --> 14 = 7x2 |
| Smallest (C) 2 Total = 26+14+2 = 42 |
| |
| Very clean numbers. Fits Babylonian preference for integers. |
+----------------------------------------------------------------------------------++----------------------------------------------------------------------------------+
| TABLET PROCEDURE (Reconstructed) |
| |
| 1. Assume false_C = 1 |
| 2. false_B = 7 x 1 = 7 ("seven was said to you") |
| 3. false_(A+C) = 2 x 7 = 14 ("7 to two repeat --> 14 keep in head") |
| 4. false_A = 14 - 1 = 13 |
| 5. false_total = 13 + 7 + 1 = 21 |
| |
| Scale: real_share = false_share x (real_total / 21) |
| |
| "Let 14 keep your head" -- exactly as on the tablet! |
+----------------------------------------------------------------------------------++----------------------------------------------------------------------------------+ | VISUAL CONSTRUCTION ON GRID (like 4x4 tablet diagram) | | | | Draw total bar of length 21 units (or 42 for nicer numbers) | | | | +──────────────────────────────────────────────────────+ <- Total = 42 | | |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | A = 26 | | |XXXXXXXXXXXXXXXXXXXXXXXXXXXX | B = 14 | | |XXX | C = 2 | | +──────────────────────────────────────────────────────+ | | | | Straightedge across grid lines gives exact proportions. | | Arithmetic progression: common difference of 12 (when scaled to 42). | +----------------------------------------------------------------------------------+
+----------------------------------------------------------------------------------+ | GEOMETRIC PROGRESSION ATTEMPT (Ratio ~2) | | | | Shares: 7 --> 14 --> 28 Total = 49 | | | | Satisfies A + C ~= 2xB under different assignment | | Does NOT satisfy B = 7xC cleanly | | Interesting but less faithful to tablet "seven" condition | | | | Preferred solution remains 13-7-1 ratio (scaled). | +----------------------------------------------------------------------------------+
copy----
+----------------------------------------------------------------------------------+ | IM 31210 #2 -- Division of 1 mina 10 shekels of silver | | | | 7 partners with steadily decreasing shares | | Common difference = 7;30 (sexagesimal) = 7.5 decimal | | | | Final Real Shares (shekels): | | 16 --> 14 --> 12 --> 10 --> 8 --> 6 --> 4 | | | | Total = 70 shekels = 1 mina 10 shekels | +----------------------------------------------------------------------------------+
copy----
+----------------------------------------------------------------------------------+ | VISUAL REPRESENTATION -- Vertical Bars (Each # = 1 shekel) | | | | Partner 1 (largest) 16 ################ | | Partner 2 14 ############## | | Partner 3 12 ############ | | Partner 4 10 ########## | | Partner 5 8 ######## | | Partner 6 6 ###### | | Partner 7 (smallest) 4 #### | | | | Arithmetic Series: Common difference = -2 shekels | | Total sum = 70 shekels | +----------------------------------------------------------------------------------+
copy----
+----------------------------------------------------------------------------------+ | BABYLONIAN PROCEDURE -- False Value Method | | | | Start with false largest share = 1 | | | | 1;00 - 7;30 = 0;52 30 | | 0;52 30 - 7;30 = 0;45 | | 0;45 - 7;30 = 0;37 30 | | 0;37 30 - 7;30 = 0;30 | | 0;30 - 7;30 = 0;22 30 | | 0;22 30 - 7;30 = 0;15 | | | | Sum of false shares = 4;22 30 | | | | Scaling factor = 16 (because 16 x 4;22 30 = 1;10) | | | | Multiply every false value by 16 --> real shares | +----------------------------------------------------------------------------------+
+----------------------------------------------------------------------------------+ | MATHEMATICAL STRUCTURE | | | | This is a classic arithmetic progression: | | | | First term (a) = 16 | | Common difference (d) = -2 | | Number of terms (n) = 7 | | | | General term: share_k = 16 - 2x(k-1) | | | | Sum = n/2 x (2a + (n-1)d) = 70 shekels | +----------------------------------------------------------------------------------+
+----------------------------------------------------------------------------------+ | IM 31210 #4 -- Market Rates Problem | | | | Market Rates (units per ban of grain): | | 2 for 1 ban --> unit price = ;30 ban | | 1 for 2 ban --> unit price = 2 ban | | 3 for 4 ban --> unit price = 1;20 ban | | 4 for 3 ban --> unit price = ;45 ban | | | | Combined price for 1 unit each = ;30 + 2 + 1;20 + ;45 = 4;35 ban | | | | Available grain = 1 31;40 ban | | Scaling factor = 20 | | | | Final quantities (each commodity): 20 units | | Final costs: 10 + 40 + 26;40 + 15 = 1 31;40 ban | +----------------------------------------------------------------------------------+
copy----
+----------------------------------------------------------------------------------+ | BABYLONIAN PROCEDURE | | | | 1. Compute unit prices (reciprocal x quantity) | | rec(2)x1 = 30 --> ;30 | | rec(1)x2 = 1x2 --> 2 | | rec(3)x4 = 20x4--> 1 20 | | rec(4)x3 = 15x3--> 45 | | | | 2. Sum unit prices = 4 35 | | 3. Find multiplier: 20 x 4 35 = 1 31 40 | | 4. Multiply each unit price by 20 --> actual costs | +----------------------------------------------------------------------------------+
+----------------------------------------------------------------------------------+ | IM 31210 #6 -- Division Among 13 Brothers | | | | Groups: | | Oldest brother (1) --> 13;20 | | Brothers 2 and 3 (equal) --> 6;40 each (total 13;20) | | Remaining 10 brothers --> 3;20 each (total 33;20) | | | | Checks: | | Oldest = Brothers 2+3 | | 10 brothers = 2;30 x (Brothers 2+3) | | Grand total = 13;20 + 13;20 + 33;20 = 1 ban | +----------------------------------------------------------------------------------+
+----------------------------------------------------------------------------------+ | VISUAL REPRESENTATION -- Vertical Bars (Each # ~= 1;00 = 60 units) | | | | Oldest ############## 13;20 | | Bro 2+3 ####### 6;40 each | | 10 bros #### 3;20 each | | | | Each # here ~= 1;00 (60 units) for visual scaling | +----------------------------------------------------------------------------------+
+----------------------------------------------------------------------------------+ | IM 31210 #7 -- 10 Partners dividing 1;40 mina silver | | | | Total silver = 1 40 mina = 100 shekels | | Average share = 10 shekels | | Sum of first 3 shares = 46;48 shekels | | | | Common difference d/2 = ;48 shekels | | Full difference d = 1;36 shekels | | | | Shares decrease steadily by 1;36 shekels each time | +----------------------------------------------------------------------------------+
+----------------------------------------------------------------------------------+ | VISUAL REPRESENTATION -- Ten Partners (Conceptual, each # ~= 1 shekel) | | | | Partner 1 (largest) ################# ~17;12 | | Partner 2 ############### | | Partner 3 ############# | | ... ... | | Partner 10 (smallest) #### | | | | Arithmetic series: common difference = -1;36 shekels | +----------------------------------------------------------------------------------+
+----------------------------------------------------------------------------------+ | Step 1: Original Rectangle (Area = 60) | | | | Length (x) | | +──────────────────────+ | | | | Width (y) | | | Area = 60 | | | | | | | +──────────────────────+ | | x - y = 7 | +----------------------------------------------------------------------------------+ | Step 2: Halve the difference --> 3;30 on each side | | Add two small rectangles (each 3;30 wide) | | | | +──────────────+───────+──────────────+ | | | 3;30 | | 3;30 | | | | | y | | | | +──────────────+───────+──────────────+ | +----------------------------------------------------------------------------------+ | Step 3: Add the square of half-difference (3;30 x 3;30 = 12;15) | | Final Completed Square (side = 8;30) | | | | +──────────────────────────────────────+ <- side = 8;30 | | | XXX | | | | Completed XXX | Area = 1,12;15 | | | Square XXX | | | +──────────────────────────────────────+ | | | | Larger number = 8;30 + 3;30 = 12 | | Smaller number= 8;30 - 3;30 = 5 | | Result: The two numbers are 12 and 5. | +----------------------------------------------------------------------------------+
+----------------------------------------------------------------------------------+ | Original: Square (x) + Side (x) = 45 | | | | +──────────────+ | | | | + x = 45 | | | x^2 | | | +──────────────+ | | | | After adding the small square (0;30 x 0;30 = 0;15): | | | | Completed Big Square (side = 6;45) | | | | +──────────────────────────────+ | | | | | | | Big Square | Side = 6;45 | | | Area = 45;15 | | | +──────────────────────────────+ | | | | Final side of original square = 6;45 + 0;30 = 7;15 | +----------------------------------------------------------------------------------+
+----------------------------------------------------------------------------------+ | GEOMETRIC INTERPRETATION | | Field area as difference of two squares | | | | Large square side = (a + b) / 2 = average of two sides | | | | +---------------------------+ | | | | | | | Large square | side = (a+b)/2 | | | area = term1 | | | | +--------+ | | | | Small | <-- subtract this corner | | +------------------+ square | area = term2 | | +--------+ side = (a-b)/2 | | | | Remaining area (L-shape) = term1 - term2 = a * b | | | | For almost-square fields: a ~ b --> (a-b)/2 is very very tiny | | --> term2 is very small --> result dominated by term1 | +----------------------------------------------------------------------------------+
Note. The very very tiny term2 square is called a moiety or bit in some Babylonian algorithms.
----+----------------------------------------------------------------------------------+ | STANDARD BABYLONIAN QUADRATIC SOLUTION (YBC 6967 style) | | | | Given: x² + b x = c (here b=7, c=60) | | | | Step 1: Halve b → b/2 = 3;30 | | Step 2: Square it → (b/2)² = 12;15 | | Step 3: Add to c → c + (b/2)² = 60 + 12;15 = 1,12;15 | | Step 4: Take square root → √1,12;15 = 8;30 | | Step 5: Larger root = 8;30 + 3;30 = 12 | | Step 6: Smaller root= 8;30 - 3;30 = 5 | | | | Geometric view: Add two rectangles (3;30 wide) + one corner square (12;15) | +----------------------------------------------------------------------------------+
----+----------------------------------------------------------------------------------+ | GEOMETRIC CONSTRUCTION — Completing the Square | | | | Original: Square(x) + two sides(b) = Area(c) | | | | +────────────────────+ | | | | ← x (side of original square) | | | x² | | | +────────────────────+ | | b | | | | After adding two rectangles (width b/2) and corner square: | | | | +──────────────────────────────+ ← Large completed square (side = x + b/2)| | | | | | | Completed | | | | Square | Area = c + (b/2)² | | | | | | +──────────────────────────────+ | | | | Take √(completed area) → subtract b/2 to recover x | +----------------------------------------------------------------------------------+
----+----------------------------------------------------------------------------------+ | ALTERNATIVE: Field as Difference of Two Squares | | (Used when equation is x² – y² = area) | | | | Large square side = (x + y)/2 | | Small square side = (x – y)/2 | | | | +────────────────────────+ | | | Large | | | | Square | side = (x+y)/2 | | | Area = Term 1 | | | | +--------+ | | | | Small | side = (x-y)/2 | | +---------------+ Square | Area = Term 2 | | +--------+ | | | | Remaining L-shape area = Term 1 – Term 2 = x·y | | Very common for “length + width” and “length – width” problems | +----------------------------------------------------------------------------------+
----+----------------------------------------------------------------------------------+ | QUICK METHOD SELECTION (Babylonian Scribe Rules of Thumb) | | | | Problem Type | Preferred Method | Reason | | --------------------------------|--------------------------------|----------------------------| | Square + sides = area | Completing the Square | Direct geometric fit | | Length + width and product | Difference of Squares | Natural L-shape | | Two numbers, sum & product | Difference of Squares | Classic “two numbers” | | Square minus sides = area | Completing the Square (subtract)| Rare but symmetric | | Near-square fields | Difference of Squares | Small corner term | | Coefficients easy to halve | Completing the Square | Regular sexagesimal numbers| +----------------------------------------------------------------------------------+
+----------------------------------------------------------------------------------+
| 10 WAYS TO IMPROVE TCL CODE EFFICIENCY |
| |
| +----+---------------------------+--------------------------------------------+|
| | # | tip | notes / source ||
| +----+---------------------------+--------------------------------------------+|
| | 1 | Faster random generator | RandMT / Mersenne Twister vs rand() ||
| | 2 | Memoization | cache results to avoid redundant calls ||
| | | | use dict (hash table) to store results ||
| | 3 | lrange over range loops | use lrange to generate lists, iterate ||
| | 4 | Simplify conditionals | use logical operators, reduce if-blocks ||
| | 5 | Break into small procs | improves readability and debuggability ||
| | 6 | Use TCL profiling tools | identify performance bottlenecks ||
| | 7 | Use time and clock cmds | measure elapsed time during development ||
| | 8 | BRACE YOUR EXPRESSIONS | set aa [expr {$aa+$ee}] reduces time x100! ||
| | | | credit: GWM. Really. Not exaggerated. ||
| | 9 | Check core/TCLLIB first | precompiled routines save ~1/3 time ||
| | | | homebrew SECOND, not first ||
| | 10 | Use modern TCL version | TCL 8.6.12+ has better performance ||
| +----+---------------------------+--------------------------------------------+|
| |
| Note on puts: printing output takes a lot of computer time. |
| Avoid puts until very end of program or omit in draft decks entirely. |
+----------------------------------------------------------------------------------++----------------------------------------------------------------------------------+ | PROPORTION RULES AS ALGORITHM BASIS (rule of three) | | Babylonian clay tablet proportion rules = first known linear equation solns | | | | +---------------------+----------+-----------------------------------------+ | | | proportion rule | date CE | source | | | +---------------------+----------+-----------------------------------------+ | | | if a/b = c/d | 450 CE | Aryabhata, Sanskrit Mathematics | | | | c = (a*b)/d | 450 CE | Aryabhata, Sanskrit Mathematics | | | | ditto | 1290 CE | Livero de l'abbecho, Italy | | | | ditto | 1307 CE | Tractatus algorismi, Vatican | | | | ditto | 1300 CE | Talkhis of Ibn al-Banna, Arabic | | | | d = (a*b)/c | 1290 CE | Sanskrit Mathematics | | | | Y = (b/a)*X | 1200 CE | ibn Thabat (rare, division-by-zero risk)| | | | b/a = d/c | -- | reciprocate ratios | | | | a/c = b/d | -- | sideways | | | | a*d = b*c | -- | cross multiplication | | | | c = (a*d)/b | -- | solving for c | | | | d = (b*c)/a | -- | solving for d | | | | a:b:c | -- | multiple proportion entries | | | +---------------------+----------+-----------------------------------------+ | | | | Pythagoras: 3 is perfect (beginning, middle, end) | | Lincoln: "learned to cipher to the rule of 3" | | Babylonians: base 60, emphasize 3*4=12, 3*20=60 | +----------------------------------------------------------------------------------+
+----------------------------------------------------------------------------------+ | PSEUDOCODE CHECKLIST FROM PROPORTION RULES | | | | # pseudocode: some problems solvable by proportions to order of magnitude | | # pseudocode: enter quantity1, quantity2, quantity3 | | # and expected output (quantity4) for testcases | | # pseudocode: outputs should be in compatible units | | # pseudocode: rules of thumb can be 3 to 15 percent off (g..in g..out) | | # pseudocode: need testcases -- small, medium, giant | | # pseudocode: need testcases within range of expected operation | | # pseudocode: are there any cases too small or too large to solve? | | | | Pseudocode output targets: | | output fraction of (remaining items) / (items at time zero) | | output fraction as percent | | output fraction of (quantity4) / (quantity1 at time zero) | | output fraction of (quantity2 * quantity3) / (quantity1 at time zero) | | | | Four forms of algorithm representation: | | +---------------------+----------------------------------------------------+| | | form | description || | +---------------------+----------------------------------------------------+| | | instruction list | step-by-step natural language, top-down order || | | flowchart | graphical, visualizes sequence and decision points || | | pseudocode | natural language + structure, language-independent || | | graphical instruct. | visual representation, pictures and diagrams || | +---------------------+----------------------------------------------------+| +----------------------------------------------------------------------------------+
Extant Babylonian Procedure, as preserved + Friberg reconstruction:
# Pseudocode # Problem Statement (Reconstructed) If he asks you about 1 bán of beer (or some total amount of beer), with three partners whose kiṣiru (shares/vessels) are in the following relation: The two other partners together have twice my kiṣiru My kiṣiru is seven times the smallest one What are the three shares?
# Pseudocode
IF asked about 1 bán of beer with 3 partners:
# Text is using method of false position.
total amount of beer = 1 bán
assuming 1 ban = 42 silas or cups # key statement in FP. method, but not on tablet
# beginning lost on tablet.
procedure ThreePartnersBeerDivision
# === BEGINNING: Setup the Problem ===
read real_total_beer # Possibly stated as 1 bán (10 sìla), but likely a multiple of 21
# Best clean solution assumes real_total_beer = 42 units
# === FALSE POSITION PHASE ===
# Assume a convenient false value for the smallest share
false_C = 1 # Smallest partner's kiṣiru
false_B = 7 * false_C # "seven was said to you"
# → "my kiṣiru is seven times the smallest"
false_A_plus_C = 2 * false_B # "their kiṣirus are twice my kiṣiru"
# 7 × 2 = 14 ("7 to two repeat, let 14 keep in your head")
false_A = false_A_plus_C - false_C # 14 - 1 = 13
# Sum the false shares
false_total = false_A + false_B + false_C # 13 + 7 + 1 = 21
# === SCALING PHASE ===
scaling_factor = real_total_beer / false_total # e.g. 42 / 21 = 2
# Apply the scaling factor to all false shares
real_C = false_C * scaling_factor # Smallest
real_B = false_B * scaling_factor # Middle ("my" share)
real_A = false_A * scaling_factor # Largest
------------------
# conclusion lost on tablet.
Output the three real shares.
# === CONCLUSION / OUTPUT ===
output "Largest partner (A):", real_A
output "Middle partner (my share B):", real_B
output "Smallest partner (C):", real_C
# Verification
check real_A + real_B + real_C == real_total_beer
check real_A + real_C == 2 * real_B
check real_B == 7 * real_C
This is a draft.
Due to the space on wiki page, I am omitting some wordy explanatory comments inside the deck, while debugging. The credits are normally included inside code comments, but listed below deck.
#tcl
# Possible solutions, missing key total amount in translation.
set total 42.0
# try 21, 42, 63, etc, multiples of 21
set C [expr {$total / 21.0}]
set B [expr {7 * $C}]
set A [expr {2 * $B - $C}]
puts "Largest: $A"
puts "Middle (my): $B"
puts "Smallest: $C"
puts "Sum check: [expr {$A + $B + $C}]"
#TCL
proc complete_square_1 {b c} {
# b = linear coefficient, c = constant term
# Returns list {larger_root smaller_root}
set half_b [expr {$b / 2.0}]
set small_sq [expr {$half_b * $half_b}]
set completed [expr {$c + $small_sq}]
# === Correct expr form for square root ===
set large_side [expr {sqrt($completed)}]
set larger_root [expr {$large_side + $half_b}]
set smaller_root [expr {$large_side - $half_b}]
return [list $larger_root $smaller_root]
}
# Alternative one-liner style (more compact)
proc complete_square_2 {b c} {
set hb [expr {$b / 2.0}]
set large_side [expr {sqrt($c + $hb*$hb)}]
return [list [expr {$large_side + $hb}] [expr {$large_side - $hb}]]
}
# Babylonian Style Verification Snippet
# Demonstrates Heap, Return, and Balances
proc babylonian_verification_demo {total_beer partner_ratios} {
set num [llength $partner_ratios]
set guess [expr {$total_beer * 1.0 / $num}]
for {set i 0} {$i < 8} {incr i} {
set shares {}
set heap_sum 0.0
foreach r $partner_ratios {
set share [expr {$guess * $r}]
lappend shares $share
set heap_sum [expr {$heap_sum + $share}]
}
# Babylonian Check: Heap them together
puts "Heap them together: Sum = $heap_sum (target $total_beer)"
set error [expr {abs($heap_sum - $total_beer)}]
if {$error < 0.001} {break}
set guess [expr {$guess * ($total_beer / $heap_sum)}]
}
# Babylonian Check: Return to original
set recovered 0.0
foreach s $shares {
set recovered [expr {$recovered + $s}]
}
puts "Return to original: Recovered total = $recovered"
# Babylonian Check: See if it balances
if {abs($recovered - $total_beer) < 0.001} {
puts "It balances: Solution verified correctly."
return $shares
} else {
puts "Does not balance: Recheck calculations."
return {}
}
}
# Example usage (IM 31210 style)
set total 42.0
set ratios {1 2 3 4}
set result [babylonian_verification_demo $total $ratios]
puts "Verified shares: $result"Clean Integer Version.
# pseudocode
procedure ThreeBrothersBeerShare_Clean
# === PROBLEM SETUP ===
real_total = 28 # Multiple of 7 → clean integers
# === FALSE POSITION PHASE ===
false_C = 1 # Smallest brother
false_B = 2 # Middle brother
false_A = 4 # Largest brother
false_total = 1 + 2 + 4 = 7 # Very clean false sum
# === SCALING PHASE ===
scaling_factor = real_total / false_total # 28 / 7 = 4
real_C = false_C * scaling_factor # 1 * 4 = 4
real_B = false_B * scaling_factor # 2 * 4 = 8
real_A = false_A * scaling_factor # 4 * 4 = 16
# === OUTPUT ===
output "Smallest brother :", real_C, "units"
output "Middle brother :", real_B, "units"
output "Largest brother :", real_A, "units"
output "Total :", real_C + real_B + real_A
end procedure
# References.
# Readable Pseudocode reconstruction based primarily
# on the Friberg, & Middeke-Conlin & Proust analysis
# pseudocode
# pseudocode
procedure CombinedMarketRate_FourCommodities
# === SETUP: READ THE GIVEN DATA ===
read available_grain = 1 31 40 # total grain (bán) you have
# Market rates given as (units : grain)
market_rate1 = 2 for 1 bán
market_rate2 = 1 for 2 bán
market_rate3 = 3 for 4 bán
market_rate4 = 4 for 3 bán
# beginning lines and much context lost on tablet.
# === PHASE 1: COMPUTE UNIT PRICE FOR EACH COMMODITY ===
# Unit price = grain needed to buy 1 unit of that commodity
# For first commodity
rec2 = reciprocal(2) # = 30 (i.e. 0;30)
unit_price1 = rec2 * 1 # = 30 → 0;30 bán per unit
# For second commodity
rec1 = reciprocal(1) # = 1
unit_price2 = rec1 * 2 # = 2 bán per unit
# For third commodity
rec3 = reciprocal(3) # = 20 (i.e. 0;20)
unit_price3 = rec3 * 4 # = 1 20 bán per unit
# For fourth commodity
rec4 = reciprocal(4) # = 15 (i.e. 0;15)
unit_price4 = rec4 * 3 # = 45 → 0;45 bán per unit
# === PHASE 2: COMPUTE COMBINED UNIT PRICE ===
combined_price = unit_price1 + unit_price2 + unit_price3 + unit_price4
# 0;30 + 2 + 1;20 + 0;45 = 4;35 bán
# (this is the grain cost for one set: 1 unit of each commodity)
# === PHASE 3: FIND THE SCALING MULTIPLIER ===
multiplier = available_grain / combined_price
# Solve: multiplier × 4;35 = 1 31 40
# Result: multiplier = 20
# === PHASE 4: SCALE TO ACTUAL QUANTITIES AND COSTS ===
quantity_each = multiplier # 20 units of each commodity
cost1 = multiplier * unit_price1 # 20 × 0;30 = 10 bán
cost2 = multiplier * unit_price2 # 20 × 2 = 40 bán
cost3 = multiplier * unit_price3 # 20 × 1;20 = 26 40 bán
cost4 = multiplier * unit_price4 # 20 × 0;45 = 15 bán
# final closing lines and much context lost on tablet.
# === VERIFICATION ===
total_cost = cost1 + cost2 + cost3 + cost4
check total_cost == available_grain # 10 + 40 + 26 40 + 15 = 1 31 40
# Output the solution
output "You can buy", quantity_each, "units of each of the four commodities."
output "Grain used for each:"
output " Commodity 1 (rate 2/1 bán):", cost1, "bán"
output " Commodity 2 (rate 1/2 bán):", cost2, "bán"
output " Commodity 3 (rate 3/4 bán):", cost3, "bán"
output " Commodity 4 (rate 4/3 bán):", cost4, "bán"
output "Total grain used:", total_cost
# References.
# Readable Pseudocode reconstruction based primarily
# on the Friberg, & Middeke-Conlin & Proust analysis
Modern Mathematical Equivalent (Sexagesimal → Decimal for Clarity) Unit prices: 0.5, 2, 1.333…, 0.75 bán per unit Combined price per set: 4.583… bán (= 4;35) Available: 1 31;40 = 91 + 2/3 bán Multiplier: 20 Quantities: 20 units each Costs: 10, 40, 26.666…, 15 bán → sum = 91.666… bán
Note. This matches the preserved procedure on the tablet exactly. Including the explicit use of reciprocals and the final multiplication by 20. The Babylonian results are integer based in Base 60.
Babylonian Market Forecaster (CMF v1)
# pseudocode
procedure BabylonianMarketForecaster
# === INPUTS (like a Babylonian scribe receiving rates) ===
available_capital # e.g. 1 31 40 (your trading capital, risk budget, etc.)
# Market Rates: "How many units you get per 1 unit of capital"
rate_A # e.g. 2.0 (Tech stocks)
rate_B # e.g. 1.5 (Energy)
rate_C # e.g. 3.2 (Grain / Commodities)
rate_D # e.g. 0.8 (Gold / Safe haven)
# === STEP 1: Compute Unit Prices (Reciprocal Method) ===
price_A = 1 / rate_A # "igi" style: how much capital per 1 unit
price_B = 1 / rate_B
price_C = 1 / rate_C
price_D = 1 / rate_D
# === STEP 2: Heap (Sum) the Combined Market Cost ===
combined_cost = price_A + price_B + price_C + price_D
# This is the Babylonian "heap" (ku-mur) — total cost for one unit of each asset
# === STEP 3: Find Scaling Factor ===
scaling_factor = available_capital / combined_cost
# "What to [combined_cost] should I set so that it equals my capital?"
# === STEP 4: Allocate (Distribute) ===
allocation_A = scaling_factor * price_A
allocation_B = scaling_factor * price_B
allocation_C = scaling_factor * price_C
allocation_D = scaling_factor * price_D
# === OUTPUT ===
output "Combined Market Cost Index:", combined_cost
output "Scaling Factor (Market Strength):", scaling_factor
output ""
output "Recommended Allocations:"
output "Asset A (Tech) :", allocation_A
output "Asset B (Energy) :", allocation_B
output "Asset C (Grain) :", allocation_C
output "Asset D (Gold) :", allocation_D
output "Total Allocated :", allocation_A + allocation_B + allocation_C + allocation_D
# Interpretation
if scaling_factor > 1.0:
output "Market is relatively CHEAP → Bullish signal"
else:
output "Market is relatively EXPENSIVE → Cautious signal"
end procedure
# References.
# Readable Pseudocode reconstruction based primarily
# on the Friberg, & Middeke-Conlin & Proust analysis
Example Run (Hypothetical) # pseudocode available_capital = 100000 rate_A = 2.0 # Tech rate_B = 1.5 # Energy rate_C = 3.0 # Commodities rate_D = 0.8 # Gold # Output might show: Combined Market Cost Index: 2.083 Scaling Factor: 48000 Allocations: Tech=24000, Energy=32000, Commodities=16000, Gold=28000 → Market is relatively CHEAP
(Common Oil vs. First-Quality / Fine Oil)
Reconstructed Problem Statement (Babylonian Style)
If he asks you: Buy the same quantity of first-quality oil and common oil. The rate in-kind for first-quality oil is 3 sila per shekel of silver. The rate in-kind for common oil is 1 bán 2 sila (= 12 sila) per shekel of silver.
What is the silver value (cost) for each oil when you buy equal amounts. and what is the common quantity you can buy for a total of 1 shekel of silver?
# Alternate text. Reconstructed Problem Statement (Babylonian Style) If he asks you: “Fine oil and common oil — make them equal (maḫārum / ib₂-sa₂) and buy (or value the inventory).” Given: Fine oil (i₃-sag): 3 sila per shekel Common oil (i₃-geš): 12 sila per shekel How much of each oil should you take so their silver values are equal. and what is the total silver value for a given total amount (e.g. 1 shekel)?
# pseudocode
procedure Maḫārum_Oil_Valuation_YBC4698
# === SETUP: GIVEN DATA ===
read total_silver = 1 gin₂ (shekel)
rate_fine = 3 sila per shekel # first-quality oil
rate_common = 12 sila per shekel # regular oil
# === PHASE 1: COMPUTE UNIT VALUES (silver per sila) ===
unit_value_fine = reciprocal(rate_fine) # 0;20 shekel per sila
unit_value_common = reciprocal(rate_common) # 0;5 shekel per sila
# === PHASE 2: maḫārum - MAKE EQUAL (Equalization Step) ===
# Goal: Find quantities such that silver value of fine = silver value of common
# or compute combined value for equal quantities (most common interpretation)
combined_value_per_sila_pair = unit_value_fine + unit_value_common
# 0;20 + 0;5 = 0;25 shekel
# (this is the cost/value for 1 sila of each after maḫārum)
# === PHASE 3: SCALING MULTIPLIER (False Position / Division) ===
# "What should I set to 0;25 so that it gives me 1 shekel?"
multiplier = total_silver / combined_value_per_sila_pair
# 1 ÷ 0;25 = 2;24
# === PHASE 4: APPLY maḫārum RESULT ===
quantity_fine = multiplier * 1 sila # Equal quantity of each
quantity_common = multiplier * 1 sila
value_fine = multiplier * unit_value_fine # Silver value after equalization
value_common = multiplier * unit_value_common
# === OUTPUT ===
output "After maḫārum (making equal):"
output "Quantity of fine oil: ", quantity_fine, "sila"
output "Quantity of common oil: ", quantity_common, "sila"
output "Silver value - Fine: ", value_fine
output "Silver value - Common: ", value_common
output "Total silver value: ", value_fine + value_common
# Verification
check value_fine + value_common == total_silver
check value_fine == multiplier * unit_value_fine
# References.
# Readable Pseudocode reconstruction based primarily
# on the Middeke-Conlin & Proust analysis
A DSL is a domain‑specific language. A DSL is a small, focused mini‑language designed to express ideas in one particular problem area more clearly than a general‑purpose language can.
Tcl is unusually good at DSLs. Because everything is a command and everything is a string. Tcl lets you shape the language to the problem instead of shaping the problem to the language.
# Tcl, 6/5/2026
# A DSL is a domain‑specific language.
# === Define the tiny DSL ===
proc silver {amount} { return $amount }
proc rate {kind amount} { dict set ::rates $kind $amount }
proc equalize {} {
set fine [dict get $::rates fine]
set common [dict get $::rates common]
set unit_fine [expr {1.0 / $fine}]
set unit_common [expr {1.0 / $common}]
set pair_value [expr {$unit_fine + $unit_common}]
set m [expr {$::total / $pair_value}]
puts "Equal quantities: fine=$m sila, common=$m sila"
}
# === Script written *in* the DSL ===
set total [silver 1.0] ;# 1 shekel
rate fine 3 ;# 3 sila per shekel
rate common 12 ;# 12 sila per shekel
equalize
Output on Equal quantities: fine=2.4 sila common=2.4 sila # exact numbers depend on floating‑point vs. sexagesimal, # but the workflow is correct. # Check 2.4/3. + 2.4/12. = 0.9999, rounds to 1. # Example entries for console window set total [silver 1.0] rate fine 3 rate common 12 equalize # This is a DSL for Problem #4 on fine oil # Reads like a Babylonian procedure, not like generic Tcl.
Note. Duration is how long it took for that specific scenario to run (in milliseconds). Duration = Computation / Execution Time
gold 2/9/2026. Added categories, so can find message in Wiki.
gold 2/3/2025. Testing, encountered initial difficulty in saving work? Long code blocks with or unmatched wiki markup can sometimes confuse the Tcl Wiki formatting engine, especially if fences are not balanced or a line begins with markup it treats specially.
gold 2/14/2026. Added Automatic Dump of Examples, Using ActiveState.
gold 2/14/2026. convert to strict 7-bit ASCII for Playground V9. reporting error at bottom. program should run to completion with automatic test suite.
gold 2/14/2026.
gold 3/7/2026. convert to strict 7-bit ASCII for Playground V9. variables need to be human readable and very explanatory. avoid variables with single letter names. Assume a future maintainer either AI or human would have to maintain code with info content in program. the program is working the numbers correctly . so minimal changes.
gold 5/23/2026. Forwarding Python version to other venue. The TCL version is posted here.
Matrix of Collatz solutions look like two swarms of bees rather a single linear solution or even look like multiple fuzzy levels of solution ranges, eg. non-linear solutions, observable in various pngs. You can tell me different. Based on long experience of fitting equations in engineering, possibly the probabilistic reasoning or pattern matching on quantum solutions plural is more adaptable.
gold 4/24/2026. Difficult for me to evaluate the Quantum math theories. The Python versions are posted in other venues. The TCL version is posted on wiki.
However, I suppose that the simulation model using TcL could check the Yada-Yada theory for consistencies with other vouched quantum rules. However, code seems interesting from a hack programming viewpoint.
gold 6/6/2026. My eyes are bad here on tiny fonts. But it looks like you are not defining your procs ahead of proc calls. That might be a no‑no in a Tcl package. Tcl reads files top‑to‑bottom, so if a DSL block appears before the supporting procedures are defined, the interpreter will complain. Your examples look fine conceptually
Professor Joran Friberg in 7/7/2021 pm. Thank you for this very interesting work gang interpretation of the Old Babylonian brothers’ shares problem in the cuneiform text IM 31210 #6. (A correction: The text was published in Ch. 7 of J. Friberg et al, New Mathematical Cuneiform Texts, Springer 2016.)
Please place any comments here with your wiki MONIKER and date, Thanks.gold 5/10/2026
Note. Testing computer methods and computer programs, maybe wrong numbers.
| Category Numerical Analysis | Category Toys | Category Calculator | Category Mathematics | Category Example | Toys and Games | Category Games | Category Application | Category GUI |