skip to content

Finance wants parcel weights stored in grams instead of kilograms, and your exact packing check is a weight-indexed table; what do you tell them?

level: principalimportance: should knowfreq 33%

answer

  1. one cost responds to a unit change
  2. cells scale with capacity, not parcels
  3. hardness is unchanged by the unit
  4. separate storage precision from working granularity
  5. rounding needs a named error owner

basics

~20 s

That the unit change multiplies the table's width a thousandfold while the depot, the parcel count and the problem's hardness are unchanged. The cost of this method tracks numeric precision, so precision and granularity must be decided deliberately.

solid answer

~40 s

A weight-indexed exact check costs about the item count times the numeric capacity, so moving from kilograms to grams multiplies the work by a thousand without a single extra parcel arriving. Nothing about the problem changed - Partition and Bin Packing were NP-hard before and after; what changed is where your instances sit relative to the pseudo-polynomial bound. The judgment call is threefold: does the extra precision change any packing decision the business actually makes; if not, store grams but round to a working granularity at the point the table is built, with a named owner for the rounding error; and if the precision genuinely matters, this method is the wrong one rather than the unit being wrong. The structural lesson is to stop a storage-precision decision from silently being a compute-budget decision.

code

pseudocode · 10 lines
pseudocode
parcels = 500

capacity_kg = 12000
cells_kg = parcels * capacity_kg          # 6,000,000

capacity_g = capacity_kg * 1000           # 12,000,000
cells_g = parcels * capacity_g            # 6,000,000,000

# same shipment, same 500 parcels, 1000x the work
# the multiplier came from the unit, not from the business

go deeper

for a junior

Recall that a table indexed by total weight has one entry per possible total, so measuring the same parcels in a thousand times finer unit means a thousand times as many entries.

for a middle

Explain the split: the item count enters the cost linearly while the numeric capacity enters it linearly too, and only the second one is multiplied by a change of unit.

for a senior

Demonstrate the diagnosis and the fix: identify that precision rather than volume drives this cost, convert at the component boundary, and state what rounding would make the answer exact about.

for a principal

Own the coupling: a schema's unit choice must not be an undeclared lever on another component's compute budget, and the components whose cost tracks a magnitude should be known and reviewed as such.

## What the unit change actually does The exact check sweeps a table indexed by achievable total weight, so its work is proportional to the item count multiplied by the capacity expressed **in the unit being indexed**. The parcels have not changed, the depot has not changed, the customers have not changed - but the index has been multiplied by a thousand, and so has the table. This is the one cost in the system that responds to a unit of measure. Adding parcels costs linearly. Adding warehouses costs linearly. Changing a unit multiplies. ## What is unchanged It is worth being explicit, because the instinct is to say the problem got harder: - **The classification is identical.** Splitting a load evenly and packing into fixed-capacity containers were NP-hard in kilograms and are NP-hard in grams. Hardness is a property of the problem, not of the unit. - **The physical question is identical.** The same parcels fit into the same containers. - **The item count is identical.** Nothing about `n` moved. What moved is the instance's position relative to the pseudo-polynomial bound. In kilograms the numbers were small enough that a value-indexed method was effectively polynomial on your traffic; in grams they are not. The method's suitability was always a property of the numbers, and the unit is just the dial that sets them. ## The options a lead actually weighs 1. **Challenge whether the precision changes a decision.** If no packing outcome ever differs between a parcel of 2.500 kg and one of 2.4996 kg, the extra digits are real for invoicing and cosmetic for packing. Storing grams and converting at the boundary of the packing component costs nothing and preserves both. 2. **Round deliberately, and name an owner for the error.** If grams are stored, the packing component may still work at a coarser granularity. Then the answer it produces is exact for the rounded instance and only approximately right for the true one, and somebody has to own how much drift is acceptable and where it shows up - a container declared full that has room, or one declared roomy that is over. 3. **Change the method, not the unit.** If the precision genuinely drives decisions, a method whose cost scales with the numeric range is simply the wrong shape for the problem, and that is a design conversation rather than a data-modelling one. 4. **Bound the instance instead.** Often the packing decision is made per shipment, per vehicle or per hour, so the capacity actually indexed is much smaller than a naive global total. Narrowing the instance is frequently the cheapest of the four and the one most often missed. ## The arithmetic, on one shipment | unit | capacity indexed | parcels | table cells | |---|---|---|---| | kilograms | 12,000 | 500 | 6,000,000 | | grams | 12,000,000 | 500 | 6,000,000,000 | Same shipment, same parcels, a thousandfold difference in work. And the growth continues: a later request for milligrams, or for a currency held in a smaller minor unit, would multiply it again. ## The structural lesson The part worth carrying into other systems is the coupling itself. A schema decision - which unit a quantity is stored in - was able to act as a lever on the runtime of an unrelated component. That coupling is invisible in review because the schema change looks like a widening and the algorithm change looks like nothing at all. Two habits defuse it: - **Make the working granularity of a numeric algorithm explicit and separate from storage precision**, converting at the component's boundary so that a change to one is a visible, deliberate change to the other. - **Record which components have a cost that tracks a magnitude rather than a count.** They are rare, and they are exactly the ones a unit or precision change can take down. ## How to say this to finance Not as a refusal. The useful version is: store grams - the invoicing case for it is good and the packing component can work at whatever granularity the packing decision needs. Then ask the question that decides the rest, which is whether any packing outcome is supposed to change because of the extra digits. If the answer is no, the change is a conversion at a boundary. If the answer is yes, the packing component needs redesigning and that belongs on the plan, with the reason stated plainly: this method's cost is set by the precision of the numbers, not by the size of the business.

  • Does storing weights in grams make the packing problem itself harder?
    No. Both the even-split and the fixed-capacity packing questions are NP-hard in either unit; hardness is a property of the problem, not of how its numbers are written. What the unit changes is whether a value-indexed method is affordable on the instances you actually get.
  • If the component rounds weights up to the nearest kilogram before packing, what exactly is it computing?
    An exact answer to a modified instance. Every result is correct for the rounded weights and only approximately correct for the true ones, so the error is a product decision about how much slack or overfill is acceptable, and it needs an owner rather than a comment in the code.
  • What is a cheaper move than either rounding or replacing the method?
    Shrinking the instance. Packing decisions are usually made per vehicle, per shipment or per time window, so the capacity actually indexed is far below any global total. Narrowing what the component is asked about often removes the cost problem without touching precision at all.
  • Which components in a system are vulnerable to this kind of change?
    The ones whose cost is proportional to a magnitude the data carries rather than to a count of things - tables indexed by a total, buckets allocated per unit of range, loops over a numeric span. They are uncommon, which is why a unit change surprises people when it lands on one.

saying these in an interview costs you the question

  • Says the packing problem became harder when the unit changed
  • Treats a storage precision change as having no compute consequence
  • Rounds silently inside the algorithm with nobody owning the error
  • Assumes more parcels, not finer units, is what will break the method
  • Refuses the finer unit outright instead of converting at the boundary