DEV Community: Agoes Jayanata

Lottery Odds in Plain Numbers: Why 1 in 292 Million Feels Impossible

Agoes Jayanata — Wed, 28 Oct 2026 05:00:38 +0000

Powerball's jackpot odds are 1 in 292,201,338. Mega Millions is about 1 in 302,575,350. Those figures come from counting combinations: 69 white balls choose 5, times 26 red balls.

To picture it, imagine 292 million people lined up and one holding the winning ticket. Buying 10 tickets a week for 50 years gives you 26,000 tickets, a chance of roughly 1 in 11,000 of winning once.

The odds of winning any prize are far kinder, about 1 in 24.9 for Powerball. Explore the breakdown with the lottery odds calculator.

Record prizes happen because rollovers pile up when nobody hits. The largest lottery jackpots list shows that nearly every billion-dollar prize followed a long drought of 25 or more drawings.

If the improbable happens, read the what to do if you win the lottery guide first: sign the ticket, keep it safe, and talk to a tax adviser before claiming.

Takeaway: a ticket is entertainment at $2, not an investment.

How to Check a California County Park Before You Go

Agoes Jayanata — Tue, 27 Oct 2026 07:02:10 +0000

California county parks are inexpensive and varied, but the details change park to park: parking fees, dog rules, hours, and temporary closures. A two-minute check saves a lot of frustration.

1. Start with the county

Rules differ by county, because each county parks agency sets its own. A browsable directory such as Parks by County, a California county parks guide organizes parks by county and city so you can see your options side by side. Seven counties are covered: Santa Clara, Alameda, San Mateo, Contra Costa, Orange, San Diego, and Los Angeles.

2. Check the four things that vary most

Parking or entry fee. Many county parks charge per vehicle, and some are free. A figure like $6 per vehicle is common at some Bay Area parks, but not universal.
Dog rules. Options range from not allowed, to leashed on selected trails, to designated off-leash areas.
Hours. Typically 8 a.m. to sunset, but some parks close seasonally.
Closures and notices. Playgrounds, trails, and boat ramps close for construction, rain, or inspections. ## 3. Use the statewide overview

If you are choosing between regions, the California county parks overview is a good starting page. From there, you can drill into a county and then a single park.

4. Always confirm with the agency

An independent guide can only summarize. The managing agency has the final word, especially on fees and temporary closures. Look for a link to the official park page and read any current notice at the top.

5. Pack for the rules

If dogs are allowed on a leash, bring a leash that is short enough and water for the dog. If a park charges per vehicle, carpool to save. If trails open at sunrise but the gate opens later, plan around the gate.

A simple routine

Pick the county.
Open the park page and read fee, dog, and hours lines.
Read any closure notice.
Click through to the official page to confirm.
Go.

That is all it takes to avoid most park-day surprises.

Estimating Resin for Molds and Coasters in JavaScript: Volume, Density and Waste

Agoes Jayanata — Sun, 25 Oct 2026 05:07:09 +0000

Most volume calculators assume a box. Resin molds are rarely boxes: coasters have rounded corners, dice molds are cubes with pips, and silicone trays taper. While building a small resin estimator I ended up with three tiny functions that cover almost every craft mold. Here they are, with the reasoning behind each.

1. Regular shapes: compute volume, then convert to mass

Resin is sold by volume (ml, fl oz) but often mixed by weight. Keep everything in cubic centimetres internally and convert at the edges.

const shapes = {
  cylinder: ({ d, h }) => Math.PI * (d / 2) ** 2 * h,   // round coaster
  box: ({ l, w, h }) => l * w * h,                      // square coaster, bar mold
  roundedSquare: ({ s, r, h }) =>                       // square with corner radius r
    (s * s - (4 - Math.PI) * r * r) * h,
};

function resinNeeded(shape, dims, count = 1, wastePct = 10) {
  const cm3 = shapes[shape](dims) * count;               // 1 cm3 = 1 ml
  return cm3 * (1 + wastePct / 100);
}

// six 10 cm round coasters, 0.6 cm deep
resinNeeded('cylinder', { d: 10, h: 0.6 }, 6); // ≈ 311 ml

Six 10 cm coasters at 6 mm need about 283 ml of resin before waste and roughly 311 ml after a 10% allowance for the cup and stir stick. That 10% is not decorative: resin clings to every surface it touches, and a mixing cup alone can hold back 5–10 ml.

2. Irregular molds: measure with water

For anything with pips, carvings or organic edges, geometry is a trap. The reliable method is water displacement, and it maps neatly to code:

// weigh the empty mold, fill with water, weigh again
function volumeFromWater(gramsEmpty, gramsFull) {
  return gramsFull - gramsEmpty;   // water ≈ 1 g/ml
}

Dry the mold completely before pouring, since even a drop of water can cloud epoxy.

3. Volume to weight and to A/B parts

Epoxy densities usually fall between 1.08 and 1.15 g/ml. If your kit mixes 1:1 by volume but you measure on a scale, convert first:

function splitParts(totalMl, ratio = [1, 1], density = 1.1) {
  const sum = ratio[0] + ratio[1];
  const grams = totalMl * density;
  return {
    totalGrams: Math.round(grams),
    partA: Math.round((grams * ratio[0]) / sum),
    partB: Math.round((grams * ratio[1]) / sum),
  };
}

splitParts(311);           // { totalGrams: 342, partA: 171, partB: 171 }
splitParts(311, [2, 1]);   // 2:1 system

One caveat: when a kit specifies 1:1 by volume, part A and part B often have slightly different densities, so the gram split is not exactly 50/50. Read the technical data sheet and use the by-weight ratio it lists if there is one.

4. Depth limits matter more than volume

The other mistake the calculator catches is pour depth. A coating resin poured 2 cm thick in a deep mold can overheat, yellow or crack. A simple guard:

function lifts(depthCm, maxPourCm) {
  return Math.ceil(depthCm / maxPourCm);
}
lifts(5, 2); // 3 separate pours

Try the full versions

I put the finished logic, with unit switching and presets, into two free tools: a resin mold calculator for any shape or water-measured mold, and a resin coaster calculator that handles sets, rounded corners and waste.

The takeaway for anyone building estimators: keep the model small, give the user a measurement escape hatch (water displacement), and always show the waste allowance explicitly so it can be tuned. A calculator that hides its assumptions gets ignored the first time it is wrong.

Calculating Pool Volume for Rectangles, Circles and Ovals in JavaScript

Agoes Jayanata — Sat, 24 Oct 2026 14:23:00 +0000

If you've ever shocked a pool, balanced its chemistry, or ordered a fresh bag of salt for a salt-chlorine system, you already know the rule: the dose depends on the volume, and the volume depends on the shape. Swimming pools come in rectangles, circles, and ovals, and each one has its own volume formula. The good news is that they all collapse into a single area × average depth pattern, and a few lines of JavaScript are enough to cover every case a DIY calculator will meet.

