Zulip Chat Archive

Stream: Natural sciences

Topic: Functions of vectors or vectors of functions?


Mr Proof (Aug 28 2025 at 05:09):

I might have asked this before but, are vector-fields better thought of as functions of vectors or vectors of functions or their own thing.

The difference is in what order the continuous and discrete variables are curried.

A third option is to have mixed index e.g A(X) where X=(mu,x,y,z,t) where mu is a discrete variable.

Why is this important?
Well if we do a dot product A.B depending on the order of currying this is either a dot product on vectors or int A(x)B(x) dx. or both.

Well, I don't think there's any "good" way of doing index free tensors fields, however much people have tried.

Alex Meiburg (Aug 28 2025 at 14:36):

If you write them as a "function from vectors to vectors", this will make it more ergonomic to then talk about when the fields are continuous/differentiable/smooth. I think this is enough to make that definitely the winning choice.

Alex Meiburg (Aug 28 2025 at 14:37):

It also lets you move more easily to talking about e.g. functions on the tangent bundle, which isn't really something you can talk about as a vector-of-functions.

Mr Proof (Aug 28 2025 at 23:30):

Yes so basically the type should be more like:

R4R4\mathbb{R}^4 \rightarrow \mathbb{R}^4

rather than

(R4R)4(\mathbb{R}^4 \rightarrow \mathbb{R})^4

My counter argument would be if we look at Maxwell's equations, we notice they are written without reference to any particular point x. So it is as if they are using the second abstraction rather than the first. But perhaps when doing things like Div and Curl, we should be thinking of Vector Fields as their own unique type rather than a combination of vectors and fields. And then be able to either select a unique point or a unique index. After all vector fields have more more structure than their parts. The downside of using a VectorField type is that we have to redefine all the dot products and cross products to work with it.

Alex Meiburg (Aug 29 2025 at 03:51):

I think that if you start by thinking what it would look like for a generic manifold, you'll probably end up with the better version. You don't have to actually do it with manifolds and docs#TangentSpace, but it will give you the more type-safe idea.

For instance, I think Div is really about the first abstraction, not the second. The function docs#deriv is the high school "1D" notion of derivative, but it is really just a special case of docs#fderiv, which works for any function f : A -> B where A and B could be multi-dimensional vector spaces over the reals. So if your electric field E is an R^4 -> R^4, then fderiv R E is a R^4 -> R^4 -> R^4, indicating "at position x, if I moved a little bit in direction y, how much would my z component of the electric field change?".

Then the divergence is tracing the second two components of this together. (In fact, since it's a linear map R^4 -> R^4 ->ₗ[R] R^4, it's literally just LinearMap.trace ∘ fderiv R E). The 3D curl is tracing all three components (now in R^3) against the Levi-Cevita tensor.

In the second abstraction, or (R^4 -> R)^4 as you wrote it, you would get much less structure! You have four separate functions R^4 -> R, but there's no "built-in" correspondence between the input space R^4 and the output space R^4. On a manifold, these _must_ be the same.

As another example: if you want to talk about the electric field as the derivative of a voltage field (e.g. in free space), then fderiv R V would give you the right type, R^4 -> R^4.


Last updated: Dec 20 2025 at 21:32 UTC