vellum 0.6.2

One bug, found by looking at a picture.

vl_contour() transposed its input matrix

It assumed rows indexed y and columns x. Base R is the opposite: image(), contour(), persp() and contourLines() all take dim(z) == c(length(x), length(y)), so rows index x — and that is also the shape outer(xs, ys, f) produces, which is how a grid is normally built.

So every contour came back reflected across the diagonal. The documentation compounded it by citing image() as the authority for the opposite of what image() does.

Verified against base R on an asymmetric bump at (x = 2, y = −1):

	result
vl_contour(z) before	(−1, 2)
grDevices::contourLines(x, y, z)	(2, −1)
vl_contour(z) now	(2, −1)

Is this breaking?

Only if you were transposing your matrix to work around it. Code that passed outer(xs, ys, f) straight in was getting transposed output and is now correct with no change — which is why no example or vignette needed a code edit, only clearer argument names.

Why 81 contour tests missed it

Every contour test used a surface symmetric in its two arguments, where a transpose is a no-op. On a symmetric Gaussian the bug is invisible; over a density with a reference layer beneath it, it is obvious at a glance.

The new tests use an asymmetric surface and assert against grDevices::contourLines() rather than against our own expectation. That is the same blind spot as the offset-viewport bug fixed in 0.6.1 — in both cases a convenient, symmetric fixture concealed a real error, and a deliberately awkward one exposed it immediately.

Also removes a transpose from the hot path, so it is marginally faster.