The first detail that trips people up is depth. Most pools slope from a shallow end to a deep end, so a single depth number doesn't describe the water. The standard fix is to average the two:

averageDepth = (shallowDepth + deepDepth) / 2

Use that average everywhere in the rest of the math. For a rectangular pool, the volume in cubic feet is straightforward:

volumeFt3 = lengthFt * widthFt * averageDepthFt
Pool chemicals and fill rates are in gallons, not cubic feet. One cubic foot of water equals 7.48 gallons, so:

gallons = volumeFt3 * 7.48

A circle is a rectangle with a different area. The surface area is π × radius², and the radius is half the diameter:

volumeFt3 = Math.PI * radiusFt * radiusFt * averageDepthFt

An oval (or ellipse) is the tricky one. The exact area of an ellipse is π × semiMajor × semiMinor, which in pool math is almost always rewritten with the 0.785 approximation factor:

area ≈ 0.785 * lengthFt * widthFt

The 0.785 is π/4, and it converts a length × width rectangle into the ellipse's area. Multiply by average depth and you have the volume:

volumeFt3 = 0.785 * lengthFt * widthFt * averageDepthFt
That lets you write one JavaScript function that covers every shape:

function poolVolumeGallons(shape, dimensions, shallowDepthFt, deepDepthFt) {
  const avgDepth = (shallowDepthFt + deepDepthFt) / 2;
  let volumeFt3;
  if (shape === 'rectangle') {
    volumeFt3 = dimensions.length * dimensions.width * avgDepth;
  } else if (shape === 'circle') {
    const r = dimensions.diameter / 2;
    volumeFt3 = Math.PI * r * r * avgDepth;
  } else if (shape === 'oval') {
    volumeFt3 = 0.785 * dimensions.length * dimensions.width * avgDepth;
  }
  return volumeFt3 * 7.48;
}

A 16 ft × 32 ft oval, 3 ft shallow and 9 ft deep:

poolVolumeGallons('oval', { length: 32, width: 16 }, 3, 9)
≈ 0.785 × 32 × 16 × 6 × 7.48 ≈ 18,160 gallons

The pool volume calculator walks through this exact pattern for each shape, including the average-depth step.

Salt Dosing From the Volume

Once you trust your gallon count, chemistry becomes straightforward. The most common calculation is salt dosing for a salt-chlorine generator. The formula the industry uses is:

pounds of salt = gallons × ppmDifference × 8.34 / 1,000,000

The 8.34 is the weight of a gallon of water in pounds (water weighs about 8.34 lb/gal), and the 1,000,000 converts the parts-per-million ratio into actual pounds. In JavaScript:

function saltPoundsNeeded(gallons, currentPPM, targetPPM) {
  const ppmDiff = targetPPM - currentPPM;
  if (ppmDiff <= 0) return 0;
  return (gallons * ppmDiff * 8.34) / 1e6;
}

saltPoundsNeeded(18160, 1500, 3500) ≈ 308 pounds

For the 18,160-gallon oval above, raising salinity from 1,500 ppm to 3,500 ppm calls for about 308 pounds of salt. Note the guard clause: if the current reading is already at or above the target, the function returns zero instead of a meaningless negative number.

A 10,000-gallon rectangular pool that's at 2,500 ppm and needs 3,500 ppm only needs roughly 83 pounds. Same formula, different volume — which is exactly why getting the volume right matters more than memorizing the salt constant.

Wrapping Up

Pool volume is one of those calculations where the math is honest and the mistakes are human: measure the shallow and deep ends separately, average them, pick the right shape factor (1.0 for rectangles, π for circles, 0.785 for ovals), multiply through, and convert at the end with 7.48. Get the gallons right and every downstream dose — shock, algaecide, pH adjuster, salt — scales from the same number.

If you're putting a pool calculator together, the single poolVolumeGallons function above is a clean start. Add the salt dosing helper next, and you already cover the two questions pool owners ask most often. The pool volume calculator and salt pool calculator show the worked-out versions, including the average-depth step and the ppm-guard clause.

Board Feet and Cubic Yards: Two Tiny Unit Functions Every DIY Calculator Needs

Agoes Jayanata — Sat, 24 Oct 2026 14:20:39 +0000

If you've ever built a deck, framed a shed, or ordered concrete for a patio, you've probably reached for a calculator at some point. DIY calculators are useful, but the unit conversions behind them follow the same small patterns every time. Two of the most common are board feet, which measure lumber, and cubic yards, which measure bulk materials like dirt, mulch, and concrete.

Both reduce to a tiny formula and a few lines of JavaScript. Below I'll show one function for each, the gotchas that make the difference between a clean build and a truckload of waste, and links to ready-made calculators you can try.

Board Feet

A board foot is the standard unit for pricing lumber in the U.S. It represents a piece of wood 1 inch thick, 12 inches wide, and 12 inches long — exactly one cubic foot of volume expressed in lumber terms. The formula is simple:

board feet = thickness(in) × width(in) × length(ft) / 12

In JavaScript it becomes a single function:

function boardFeet(thicknessIn, widthIn, lengthFt) {
  return (thicknessIn * widthIn * lengthFt) / 12;
}

Call it with the actual measured dimensions, not the label on the sticker. A "2×4×8" stud is sold by its nominal size, but a dressed 2×4 is closer to 1.5 inches by 3.5 inches thick. Using the nominal 2 and 4 would overstate your board feet and make your takeoff look cheaper than it really is.
For example, a true 2×4 that is 1.5 in thick, 3.5 in wide, and 8 ft long:

boardFeet(1.5, 3.5, 8) → (1.5 × 3.5 × 8) / 12 = 3.5 board feet

If you used the nominal 2 and 4 instead, you'd get 5.33 board feet — over 50% more. That's why every serious lumber takeoff uses actual dimensions.

A worked-out version lives in this board foot calculator, which walks through the thickness, width, and length step by step.

Cubic Yards

Cubic yards is how ready-mix concrete, topsoil, and mulch are sold. The formula starts in feet and divides by 27, because one cubic yard equals 27 cubic feet (3 ft × 3 ft × 3 ft):

cubic yards = length(ft) × width(ft) × depth(ft) / 27
The JavaScript version is equally short:

function cubicYards(lengthFt, widthFt, depthFt) {
  return (lengthFt * widthFt * depthFt) / 27;
}

A 12 ft × 8 ft patio poured 4 inches deep (0.333 ft):

cubicYards(12, 8, 0.333) ≈ 1.18 cubic yards

Here's where beginners trip up. You don't order 1.18 yards of concrete — suppliers deliver by the yard and you want a little extra for spill, windrows, and form variation. The standard practice is to round up to the nearest tenth or a quarter-yard and add 5-10% for waste:

function yardsToOrder(lengthFt, widthFt, depthFt, wastePct = 0.1) {
  const exact = cubicYards(lengthFt, widthFt, depthFt);
  return Math.ceil((exact * (1 + wastePct)) * 10) / 10;
}

yardsToOrder(12, 8, 0.333) → 1.3 cubic yards

The / 27 is the entire math; everything else is the real world. A complete walk-through is in this cubic yard calculator, including inch-to-feet depth conversion.

Why These Two Together

Board feet and cubic yards show up on almost the same job. You'll calculate board feet for the framing, then cubic yards for the footing concrete that holds it. Both formulas are one multiplication chain and one division; the judgment calls — actual vs nominal dimensions, and rounding up for purchase — are what separate a useful calculator from a dangerous one.

If you're building a DIY estimator, start with these two functions. Keep thickness, width, and length in their native units so the function signature tells you the unit at the call site, and round up on anything the customer pays for. You can try the board foot calculator and cubic yard calculator side by side to see how the same pattern repeats across different materials.

Building a Multilingual Calculator Site: Metric vs Imperial Unit Handling (epoxy example)

Agoes Jayanata — Sat, 24 Oct 2026 12:29:17 +0000

When a calculator spans languages, unit systems and rounding rules collide with locale conventions. A single input — "how much epoxy do I need?" — might be answered in millimetres and litres in Munich, inches and US gallons in Houston, or centimetres and litres in São Paulo. Behind the scenes you want one source of truth so you don't end up with six different volume formulas diverging over time.

The approach that keeps things maintainable is simple in principle and a little fiddly in practice: store every value internally in SI units (metre, kilogram, second, litre) and only convert at the UI edge. The conversion layer becomes a thin, testable adapter between the user's units and the model, and the rest of your code never thinks about inches or gallons again.

SI as the internal model

In a material-estimation tool like Epoxy Planner, the model is just a few numbers: area, thickness, coverage rate, and the resulting volume. Pick SI once and commit.

Length: metre (m). The user may type millimetres for a floor coating thickness — convert to metres the moment the value enters the model.
Area: square metre (m²). Surface-area inputs in square feet convert to m² at the input; the calculator never sees ft².
Volume: litre (L). A US user enters gallons; multiply by 3.78541 and store litres.

The rule of thumb: the conversion constant lives next to the input control, not inside the formula. That way your coverage-rate math is area_m2 * thickness_m * 1000 = litres, and it stays the same whether the input panel is German or English.

Converting at the UI edge

Define a small conversion map and use it consistently for input and display. Here is a minimal example covering the units a coating calculator typically needs:

const TO_SI = {
  length: { mm: 1e-3, in: 0.0254, ft: 0.3048, m: 1 },
  area:   { ft2: 0.092903, m2: 1 },
  volume: { 'gal-US': 3.78541, L: 1 },
};

function toSI(value, from) {
  return Object.entries(TO_SI).reduce((best, [category, units]) => {
    if (units[from] !== undefined) {
      best[category] = value * units[from];
    }
    return best;
  }, {});
}

// 20 mm film → metres, 500 sq ft → m², 5 US gal → litres
console.log(toSI(20, 'mm'));     // { length: 0.02 }
console.log(toSI(500, 'ft2'));   // { area: 46.4515 }
console.log(toSI(5, 'gal-US'));  // { volume: 18.92705 }

Going the other way, display units are derived by dividing by the same constant. Because you only touch the conversion table, adding a new unit (say, imperial gallons) is a one-line change and the formula code is untouched.

Be aware of the direction mismatch for area and volume: ft² → m² uses 0.092903, but m² → ft² divides by that constant (≈10.7639). Using the same table with division works cleanly as long as you don't accidentally multiply by the "to SI" factor on the way out — a common off-by-one-constant bug.

Locale-aware number formatting

Once the calculator hands back litres, you have to render them for the user. In Western Europe and Latin America a comma is the decimal separator, and a dot groups thousands. Intl.NumberFormat handles this without you shipping locale tables.

function formatForLocale(value, locale) {
  const fmt = new Intl.NumberFormat(locale, {
    minimumFractionDigits: 2,
    maximumFractionDigits: 4,
  });
  return fmt.format(value);
}

// 18.927 litres shown differently in Germany and Brazil
console.log(formatForLocale(18.92705, 'de-DE')); // "18,93"
console.log(formatForLocale(18.92705, 'pt-BR'));  // "18,93"
console.log(formatForLocale(18.92705, 'en-US'));  // "18.93"

The locales where a decimal comma matters for this kind of site include de, fr, es, it, and pt-BR. Round-trip carefully on input: if you let the user type into a number input, browsers already handle the locale separator, but a free-text field needs Number(str.replace(',', '.')) before conversion, otherwise "3,5" parses as 3 in JavaScript and silently truncates the order.

When Epoxy Planner localised the calculator, the German epoxy floor calculator at the German epoxy floor calculator URL needed the comma, and the Brazilian Portuguese version needed it too — the difference was in word order, not the decimal mark.

hreflang alternates

Search engines won't serve a French user a page formatted for US conventions if you tell them the relationship between your locale pages. Emit hreflang link elements for every language variant, plus an x-default:

<link rel="alternate" hreflang="de" href="https://epoxyplanner.com/de/..." />
<link rel="alternate" hreflang="fr" href="https://epoxyplanner.com/fr/..." />
<link rel="alternate" hreflang="es" href="https://epoxyplanner.com/es/..." />
<link rel="alternate" hreflang="it" href="https://epoxyplanner.com/it/..." />
<link rel="alternate" hreflang="pt-br" href="https://epoxyplanner.com/pt-br/..." />
<link rel="alternate" hreflang="x-default" href="https://epoxyplanner.com/" />

Two implementation notes that bite in practice. First, every alternate page must link back to every other alternate, including itself — a missing self-link is the most common hreflang audit finding. Second, the path prefix you choose (/de/, /fr/, /es/, /it/, /pt-br/) is what shows in the URL and in search results, so keep it stable. Switching from /pt/ to /pt-br/ mid-project forces a redirect chain that dilutes ranking.

Rounding rules for material orders

Coverage math is continuous; epoxy kits are discrete. A calculator that prints "18.93 L" is misleading when the store sells 5 L buckets and 20 L drums. The business rule for material orders is almost always "round up to the next available kit size," never round to nearest and never round down.

A clean way to implement this is a small ceilToKits helper that returns both the kit breakdown and the true purchase volume:

function ceilToKits(litres, kitSizes = [20, 5, 1]) {
  let remaining = litres;
  const kits = [];
  for (const size of kitSizes) {
    const count = Math.ceil(remaining / size);
    if (count > 0) {
      kits.push({ size, count });
      remaining = 0;
      break;
    }
  }
  const purchasedLitres = kits.reduce((sum, k) => sum + k.size * k.count, 0);
  return { kits, purchasedLitres, waste: purchasedLitres - litres };
}

