Perimeter Calculator

The calculator's default Shape is Rectangle, and the rectangle branch of the engine's switch(shape) statement computes 2 * (length + width) — a formula that never references the sides variable at all. Because of that, the Number of Sides field stays hidden until Shape is changed to Regular Polygon, where the formula becomes sides × length instead and the field appears.

Part of it is the same starting-value effect you'd see in any additive formula: Length defaults to 10 while Width defaults to 5, so a percentage-based nudge to Length produces a bigger absolute change simply because it starts from a bigger number, not because 2(l + w) weights it any differently. But there's a bigger structural reason Length wins across this whole calculator, not just at the rectangle's defaults: switch to Circle, Equilateral Triangle, or Regular Polygon and Width drops out of the formula entirely — those three branches compute perimeter from Length (read as radius or side) and, for the polygon, Number of Sides, with Width never referenced at all. So Length is the one dimension every shape this calculator supports actually depends on, while Width only ever matters for the rectangle case — a much stronger asymmetry than the additive-formula effect alone would produce.

No. The switch(shape) block only reads Width inside the rectangle case; the circle, triangle, and polygon cases each use only Length (as radius or side length) and, for the polygon, Number of Sides. Leaving Width at a nonzero value while using one of those other shapes has no effect on the computed Perimeter whatsoever.

For Shape = Circle, the engine computes the circumference as 2 * Math.PI * length, treating the Length input as the radius rather than a side length. That is a different physical quantity from every other shape's Length field, which is why the input's own help text labels it "Length / Radius / Side" rather than just "Length."