Matrix Multiplication

What an ordered product means

The product C = A x B is another 3x3 matrix. Its entry cij combines row i of A with column j of B. The row supplies the first three factors and the column supplies the matching second factors. For c12, use a11 with b12, a12 with b22, and a13 with b32. This crossing of one row and one column is the defining pattern. It is why the operation cannot be reconstructed by simply multiplying entries that share the same row and column index in both matrices.

Order is part of the answer. In general, A x B and B x A have different entries even when both matrices have the same square shape. The calculator always evaluates the order shown by the fields and the result label. It does not sort the matrices, choose a more convenient order, or silently use a transpose. If the matrices represent transformations, the input order can correspond to applying one transformation before another, so preserve that order in any external record.

• Each output entry uses one row of A and one column of B.
• The result is an ordered product, not a commutative operation.
• The output remains a 3x3 matrix because both inputs are 3x3.

Reading two row-major matrices

Matrix A is read as [[a11, a12, a13], [a21, a22, a23], [a31, a32, a33]]. Matrix B has the parallel layout with b keys. The first digit is the row, the second digit is the column. To calculate a row-column dot product correctly, do not confuse b12 with b21: one belongs to row one and column two, while the other belongs to row two and column one. Such a swap can produce a plausible finite matrix while answering a different multiplication question.

Every entry is a finite number between -1000 and 1000 inclusive. Direct calls with strings, missing values, not-a-number, infinity, or out-of-range numbers are rejected before any products are formed. The bounds do not describe every matrix that exists; they keep this renderer-facing tool predictable. The example uses the same complete set of eighteen keys as the form, which makes the row and column source of every product auditable.

• Keep the A and B prefixes attached to every position.
• The second index identifies a column, not a second matrix.
• All eighteen entries are validated before multiplication.

The row-column formula

For each i and j from 1 through 3, cij = ai1 times b1j + ai2 times b2j + ai3 times b3j. The first output row therefore contains the dot products of A row one with B columns one, two, and three. After that row is complete, repeat with rows two and three. The engine accumulates each of the three products in a fixed order and checks the product and running sum for finiteness. This explicit loop is the computational form of the mathematical definition.

The same formula explains why zeros can simplify a product without changing the rule. A zero in A row i or B column j removes one term, while a negative pair contributes a positive product and a mixed-sign pair contributes a negative product. The output is the signed sum of all three contributions. No absolute value is appropriate unless a separate norm or magnitude question is being asked.

• Each output cell is a sum of three corresponding row-column products.
• Zeros remove terms but do not change the multiplication rule.
• Signs remain active through both the products and the final sum.

A worked product

Use A = [[1, 2, 3], [0, 1, 4], [5, 6, 0]] and B = [[2, 0, 1], [1, 3, 0], [0, 2, 1]]. For c11, combine A row one and B column one: 1x2 + 2x1 + 3x0 = 4. For c12, use B column two: 1x0 + 2x3 + 3x2 = 12. For c13, use B column three: 1x1 + 2x0 + 3x1 = 4. The first row is therefore [4, 12, 4].

Continuing the same procedure gives row two [1, 11, 4] and row three [16, 18, 5]. The complete result is [[4, 12, 4], [1, 11, 4], [16, 18, 5]]. A reviewer can independently recompute one cell from each row and one cell from each column to catch both arithmetic and indexing mistakes. Checking only c11 is not enough because a transposed B entry may leave the first cell unchanged by coincidence.

• The first output row is [4, 12, 4].
• The second output row is [1, 11, 4].
• The third output row is [16, 18, 5].

Identity, zero, and sign behavior

The 3x3 identity matrix I3 is a two-sided identity for compatible 3x3 products: I3 x A equals A and A x I3 equals A. This is a strong structural test because it checks which entries are taken from each row and column without requiring a special numeric result. The all-zero matrix is absorbing: A x 0 and 0 x A both return the zero matrix. These properties are valid for this fixed square contract and are useful when a product is part of a longer sequence.

Negative entries participate in ordinary signed multiplication and addition. Two negative factors make a positive term; one negative factor makes a negative term. Different terms can cancel, so a zero output cell does not necessarily mean that every contributing product was zero. The engine preserves exact zero where arithmetic produces it and removes negative zero from the returned representation. A matrix with mixed signs is therefore a better test than an all-positive fixture.

• I3 x A and A x I3 should both return A.
• A product with the zero matrix returns the zero matrix.
• A zero cell can result from cancellation among nonzero terms.

Finite arithmetic and bounded powers