// 18.93 L → one 20 L kit, 1.07 L over-pour
console.log(ceilToKits(18.92705));

Notice how the input to the function is still the SI value (litres). The kit sizes are business data, not unit data, so they live in product config, not in the converter. This separation is what lets you change from "5 L / 20 L" buckets to "1 gal / 5 gal" pails for a US variant by swapping one config array instead of rewriting the coverage math.

Putting it together

The architecture that survives localisation looks like this:

Input adapter — reads the user's unit selector, parses the locale-aware number, calls toSI, hands an SI value to the model.
Model — coverage formula in metres, square metres and litres. No units, no locale, no rounding.
Output adapter — takes the litres, runs ceilToKits with the regional kit catalog, then Intl.NumberFormat with the page locale for display.

Every layer has a single responsibility and a clear contract. The converter only knows unit constants, the model only knows arithmetic, and the formatter only knows locales and kit sizes.

For a worked-through example of this pattern in a real product, see Epoxy Planner — the same coverage model powers the English, the German epoxy floor calculator, and the Brazilian Portuguese version, differing only at the UI edge.

Takeaways

Store values in SI internally; convert at the UI edge so the formula never changes.
Keep your toSI / fromSI table small and test the inverse explicitly — area and volume factors invert, they don't mirror.
Use Intl.NumberFormat for every locale that writes decimals with a comma (de, fr, es, it, pt-BR), and normalise input before parsing.
Emit a complete, self-linking hreflang set for /de/, /fr/, /es/, /it/, /pt-br/ and an x-default.
Round material orders up to kit sizes with a dedicated helper; treat kit sizes as product config, not units.

Coding a Voltage Drop and Wire Size Calculator in JavaScript

Agoes Jayanata — Thu, 22 Oct 2026 17:07:02 +0000

When you're designing a branch circuit or sizing the conductors for a panel feed, the conversation quickly narrows to one question: how much voltage is going to disappear between the source and the load, and what wire size will keep that drop acceptable? Electrical codes and good practice keep circling back to Ohm's law and a single rule of thumb, and it turns out those rules translate almost directly into JavaScript. In this post we'll build the math for a voltage drop calculator and a wire size calculator, work through a real example, and write a short function that picks the smallest American Wire Gauge (AWG) size that keeps voltage drop under the familiar 3 percent guideline.

Ohm's law and the voltage drop idea

Ohm's law is the starting point: V = I × R. Voltage (V) equals current (I) multiplied by the resistance (R) of the path. In a real circuit the conductors themselves have resistance, so some of the source voltage is used up just getting power to the load. That lost voltage is the "voltage drop," and if it gets too large the load — a motor, a light, an outlet — won't perform as designed.

The National Electrical Code (NEC) doesn't mandate a single number, but it recommends in Informational Note No. 2 of 210.19(A)(1) that the branch-circuit voltage drop not exceed 3 percent. Many designers also budget 3 percent for the feeder, so the total end-to-end drop stays under about 6 percent. For this calculator we'll target that 3 percent guideline on the branch circuit.

The single-phase voltage drop formula

For a single-phase circuit (the kind that comes from a typical 120 V or 240 V residential service) the voltage drop is computed as:

VD = 2 × K × I × L / CM

where:

VD is the voltage drop in volts,
2 accounts for the round trip (hot and neutral),
K is the resistivity constant of the conductor material — approximately 12.9 for copper at around 75 °F (the NEC and many handbooks use this value for copper),
I is the current in amperes,
L is the one-way length of the run in feet,
CM is the cross-sectional area of the conductor in circular mils.

A few quick notes: the factor of 2 is what makes single-phase different from three-phase. Three-phase uses √3 instead of 2 and drops the neutral-return path. The K value of 12.9 is an approximation — actual resistance depends on temperature and the precise alloy — but it's the number that shows up in tables and calculators everywhere, and it's what we'll hard-code in the snippet.

Circular mils and the AWG table

Wire size in North America is specified by the AWG system, and in that system the physical cross-section is expressed in circular mils (CM). A circular mil is the area of a circle one mil (0.001 inch) in diameter. The higher the AWG number, the thinner the wire and the smaller the CM value.

For a voltage drop calculator we only need a small lookup table of the most common sizes. Here are representative values:

AWG	Circular mils (CM)
14	4,110
12	6,530
10	10,380
8	16,510
6	26,240
4	41,740
3	52,620
2	66,360
1	83,690
1/0	105,600

These are the standard values you'll find in the NEC Chapter 9, Table 8. A production wire size calculator usually stores the full table and iterates from 14 AWG upward until the computed drop satisfies the target.

Worked example: 20 A at 120 V over 100 ft

Let's run the numbers for a common case: a 20 A branch circuit feeding a load at the end of a 100 ft one-way run, nominally 120 V, copper conductors, single phase.

First try 12 AWG, whose CM is 6,530.

VD = 2 × 12.9 × 20 × 100 / 6,530
= 51,600 / 6,530
≈ 7.90 V

As a percentage of the 120 V nominal: 7.90 / 120 ≈ 6.58… wait — let me recheck the arithmetic. 2 × 12.9 × 20 × 100 = 51,600. Dividing 51,600 by 6,530 gives about 7.90 V. 7.90 / 120 ≈ 0.0658, which is roughly 6.6 percent.

That's already over the 3 percent guideline. The 3 percent of 120 V is 3.6 V. To stay under 3.6 V we'd need CM ≥ 51,600 / 3.6 ≈ 14,333 circular mils. The next standard size up from 12 AWG is 10 AWG at 10,380 CM — which is still under 14,333 — so let me re-examine.

Actually, let's redo this with a slightly different, more typical current. The example that illustrates the upsize decision most cleanly uses a load closer to what a 12 AWG branch actually carries. Let's recompute 12 AWG at the same 100 ft but confirm the voltage drop, then check 10 AWG.

For 10 AWG (CM = 10,380):
VD = 51,600 / 10,380 ≈ 4.97 V, which is 4.97 / 120 ≈ 4.14 percent.

Still over 3 percent. So at 20 A over 100 ft, even 10 AWG doesn't quite hit 3 percent with K = 12.9. The message here is the important one: 12 AWG gives roughly 6.6 percent drop, which is unacceptable, and upsizing to 10 AWG improves it to about 4.1 percent — a real reduction, but you may still want to consider an even larger conductor, a shorter run, or a higher voltage.

That said, the pattern most designers see in practice — and the one we'll use to motivate the code — is that 12 AWG often lands you right around 3 to 4 percent on moderate runs and upsizing one step to 10 AWG brings you under the guideline. A calculator makes the trade-off explicit instead of guessing. If you want a more generous K that reflects higher temperature, the numbers shift, which is another reason to let the code do the comparison.

Picking the smallest AWG under 3 percent in JavaScript

The voltage drop calculator at FixupMath evaluates the formula and compares the result to the target. We can do the same in a short function that walks the AWG table from the smallest conductor upward and returns the first one whose drop is at or below 3 percent of the source voltage.

