Hi , i was running the lab : C1_W1_Lab_2_linear_systems_as_matrices.
There when calculating determinant , i got that as 0 and error as Singular matrix but when i try to run the same code locally it was not same.
The issue lies in np.linalg.solve(A_2, b_2): because your laptopâs local linear algebra library introduces a floating-point rounding error at the 16th decimal place, the second matrix pivot evaluates to a tiny non-zero value (-10^-16), indicated by -0.000) rather than exact 0.0. Because solve() only raises a LinAlgError when a pivot is strictly zero, it bypasses your except block entirely and divides by that microscopic number instead, returning massive numbers ( 10^17) rather than flagging the matrix as singular.
Both environments are technically correct:
The matrix [[-1, 3], [3, -9]] is truly singular (row 2 is exactly -3 Ă row 1), so the determinant is mathematically zero. But np.linalg.det uses LU decomposition under the hood, and the result depends on which LAPACK/BLAS library your system ships. The Coursera lab environment happens to produce exact 0.0, while your local install (likely a different build of OpenBLAS or MKL) lands on something like -1e-16 instead.
np.linalg.solve only throws LinAlgError when it hits a strictly zero pivot during factorization. Your local libraryâs tiny rounding artifact dodges that check, so it happily divides by ~10â»Âčⶠand spits out ~10Âčâ· garbage.
Both outcomes mean the same thing: the system has no unique solution. If you ever need a reliable singularity check in practice, compare against a tolerance rather than testing for exact zero:
np.abs(np.linalg.det(A)) < 1e-10 # simple check
np.linalg.matrix_rank(A) < A.shape[0] # more robustSeems like maybe the test being used should be a little more flexible as to its value checking.
Normally DL.AI tests for zero use np.isclose(), to avoid this issue. That wasnât done for the Math for ML course.