With entries bounded by 1000, a direct 3x3 product has only three products and two additions per output cell, so ordinary finite JavaScript arithmetic is ample for the declared input range. The implementation still checks every product and every accumulated sum. This makes the result safe for JSON serialization and prevents a future caller from receiving a nonfinite value without an error. The matrix text formatter receives only finite normalized values.

The same multiplication kernel is used by the matrix-power tool, where intermediate values can grow across repeated products. Its separate exponent contract limits the exponent to an integer from 0 through 12 and places a conservative bound on intermediate arithmetic. Keeping both the input entries and the operation count bounded prevents an apparently simple power request from becoming an unbounded loop or an accidental overflow path.

• Products and running sums are checked individually.
• The direct inputs are bounded before the first row-column product.
• Power calculations reuse bounded multiplication with a finite exponent range.

Related operations are not interchangeable

Elementwise multiplication would calculate aij times bij at the same positions and would produce a different matrix. Scalar multiplication would use one number across all entries. Addition would add corresponding entries. Transpose would exchange indices without multiplying. A norm would reduce the matrix to one number. These operations may appear in the same linear-algebra workflow, but their input pairings and output meanings differ. The product page exposes two matrices specifically so the row-column relationship is visible.

A product can be mathematically defined even when it is not a useful model of a real system. Units must be compatible with the interpretation of matrix multiplication, and transformation conventions must identify which operation is applied first. The calculator cannot infer those conventions from labels such as A or B. Record the intended order and surrounding assumptions when a result is used outside an exercise or a software unit test.

• Elementwise multiplication is a different operation.
• Scalar scaling and addition have different field contracts.
• A real workflow must define units and transformation order externally.

Verification and limits

To verify a product, write the three columns of B explicitly, calculate a representative dot product from each row of A, and compare the result positions. Then test both identity orders, swap A and B when that is meaningful, and confirm that the swapped product is not assumed to match. Use a zero row or zero column to check that the corresponding contributions disappear. Finally, serialize the complete output and inspect that rows, commas, and signs remain in deterministic order.

This calculator does not perform symbolic matrix algebra, infer a dimension, solve a system, calculate eigenvalues, or certify a physical transformation. It needs only numeric entries, so do not add private identifiers or sensitive records to the fields. If the product feeds control, finance, science, graphics, or another consequential process, validate the matrix convention, units, precision, conditioning, and downstream decision separately. A finite product is evidence of arithmetic completion, not evidence that the modeled operation is appropriate.

A product should be named by its operand order before it is calculated. Write A x B and identify which matrix supplies rows and which supplies columns. This is especially important when the two matrices came from different stages of a pipeline and both happen to use the same nine key positions. A later reviewer should not have to infer order from a result that could also have been produced by a different pair or a different convention.

Sparse structure can provide useful checks. A diagonal factor should scale or mix the appropriate rows or columns according to its position, and an identity factor should leave the other matrix unchanged. A zero row in A makes the corresponding output row zero; a zero column in B makes the corresponding output column zero. These are structural consequences of the row-column formula and can expose a loop that accidentally uses a row of B where a column was required.

Cancellation deserves special attention in products. If the three terms in one output cell are large and have alternating signs, a small final value may be correct. Recompute that cell with extra retained precision and inspect each term before deciding that a result of zero is a defect. The handler does not report a condition number or a cancellation warning, so a workflow that depends on small residuals should add a separate numerical review.

When products are chained, retain intermediate matrices in structured form and state whether the next factor acts on the left or right. A product can be finite at each step while still amplifying an input perturbation. The bounded engine protects arithmetic range and loop size, but it does not estimate sensitivity. If small input changes have operational meaning, compare perturbed products and document the scale of acceptable variation outside the pure handler.

A complete product audit can recompute all nine cells from a table of three terms per cell, then compare the table with the deterministic matrix text. Check A x I3, I3 x A, A x 0, and 0 x B, followed by a noncommuting example where swapping factors changes the result. Store the source matrices, order, basis, units, and tolerance policy with the output. That record distinguishes arithmetic correctness from the suitability of the multiplication model.

The field contract is intentionally dense but finite. A product cell has exactly three terms, and every term can be traced to one entry of A and one entry of B. If a future caller wants a larger matrix, it should not reuse the nine-key handler by truncating data. A larger dimension changes the loop, bounds, performance, and often the numerical stability requirements. The fixed 3x3 choice is part of what makes this result easy to audit.

When matrices represent transformations, write down the vector orientation and whether vectors are columns or rows. The same printed product can be read differently under different conventions. The handler uses ordinary mathematical row-column multiplication and does not apply a hidden convention change. This external statement is particularly important when comparing a hand calculation with software produced by another library or storage layer.