// Circular mils for common AWG sizes (NEC Ch. 9, Table 8)
const AWG = [
  { awg: 14, cm: 4110 },
  { awg: 12, cm: 6530 },
  { awg: 10, cm: 10380 },
  { awg: 8,  cm: 16510 },
  { awg: 6,  cm: 26240 },
  { awg: 4,  cm: 41740 },
  { awg: 3,  cm: 52620 },
  { awg: 2,  cm: 66360 },
  { awg: 1,  cm: 83690 },
  { awg: 1/0, cm: 105600 }
];

const K_COPPER = 12.9; // single-phase copper constant
const PHASE_FACTOR = 2; // round-trip for single-phase

function voltageDropVolts(currentA, lengthFt, cm) {
  return (PHASE_FACTOR * K_COPPER * currentA * lengthFt) / cm;
}

/**
 * Returns the smallest AWG entry whose voltage drop is under
 * maxDropPercent percent of nominalVoltage.
 * Returns null if no size in the table is sufficient.
 */
function smallestAwgUnderPercent(
  currentA,
  lengthFt,
  nominalVoltage,
  maxDropPercent = 3.0
) {
  const maxDropVolts = (maxDropPercent / 100) * nominalVoltage;

  for (const entry of AWG) {
    const drop = voltageDropVolts(currentA, lengthFt, entry.cm);
    const percent = (drop / nominalVoltage) * 100;
    if (drop <= maxDropVolts) {
      return { awg: entry.awg, cm: entry.cm, dropVolts: drop, dropPercent: percent };
    }
  }
  return null;
}

// Example: 20 A at 120 V over 100 ft
const result = smallestAwgUnderPercent(20, 100, 120);
if (result) {
  console.log(`Pick ${result.awg} AWG: ${result.dropVolts.toFixed(2)} V  (${result.dropPercent.toFixed(1)}%)`);
} else {
  console.log('No standard size in the table keeps drop under 3%. Upsize or shorten the run.');
}

With current = 20, length = 100, and nominal = 120, the loop tries 14, 12, 10, 8… and returns the first entry whose drop is ≤ 3.6 V. Because even 10 AWG drops about 4.97 V at those inputs, this particular call would walk all the way to 8 AWG (CM = 16,510 → drop ≈ 3.12 V, ≈ 2.6 percent) and return 8 AWG. The point is the pattern: start small, compute, upsize until you satisfy the guideline. If the table runs out before you satisfy it, the function signals that explicitly rather than silently picking an undersized wire.

If you prefer a different K, a three-phase factor, or a stricter 2 percent target for sensitive equipment, you pass those in as parameters instead of hard-coding. That's the whole design philosophy of the wire size calculator: the formula is the formula; the constants are the knobs.

Disclaimer

This article and any code or calculator built from it are for educational purposes only. Voltage drop, ampacity, temperature correction, and the choice of conductor are all governed by your local electrical code and by the conditions of the actual installation (ambient temperature, number of current-carrying conductors in a raceway, type of insulation, and so on). Always follow your local code, use the tables and correction factors it references, and have a licensed electrician or qualified authority review anything that will be energized. The numbers in this post use K ≈ 12.9 and a limited AWG table as illustrations; a real design may require a different K, parallel conductors, or a three-phase formulation.

The Geometry Behind a Stair Stringer and Rafter Length Calculator

Agoes Jayanata — Thu, 22 Oct 2026 16:38:54 +0000

Framing is just applied geometry. Every stair stringer and every rafter reduces to a right triangle: a vertical rise, a horizontal run, and the hypotenuse that the lumber has to cover. Get the triangle right and the structure works. The stair calculator and rafter calculator at FixUpMath were built with Astro and published free because the math — not a paywall — should be the product. Building either one is a compact project that teaches you integer ceilings, the Pythagorean theorem, and how to turn pitch into a slope ratio in JavaScript.

Stairs: rise and run

A stair is defined by its total rise (the vertical distance from one finished floor to the next) and its total run (how far the run of treads extends horizontally). The code's first job is to turn those into per-step dimensions.

Building codes in the U.S. cap the riser at 7.75 in and typically require a minimum tread run around 10 in. Given a total rise in inches, the number of risers is the ceiling of total-rise divided by the max riser:

function riserCount(totalRiseIn, maxRiserIn = 7.75) {
  return Math.ceil(totalRiseIn / maxRiserIn);
}

Math.ceil again — same reason. If a 90 in rise gives you 11.61 risers, you can't build 11.61 of anything. Twelve risers at 7.5 in each satisfy the code and split the rise evenly. The uniform riser height is then totalRiseIn / riserCount, and the total run is riserCount * treadRunIn.

Stringer length via Pythagoras

A straight-run stringer carries every riser and every tread. Its horizontal projection is the total run; its vertical projection is the total rise. The cut length along the hypotenuse is:

function stringerLength(totalRiseIn, totalRunIn) {
  return Math.sqrt(totalRiseIn ** 2 + totalRunIn ** 2);
}

That's the theoretical length. In practice you add a few inches for the heel cut, the toe cut, and the bottom notch — and you buy the 2×12 a foot or two longer than the computed hypotenuse. In UI terms, show the computed length and the recommended purchase length separately so the user can see where the extra came from.

Rafters: span and pitch

A rafter is the same shape of problem. You know the span (the horizontal distance the roof covers) and the pitch (rise per 12 in of run, written as a ratio like 6/12). A 6/12 pitch means the roof rises 6 in for every 12 in it runs.

Half the span is the horizontal run the rafter covers. The rise over that run is pitchRatio * halfSpan, and the rafter length is the hypotenuse:

function rafterLength(spanIn, pitchNumerator, pitchDenominator = 12) {
  const halfSpan = spanIn / 2;
  const rise = (pitchNumerator / pitchDenominator) * halfSpan;
  const rafter = Math.sqrt(halfSpan ** 2 + rise ** 2);
  return { rafter, rise, halfSpan };
}

Return an object, not a single number. The rise and half-span are the intermediate values the user needs to audit, and the rafter length is the number that goes on the cut list. For a 28 ft (336 in) span at 6/12: half-span 168 in, rise 84 in, rafter ≈ 189.7 in (about 15 ft 9.7 in).

Where the code trips

Three edge cases show up repeatedly:

Riser count rounding. Always Math.ceil. A 7.74 in riser is still a code-compliant answer only if every riser is ≤ 7.75 in, and Math.round can produce a taller riser that fails inspection.
Pitch normalization. Let the user type "6/12" or just "6" and normalize it. A bare number is conventionally "N over 12". Label the assumption.
Units. Stair users think in inches; roofers often think in feet for the span. Convert at the boundary and keep one canonical unit (inches) inside the math.

Putting a stair + rafter example together

A deck stair with a 96 in total rise, 10 in treads:

risers = ceil(96 / 7.75) = 13
uniform riser = 96 / 13 ≈ 7.38 in
total run = 13 × 10 = 130 in
stringer = sqrt(96² + 130²) ≈ 161.8 in (buy a 2×12 in 14 ft)

A gable roof, 24 ft (288 in) span at 8/12:

half-span = 144 in
rise = (8/12) × 144 = 96 in
rafter = sqrt(144² + 96²) ≈ 173.2 in (about 14 ft 5.2 in)

Why this matters

Right-triangle calculators are small enough to finish in an afternoon and real enough to matter. They teach the same pattern that comes up everywhere in tooling code: decompose the geometry, compute the intermediates, round the units that have to be whole, and show the user the work. The stair calculator and rafter calculator are free, built with Astro, and a reasonable reference if you're practicing the pattern.

Building Unit-Aware Construction Calculators: From Cubic Yards to 80-lb Bags

Agoes Jayanata — Thu, 22 Oct 2026 16:35:38 +0000

Construction work lives inside units. A driveway is measured in feet and inches, poured in cubic yards, and bought in 80-lb bags of premix. Get the unit conversions wrong and you either short the job or waste money on bags that sit in the truck bed. The FixUpMath calculator suite was built with Astro and published free, because the math — not a paywall — should be the product. Building a calculator like this is a small project that teaches you real things: input parsing, dimensional analysis, and defensive rounding.

Parsing ft/in/metric input

A box labeled "Length" might receive 12 ft 6 in, 12'6", 3.81 m, or just 12. Your parser has to decide the unit and return a single number in a canonical unit — usually feet for imperial, meters for metric.

A pragmatic approach is to match a compound imperial pattern first, fall back to a single number with a unit suffix, and treat a bare number as feet. Here's a starting point:

function parseLength(input) {
  const s = input.trim().toLowerCase();

  // "12 ft 6 in" / "12'6""
  const compound = s.match(/(\d+\.?\d*)\s*(ft|'|feet?)\s*(\d+\.?\d*)\s*(in|"|inch)?/i);
  if (compound) {
    const feet = parseFloat(compound[1]);
    const inches = parseFloat(compound[3] || 0);
    return feet + inches / 12;
  }

  // "3.81 m"
  const metric = s.match(/(\d+\.?\d*)\s*(m|meters?)/i);
  if (metric) {
    return parseFloat(metric[1]) * 3.28084;
  }

  // "12 ft" or bare "12" (assumed feet)
  const ft = s.match(/(\d+\.?\d*)\s*(ft|'|feet?)$/i);
  if (ft) {
    return parseFloat(ft[1]);
  }

  // Bare number → feet
  const bare = s.match(/^(\d+\.?\d*)$/);
  if (bare) {
    return parseFloat(bare[1]);
  }

  throw new Error(`Cannot parse length: "${input}"`);
}

Surface the assumption. If you silently treat a bare 12 as feet, say so in the UI with helper text like "No unit? We assume feet." Defensive parsing is a feature, not a bug.

Volume = L × W × T

Once you have length, width, and thickness all in feet, volume in cubic feet is just the product:

function volumeCubicFeet(lengthFt, widthFt, thicknessFt) {
  return lengthFt * widthFt * thicknessFt;
}

The thickness is where most DIYers trip. Bagged concrete for a patio is typically 4 in (0.333 ft); a driveway pour is often 6 in (0.5 ft). Hardcoding thickness without labeling it as an assumption is a bug waiting to happen — surface it in the UI with a dropdown and a default.

Converting ft³ to yd³

Ready-mix concrete is sold by the cubic yard. One cubic yard is 27 cubic feet, so:

function cubicFeetToCubicYards(cuFt) {
  return cuFt / 27;
}

Division by 27 is the canonical trap in calculator code. Write it as a named constant (const CU_FT_PER_CU_YD = 27) so the magic number can be reviewed and so a linter or a reviewer doesn't have to guess what 27 means at 2 AM.

Applying a waste factor

Concrete shrinks, edges spill, and forms leak a little. The industry rule of thumb is to add 5–10% waste. Expose it as a slider so the user can feel the risk:

function applyWaste(yards, wastePercent = 10) {
  return yards * (1 + wastePercent / 100);
}

For a 2.00 yd³ slab at 10% waste you get 2.20 yd³. Round the displayed value, not the intermediate — that's a general numerical hygiene rule that saves a lot of "why is my answer off by one bag?" complaints.

Rounding up to purchasable units: the 80-lb bag

Bagged / premixed concrete is sold by the bag, not by the fraction. A standard 80-lb bag yields roughly 0.6 ft³ (about 0.0222 yd³). You can't buy 0.4 of a bag, so you always round up:

function bagsNeeded(cuYards, cuFtPerBag = 0.6) {
  const cuFt = cuYards * 27;
  return Math.ceil(cuFt / cuFtPerBag);
}

Math.ceil is the most important function in construction calculator code. Math.round will short the job. Math.floor is a budget disaster. Every "how many X do I buy?" question in this domain rounds up.

Putting it together

End-to-end, a patio of 12 ft × 10 ft × 4 in (0.333 ft) thickness:

volume = 12 × 10 × 0.333 = 39.96 ft³
yards = 39.96 / 27 = 1.48 yd³
+10% waste = 1.63 yd³
bags = ceil(1.63 × 27 / 0.6) = ceil(73.35) = 74 bags

Show the user the intermediate values (volume, yards, waste-adjusted) so they can audit the math, and put the bag count in big type at the top.

Why this matters

Unit-aware calculators are a great project for learning input parsing, dimensional analysis, and defensive rounding — and they're genuinely useful. The FixUpMath suite was built with Astro and published free so the math, not the paywall, is the product. If you're playing around with calculator apps, start with concrete: it teaches you parsing, unit conversion, waste factors, and the most important JavaScript function in the construction world — Math.ceil.

Try the live concrete calculator and compare it to your own implementation. The trickiest part isn't the math; it's the edge cases in what a real person will type into a box labeled "Length".

The Math Behind an Epoxy Resin Calculator (with JavaScript)

Agoes Jayanata — Thu, 22 Oct 2026 16:22:04 +0000

Building an epoxy resin calculator sounds simple until you realize the math under the hood spans geometry, unit systems, waste modeling, mix-ratio arithmetic, and multi-layer scheduling. In this post we walk through each calculation and ship 3 short JavaScript functions that power Epoxy Planner, a web tool that turns project dimensions into part quantities. For the full accounting of where every constant comes from, see the methodology page.

1. Volume of the pour

Most pourable epoxies conform to the shape of their container, so the calculator starts by computing volume in cubic inches and later converts to fluid units. Three primitives cover the vast majority of projects.

A rectangular slab (river table, countertop, tray) is length × width × depth. A cylinder (a round table top, a tumbler, a column) is π × r² × height. A sphere (a decorative paperweight, a dome cap) is 4/3 × π × r³.

When a project combines shapes — a rectangular slab with a cylindrical inlay — the calculator sums the primitives. Here is a shape-agnostic volume() that accepts the shape tag and the dimensions the UI collected:

function volume(shape, dims) {
  if (shape === 'rect') {
    return dims.length * dims.width * dims.depth;
  }
  if (shape === 'cylinder') {
    return Math.PI * dims.radius * dims.radius * dims.height;
  }
  if (shape === 'sphere') {
    return (4 / 3) * Math.PI * Math.pow(dims.radius, 3);
  }
  return 0;
}

All dimensions are expected in inches at this stage so every primitive returns cubic inches.

2. Unit conversions

Customers rarely think in cubic inches. The calculator converts to the units they buy resin in. The constants below are what the methodology page publishes.

1 US gallon = 231 cubic inches (exact by US definition)
1 liter = 61.024 cubic inches
1 cubic inch ≈ 16.387 milliliters

A small converter keeps the units tractable:

const CU_IN_PER_US_GAL = 231;
const CU_IN_PER_LITER  = 61.024;
const ML_PER_CU_IN     = 16.387;

function convertVolume(cuIn, to) {
  if (to === 'us_gal') return cuIn / CU_IN_PER_US_GAL;
  if (to === 'liter')  return cuIn / CU_IN_PER_LITER;
  if (to === 'ml')     return cuIn * ML_PER_CU_IN;
  return cuIn;
}

The to argument mirrors the unit selector in the UI. If a user asks for 2.4 liters of a rectangular 12 × 18 × 0.75" slab, volume() produces 162 cu in, convertVolume(162, 'liter') yields ≈ 2.655 L, and the UI rounds up to the nearest available container size.

3. Waste factor and seepage

Real pours consume more resin than the raw volume. Two separate effects are modeled.

A waste factor (typically 5–15%) accounts for pour loss, mixing-container residue, surface cleanup, and the fact that mixing two parts inevitably leaves a small film in each cup. It is applied as a multiplicative factor: total × (1 + waste).

Seepage applies only to porous substrates — raw wood, concrete, green marble — where the substrate soaks up a thin layer of resin. Seepage is modeled as a volume proportional to the exposed surface area times a seepage depth (commonly 0.02–0.05"). A 24 × 36" wood slab with 0.03" seepage on both faces absorbs roughly 2 × 24 × 36 × 0.03 = 51.84 cu in on top of the pour volume.

Both adjustments are additive to the base volume before Part A/B splitting, so the ratio math stays clean.

4. Splitting Part A and Part B by ratio

Most epoxies are two-part systems mixed by volume ratio. 1:1 is the easiest (equal parts resin and hardener). 2:1 is common in cast/resin kits (two parts resin to one part hardener).

Given a total volume V and a ratio expressed as resinParts : hardenerParts, the split is:

A = V × resinParts / (resinParts + hardenerParts)
B = V × hardenerParts / (resinParts + hardenerParts)

In JavaScript:

function splitByRatio(totalVolume, resinParts, hardenerParts) {
  const sum = resinParts + hardenerParts;
  const partA = totalVolume * resinParts / sum;
  const partB = totalVolume * hardenerParts / sum;
  return { partA, partB, ratio: `${resinParts}:${hardenerParts}` };
}

// 1:1 example
splitByRatio(100, 1, 1); // { partA: 50, partB: 50, ratio: '1:1' }

// 2:1 example (two parts resin, one part hardener)
splitByRatio(100, 2, 1); // { partA: 66.67, partB: 33.33, ratio: '2:1' }

After the split, each part's volume is converted to the user's chosen unit and rounded up to the nearest container the supplier sells. That is where many DIY calculators over-order — they round the total once and split, instead of splitting then rounding each component.

5. Splitting deep pours into lifts

Epoxy cures exothermically. Cast pours deeper than the manufacturer's maximum layer depth can crack, yellow, or delaminate, so thick pieces are built in lifts (also called layers or coats).

If a slab needs 3" of depth and the resin's max layer depth is 1", the calculator computes:

liftCount = ceil(totalDepth / maxLayerDepth)
layerDepth = totalDepth / liftCount

The layer volume for each lift is footprintArea × layerDepth. The per-lift volume is what gets passed into waste + ratio + unit conversion, then multiplied by liftCount to arrive at the project total.

This matters for two reasons. First, the calculator can tell the builder how many pours they're scheduling. Second, waste is typically quoted per-pour (each new mix event leaves residue in fresh cups), so modeling waste per lift rather than once on the whole depth usually yields a higher and more realistic total.

Putting it together

A real calculator chains these steps:

Sum volumes across every shape the user added (via volume()).
Add seepage volume if the substrate is porous.
Apply the waste factor to the subtotal.
Split into Part A and Part B via splitByRatio().
If the depth exceeds the max layer depth, recompute per-lift volume, apply waste per lift, split per lift, then multiply by liftCount.
Convert each part to the desired unit via convertVolume() and round up to sellable containers.

That pipeline is exactly what Epoxy Planner runs client-side. If you want the constants, assumptions, and edge cases in writing, the methodology page documents every factor.

For developers who want to drop this into an existing project instead of copying the functions above, the same math is packaged as epoxy-planner on npm — npm install epoxy-planner — with a stable surface that exposes the shape volumes, unit conversion table, ratio splitter, and lift scheduler as plain functions.

Summary

An epoxy calculator is small on the surface and surprisingly deep under it: elementary geometry for the pour, exact and approximate constants for unit conversion, an additive waste/seepage model, proportional split arithmetic for Part A/B, and a ceiling division to turn a deep pour into schedulable lifts. The three functions in this post — volume, convertVolume, and splitByRatio — cover the core. Try them on your next pour, or grab the npm package if you'd rather not re-derive the constants yourself.

How to Calculate a Lottery Annuity Payout in JavaScript (30 Payments, 5% Growth, Taxes)

Agoes Jayanata — Sun, 11 Oct 2026 02:58:53 +0000

When a Powerball or Mega Millions jackpot hits the news, the headline number is the annuity total - the advertised amount you'd receive if you don't take the cash. That total isn't a single check. Under today's rules the lottery pays it out as 30 graduated installments: one payment right away, then 29 more, each year, each exactly 5% larger than the one before.

The cash option for the current jackpot is roughly 41% of the advertised amount, so a winner's choice between the two isn't obvious - it depends on discount rates, taxes, and how the payments are scheduled. Below I'll walk through the math, write a short JavaScript function that produces the full 30-payment schedule from an advertised jackpot and applies a tax rate, and flag the tax details you'd get wrong by guessing.

The 30-payment schedule

The annuity is a growing-annuity. If the advertised jackpot is J and the annual growth rate is g = 5%, the first payment P₁ is chosen so that the 30 payments sum to J:

P₁ + P₁-(1+g) + P₁-(1+g)² + ... + P₁-(1+g)²⁹ = J

That's a geometric series, so:

P₁ - ((1+g)³⁰ - 1) / g  =  J
→  P₁ = J - g / ((1+g)³⁰ - 1)

With g = 0.05 the divisor (1.05³⁰ - 1) is about 56.5, so P₁ is roughly J × 0.05 / 56.5 ≈ 1.505% of the jackpot. Every later payment is just the previous one multiplied by 1.05. For the current $516 M Powerball jackpot the first payment works out to about $7,766,541 and the final one to about $31,968,134 (before tax), and the 30 payments add back to the full $516 M. You can verify the numbers for any current jackpot on the Powerball annuity calculator, which also converts the annuity into today's dollars at a discount rate you pick (4% by default) and shows the break-even return against the cash option.

Taxes - withholding isn't the final answer

Lottery winnings are ordinary income. The tricky part for most winners is the difference between what's withheld and what they actually owe.

When a prize exceeds $5,000 (after subtracting the ticket price), the lottery withholds a flat 24% for federal income tax at claim - that's the rate on the Form W-2G. Withholding is a prepayment, not the final tax. A large prize gets taxed at the ordinary-income brackets that go up to 37%. In 2026 the 37% top bracket kicks in at $640,600 of taxable income for a single filer (per IRS Rev. Proc. 2025-32), so most of a jackpot - and most of each large annuity payment - is taxed at 37% rather than the 24% already sent to the IRS. The balance, plus any state tax not fully withheld, is due when you file.

The annuity's main tax difference versus the cash is timing, not rate. A lump sum is taxed all at once in the year you claim it; annuity payments are taxed as they arrive, one year at a time. State tax comes on top in most states. The top state rates reach about 10.9% (New York) with New York City adding up to 3.876%, while Florida, Texas, Tennessee, Washington and a few others have no state income tax on winnings. The full lottery tax breakdown walks through the 2026 federal and state rules, the per-state withholding rates, and what happens when a prize is shared.

For a back-of-the-envelope estimate you can plug a single flat tax rate into the annuity code below. For anything close to real numbers, tax each payment in its own year and layer state tax the way the linked calculators do.

JavaScript implementation

Here's a compact function that returns the full 30-payment schedule and applies a flat tax rate. It's the same arithmetic used by the jackpot-annuity npm package (open source, by the author of this post).

/**
 * Compute a 30-payment lottery annuity schedule.
 *
 * @param {number} advertisedJackpot - The headline annuity total (e.g. 516_000_000).
 * @param {number} [growthRate=0.05]  - Year-over-year growth of each payment (5%).
 * @param {number} [payments=30]      - Number of payments (Powerball / Mega Millions default).
 * @param {number} [taxRate=0.24]     - Flat tax rate to apply to each payment (withholding).
 * @returns {{payments: Array<{year: number, gross: number, tax: number, net: number}>,
 *            totals: {gross: number, tax: number, net: number}}
 */
function computeAnnuity(advertisedJackpot, growthRate = 0.05, payments = 30, taxRate = 0.24) {
  const factor = (Math.pow(1 + growthRate, payments) - 1) / growthRate;
  const firstPayment = advertisedJackpot / factor;

  let payment = firstPayment;
  const schedule = [];
  let grossTotal = 0, taxTotal = 0, netTotal = 0;

  for (let year = 1; year <= payments; year++) {
    const tax = payment * taxRate;
    const net = payment - tax;
    schedule.push({ year, gross: payment, tax, net });
    grossTotal += payment;
    taxTotal   += tax;
    netTotal   += net;
    payment *= 1 + growthRate; // next year grows by 5%
  }

  return {
    payments: schedule,
    totals:   { gross: grossTotal, tax: taxTotal, net: netTotal }
  };
}

// Example: current $516M Powerball jackpot, flat 24% withholding
const result = computeAnnuity(516_000_000);
console.log("Year 1 gross: ", Math.round(result.payments[0].gross).toLocaleString());
console.log("Year 30 gross:", Math.round(result.payments[29].gross).toLocaleString());
console.log("30-year gross total:", Math.round(result.totals.gross).toLocaleString());

With advertisedJackpot = 516_000_000 and the defaults, year 1 comes out to ~$7,766,541 gross and the 30-year gross total sums back to $516,000,000 - matching the published annuity. Calling it with taxRate = 0.37 shows the closer-to-real federal take on each payment for a single filer whose prize lands in the top bracket.

If you want a ready-made version, npm install jackpot-annuity pulls the open-source package by the author of this post; it exposes the same computeAnnuity logic, plus utilities for discounting the schedule to present value and comparing it against the published cash option.

When the flat rate lies to you

The 24% / 37% gap is the most common mistake. On the current $516 M jackpot taken as cash, about $51 M is withheld at 24% and the winner receives roughly $161.6 M on the daon-srteaalll fjeadcekrpaolt -taankneu iotny e aacnhd pcaaylmle ntj afcokrp oat Asninnugiltey (fjialcekrp owth,o s{e gprroiwzteh :l a0n.d0s5 ,i nt atxhRea tteo:p 0b.r2a4c k}e)t`.

tIof gyeotu bwaacnkt tah er eaardrya-ym aodfe 3v0e rgsriaodnu,a tendp mp aiynmsetnatlsl wjiatchk pgorto-sasn,n utiatxy, apnudl lnse tt hfei eolpdesn -psroeucrocmep uptaecdk.a

g#e Wbiyt hthhoel daiuntgh oirs oaf ptrheipsa ypmoesntt;, into te xtphoes efsi ntahle tsaaxm

eT hec ofmlpautt e2A4n%n uiint yth el ocgoidce, apblouvse umtaitlcihteise st hfeo rf eddiesrcaolu n*t*iwnigt hthhoel dsicnhge*d*u lteh attoy they claim - but the estimated federal tax is around $78.6 M, so another ~$27.6 M is due when they file. An annity winner faces the same gap on a smaller scale every year: 24% is taken off each check, and the rest of the tax (up to the 37% bracket) comes due at filing. State tax is layered on top in most states, and for a jackpot the timing difference between lump-sum and annuity is often the deciding factor, not a different rate.

Summary

The advertised jackpot equals the sum of 30 payments, each 5% larger than the last; P₁ = J - 0.05 / (1.05³⁰ - 1).
Federal withholding is 24%, but a large prize is ultimately taxed as ordinary income up to the 37% top bracket (over $640,600 single in 2026); the rest is due at filing.
Annuity payments are taxed year by year; state rates add on top and vary widely.
The snippet above (and the jackpot-annuity npm package) reproduces the schedule from the advertised jackpot and applies a chosen tax rate so you can compare annuity vs. cash yourself.

*Estimates only - not tax or financial advice. For payment-by-payment tax in every state, use the linked calculators.*0r0t,s0 0t0h e- sma