General Academic

A scalar is a single number, such as a temperature or a mass. A vector, by contrast, is built from several numbers (its components) and can represent a point or a direction in space. A two-dimensional vector such as (3, 4) can be pictured as an arrow from the origin to that point; its length, or magnitude, is found with the Pythagorean theorem: the square root of the sum of the squared components. For (3, 4), that length is √(3² + 4²) = 5.

Vectors are added or subtracted component by component. Multiplying a vector by a scalar scales every component by that number: multiplying by a value greater than 1 stretches the vector, multiplying by a value between 0 and 1 shrinks it, and multiplying by a negative number reverses its direction while scaling its length by the size of that number.

Two further operations combine two vectors. The scalar (or dot) product multiplies matching components and adds the results, producing a single number equal to |a||b|cos(φ), where φ is the angle between the vectors — so the scalar product is 0 whenever the vectors are perpendicular. The vector (or cross) product, defined for three-dimensional vectors, instead produces a new vector perpendicular to both original ones, with magnitude |a||b|sin(φ); this magnitude equals the area of the parallelogram the two vectors span.

A retailer restocking a product faces two competing costs. Placing an order carries a fixed cost — the same amount of administrative work whether the order is large or small — while holding stock in a warehouse carries a cost per unit per year, driven by things like storage space and the capital tied up in unsold goods. Ordering in large, infrequent batches keeps ordering costs low but raises holding costs, since more stock sits in the warehouse at any given time; ordering in small, frequent batches does the reverse.

The classic model for finding the order size that minimises the combined cost makes a few simplifying assumptions: demand is constant and known in advance, the unit price doesn't change with order size, and there's no limit on available storage or capital. Under these assumptions, stock declines steadily from its post-delivery high of Q down to 0 just before the next order arrives, so the average stock held over time is Q ÷ 2.

The order size that minimises total cost, called the optimal order quantity Q*, is given by Q* = √(2DS ⁄ H), where D is annual demand in units, S is the fixed cost per order, and H is the holding cost per unit per year. Because D and S sit in the numerator and H in the denominator, Q* grows when demand or ordering costs rise, and shrinks when holding costs rise.

A fluid at rest still exerts a force on anything immersed in it, because every layer of fluid has to support the weight of all the fluid sitting above it. The deeper a point lies below the surface, the more fluid is stacked above it, so pressure rises steadily with depth. At the surface itself, the only pressure acting is the weight of the atmosphere above, commonly denoted p0 and equal to roughly 100,000 pascals (about 1 bar) at sea level.

This relationship is captured by the formula p(h) = ρ·g·h + p0, where ρ is the fluid's density, g is the gravitational field strength, h is depth below the surface, and p0 is the pressure already present at the surface. Using the rounded values ρ ≈ 1000 kg/m³ for fresh water and g ≈ 10 N/kg, each extra 10 metres of depth adds roughly 1000 × 10 × 10 = 100,000 pascals — about 1 bar — to the pressure. So a diver 20 metres down experiences roughly 3 bar in total: the 1 bar of atmosphere at the surface plus about 2 bar contributed by the water above.

This same weight-of-fluid idea explains buoyancy. Any object immersed in a fluid has an upward buoyant force pushing on it, equal to the weight of the fluid the object's submerged volume displaces — a relationship usually credited to Archimedes. An object sinks if its own weight exceeds that buoyant force, and it floats if the two balance exactly, which happens once the object has displaced a volume of fluid whose weight equals the object's own weight. A steel ship floats not because steel is light, but because its hull shape displaces a large enough volume of water for the displaced water's weight to match the ship's total weight.

Researchers investigating social phenomena generally choose between two broad strategies. A quantitative, deductive strategy starts from a theory-derived hypothesis about a causal relationship, then tests that hypothesis against standardized data gathered from a reasonably large sample, using statistical analysis to judge whether the pattern holds up better than chance. A qualitative, inductive strategy instead starts from the phenomenon itself, exploring how a causal mechanism actually operates through in-depth case studies, interviews, or sustained observation, and builds or refines theory out of what is found rather than testing a theory decided on in advance.