A sparse product is not necessarily a sparse result. A zero in one factor removes one path, but other row-column paths can create a nonzero cell. Conversely, cancellation can create a zero result from three nonzero paths. Test both cases explicitly. Looking only at the number of nonzero entries in the inputs is not a reliable way to predict the output pattern without performing the defined dot products.

If the product is used to combine measurements, check whether multiplication of units is intended for every term in each cell. Matrix algebra assumes that the summands in one output cell are compatible quantities. A numerically valid sum of unlike units is not meaningful. The page cannot inspect unit metadata because the fields are deliberately numeric only, so the dimensional audit must occur before or beside the call.

The final acceptance question is whether every output cell used the correct source row, correct source column, three signed products, and two additions. The handler answers that bounded arithmetic question and returns finite deterministic text. Conditioning, units, vector convention, privacy, and the policy attached to a product remain separate responsibilities for the surrounding workflow.

• Check one dot product per row and verify the field positions.
• Use identity and zero matrices as structural fixtures.
• Keep model conventions and downstream validation outside the pure product handler.

Order and composition

Matrix products encode order because the first matrix supplies rows and the second supplies columns. If A and B represent transformations, the product A x B usually means that B acts first under a common column-vector convention, although another convention may reverse that reading. The calculator reports the ordered arithmetic and does not decide which transformation is conceptually first. Record the convention with the matrix names rather than assuming that a product label alone communicates it.

Associativity allows compatible products to be regrouped in exact arithmetic, so (A x B) x C and A x (B x C) agree when all dimensions fit. The M1 page has only two inputs, but a software caller can use its deterministic result as an intermediate. Because floating-point multiplication and addition are not perfectly associative, a long chain can show small representation differences depending on grouping. Preserve the grouping and comparison tolerance when reviewing such a chain.

• A x B and B x A generally differ.
• Transformation order depends on an external vector convention.
• Associative algebra does not remove floating-point grouping differences.

Rows, columns, and data meaning

Each output position has a precise source path. The first output row uses row one of A with all three columns of B. The second output row uses row two of A, and so forth. This makes row and column labels part of the data contract. If a row represents an output channel and a column represents an input feature, the product can be meaningful; if those roles are reversed between the two sources, the same finite arithmetic may not represent the intended composition.

The handler cannot verify units or semantic compatibility. A matrix of lengths cannot automatically be multiplied by a matrix of rates merely because both have nine numeric entries. Before a product is published, identify the dimensions, basis, units, and orientation of both factors. The fixed 3x3 form prevents dimension mismatch at the software level, but it cannot prove that the conceptual dimensions have been matched correctly.

• Every result cell has one row source and one column source.
• Field positions can encode domain roles beyond their numbers.
• Conceptual dimensions and units require external validation.

Precision, cancellation, and comparison

A row-column dot product can contain positive and negative terms that nearly cancel. The final cell may be small even when each product is large, so a displayed zero at a low precision should not automatically be treated as exact zero. The engine keeps the finite numeric sum and normalizes only a true signed-zero representation. If cancellation matters, inspect the underlying numeric result and preserve the intermediate terms in an external audit rather than relying on a rounded matrix label.

Comparing two products should use the same field order, arithmetic convention, and tolerance. If the two matrices are rescaled, the product changes according to both scales. If one factor is transposed, the row-column paths change; a visually similar matrix is not a harmless display variant. The calculator gives no condition estimate and does not decide whether a small product entry is statistically, physically, or operationally negligible.

• Cancellation can make a product cell small without small terms.
• Preserve intermediate products when a near-zero cell matters.
• Use a declared tolerance when comparing product matrices.

A reproducible multiplication record

A reproducible record should store both complete matrices, the ordered expression A x B, the coordinate or basis convention, and the result. Include at least one visible row-column expansion for review, such as c11, but do not assume one cell proves all nine positions. Identity, zero, sparse, mixed-sign, and noncommuting fixtures exercise different structural properties. A reviewer can then distinguish an indexing problem from a scalar arithmetic problem or a mistaken operation choice.

For a software handoff, keep numeric inputs separate from the formatted text matrix and serialize the entire output object. The text is intended for deterministic rendering, while later matrix tools may need the nine individual values. If the product is used for a real transformation, retain the source version, units, precision, and order convention. The page is a finite arithmetic component and does not certify a system, a model, or a consequential decision by itself.

• Store both matrices and the explicit A x B order.
• Include row-column expansions and structural fixtures in review.
• Keep transformation conventions and downstream decisions outside the handler.