A typical research project, whichever strategy it leans on, moves through a similar sequence of phases. It begins with problem formulation, where a research question and, for a deductive study, a testable hypothesis are set out. Next comes research design, where the researcher decides how data will be gathered — a structured survey and a sampling frame for a quantitative study, or a choice of cases and an interview or observation protocol for a qualitative one. Data collection and analysis follows, and the project closes with a write-up that interprets the findings and relates them back to the original question.

Real projects often combine both strategies across these phases rather than sticking to just one. A team might begin with a small round of open-ended interviews to work out which factors seem to matter and generate a hypothesis, then move to a large structured survey in a later phase to test that hypothesis statistically across a wider population — using the inductive, case-based strategy to discover a plausible mechanism and the deductive, quantitative one to check how generally it holds.

A beam is a structural member that carries loads applied roughly perpendicular to its length, transferring them to its supports. A simply supported beam rests on two supports — typically a pin at one end, which resists both vertical and horizontal movement, and a roller at the other, which resists only vertical movement — and is otherwise free to bend under load. Because the beam is in equilibrium, the sum of all vertical forces on it must equal zero and the sum of all moments about any point must also equal zero; for a beam of length L carrying a single point load P at its exact midspan, symmetry combined with these equilibrium conditions means each support must carry exactly half the load, P ⁄ 2.

Inside the beam, at any cross-section, an internal bending moment develops that resists the beam's tendency to curve under the load; it can be found by considering the turning effect of all forces on one side of that section. For a point load P at the midspan of a beam of length L, the bending moment is zero at each support, rises linearly along each half of the beam, and reaches its maximum directly beneath the load, where M_max = P·L ⁄ 4. This maximum bending moment is what an engineer checks against a beam's material strength to confirm the beam won't fail.

Loads are not always concentrated at a single point. A uniformly distributed load (UDL), such as a beam's own weight, spreads a total force evenly along the span at an intensity of w per unit length, so the total load W = w·L. For a UDL across the full span of a simply supported beam, the maximum bending moment — again occurring at midspan — is instead M_max = w·L² ⁄ 8, which can be rewritten as W·L ⁄ 8. Comparing the two cases for the same total load W, a point load at midspan produces M_max = W·L ⁄ 4 — twice the maximum bending moment produced by the same total load spread out as a UDL, since concentrating a load at a single point is structurally more demanding than spreading it evenly.

Comparing two algorithms by simply timing them on one computer says little about which is actually better, since results depend on hardware, programming language and implementation details. Computer scientists instead measure an algorithm's time complexity: how the number of basic operations it performs grows as the size of its input, usually written n, increases. Big-O notation expresses this growth as an upper bound while ignoring constant factors and lower-order terms, since these matter far less than the overall shape of the growth curve once n becomes large. An algorithm described as O(1) takes roughly the same number of operations regardless of n; one described as O(n) takes a number of operations roughly proportional to n; and one described as O(n²) takes a number of operations that grows with the square of n.

Searching a list illustrates the difference well. A linear search checks each element in turn until it finds the target or reaches the end of the list, so in the worst case — the target is last, or absent altogether — it must check all n elements, giving it a time complexity of O(n). A binary search instead works only on a sorted list: it compares the target to the middle element and discards whichever half of the list cannot contain the target, repeating this halving on the remaining half until only one element is left. If k is the number of halvings needed to shrink n elements down to 1, then n ⁄ 2^k = 1, so k = log2(n) — meaning binary search's worst-case time complexity is O(log n), a far slower-growing function than O(n).

The gap between these growth rates widens dramatically as n grows larger. Doubling the input size roughly doubles the work an O(n) algorithm must do, since its operation count scales proportionally with n. An O(log n) algorithm, by contrast, only needs one additional halving step to cope with a doubled input, so its operation count barely increases at all. This is why an algorithm with a better (slower-growing) time complexity will always eventually outperform one with a worse time complexity on sufficiently large inputs, no matter how much faster the hardware running the worse algorithm is or how well-optimized its implementation happens to be.