Return to Answer

• No way to choose orientation—except for Line regions or explicit parametrizations, integrals are only unique up to a sign, and you may get the opposite sign than the one you bargained for without any indication of this. We should create a new OrientedRegion datatype.

• When we don't have enough info for orientation, we should at least have messages for alerting the user as to what kind of integral will be taken (absolute or not). There are also arguments to be made (or had!) about whether regions that automatically get converted to parametric form should have a sign or not, and if not, where the sign should be set to "positive". There's a big difference between $\int_{\vec{\gamma}} |\vec{v}\cdot d\vec{\gamma}|$ and $\left|\int_{\vec{\gamma}} \vec{v}\cdot d\vec{\gamma}\right|$!

• Just realized I demand that the argument be an explicit vector field (a list). I should instead allow arbitrary expressions, like v[x,y,z,...] as well; this should be an easy fix when I get back.

• We put a lot of trust in formal variables being definitionless, and also we allow expressions like v and f to evaluate fully with those formal variables inside. (Not to mention the newly-exposed conditions in ImplicitRegion!) This could be risky, in part because they might have a definition, but mostly because parts of our given expression might evaluate to something undesirable when acting on them outside of an integral—we don't know, and don't want to risk it.

• No error messages yet; it just returns unevaluated. Ideally we should say what's wrong if we can't evaluate.

• We could generalize to higher dimensions! Why only integrate on curves? (Note that the current implementation supports any embedding dimension, by the way.)

• Options! To, e.g., specify the preferred representation of our region, or include extra assumptions in our internal Simplifys.

• Mathematica has access to a great curated collection of curves via SpaceCurve. These often come with tangent vectors included as properties! We could extend this to use those too—not just regions—but that's pretty straightforward.

• We could add support for simple-enough BooleanRegions.

• No way to choose orientation—except for Line regions or explicit parametrizations, integrals are only unique up to a sign, and you may get the opposite sign than the one you bargained for without any indication of this. We should create a new OrientedRegion datatype.

• When we don't have enough info for orientation, we should at least have messages for alerting the user as to what kind of integral will be taken (absolute or not). There are also arguments to be made (or had!) about whether regions that automatically get converted to parametric form should have a sign or not, and if not, where the sign should be set to "positive". There's a big difference between $\int_{\vec{\gamma}} |\vec{v}\cdot d\vec{\gamma}|$ and $\left|\int_{\vec{\gamma}} \vec{v}\cdot d\vec{\gamma}\right|$!

• Just realized I demand that the argument be an explicit vector field (a list). I should instead allow arbitrary expressions, like v[x,y,z,...] as well; this should be an easy fix when I get back.

• We put a lot of trust in formal variables being definitionless, and also we allow expressions like v and f to evaluate fully with those formal variables inside. (Not to mention the newly-exposed conditions in ImplicitRegion!) This could be risky, in part because they might have a definition, but mostly because parts of our given expression might evaluate to something undesirable when acting on them outside of an integral—we don't know, and don't want to risk it.

• No error messages yet; it just returns unevaluated. Ideally we should say what's wrong if we can't evaluate.

• We could generalize to higher dimensions! Why only integrate on curves? (Note that the current implementation supports any embedding dimension, by the way.)

• Options! To, e.g., specify the preferred representation of our region, or include extra assumptions in our internal Simplifys.

• Mathematica has access to a great curated collection of curves via SpaceCurve. These often come with tangent vectors included as properties! We could extend this to use those too—not just regions—but that's pretty straightforward.

• We could add support for simple-enough BooleanRegions.

• Numerical functionality! There's lots to be done there.

I've also included support for the explicit, non-region parametric form used in the other nice answer to this post! Credit to @E. Chan-López for the argument pattern! Mine's a bit different, though: I demand, in that mode, an actual function to be given as a first argument, to avoid both a var and an iterator argument.

I've also included support for the explicit, non-region parametric form used in the other nice answer to this post! Credit to @E. Chan-López for the notion that this should be a way to specify a line integral—I was locked in thinking about regions! The syntax of mine's a bit different, though: I demand that an actual function be given as a first argument, to avoid both a vars and an iterator argument (and to avoid privileging x, y, and z, as that's not very kosher in Mathematica).

Also, I figured it would be nice to check for Line regions first, and handle them separately. After all, these are fairly unambiguously directed! For some reason, RegionConvert doesn't like converting them to parametric form—but that means we definitely lose all orientation info. Instead, I check for regions with head Line and homebrew the parametrizations. No change needs to be made to the input; the code will just react differently to Line regions.

• No way to choose orientation—except for Line regions or explicit parametrizations, integrals are only unique up to a sign, and you may get the opposite sign than the one you bargained for without any indication of this.

• When we don't have enough info for orientation, we should at least have messages for alerting the user as to what kind of integral will be taken (absolute or not). There are also arguments to be made (or had!) about whether regions that automatically get converted to parametric form should have a sign or not, and if not, where the sign should be set to "positive". There's a big difference between $\int_{\vec{\gamma}} |\vec{v}\cdot d\vec{\gamma}|$ and $\left|\int_{\vec{\gamma}} \vec{v}\cdot d\vec{\gamma}\right|$!

• Just realized I demand that the argument be an explicit vector field (a list). I should instead allow arbitrary expressions, like v[x,y,z,...] as well; this should be an easy fix when I get back.

• We put a lot of trust in formal variables being definitionless, and also we allow expressions like v and f to evaluate fully with those formal variables inside. (Not to mention the newly-exposed conditions in ImplicitRegion!) This could be risky, in part because they might have a definition, but mostly because parts of our given expression might evaluate to something undesirable when acting on them outside of an integral—we don't know, and don't want to risk it.

• No error messages yet; it just returns unevaluated. Ideally we should say what's wrong if we can't evaluate.

• We could generalize to higher dimensions! Why only integrate on curves? (Note that the current implementation supports any embedding dimension, by the way.)

• Options! To, e.g., specify the preferred representation of our region, or include extra assumptions in our internal Simplifys.

• Mathematica has access to a great curated collection of curves via SpaceCurve. These often come with tangent vectors included as properties! We could extend this to use those too—not just regions—but that's pretty straightforward.

Here are some tests!

Also, I figured it would be nice to check for Line regions first, and handle them separately. After all, these are fairly unambiguously directed! For some reason, RegionConvert doesn't like converting them to parametric form—but that means we definitely lose all orientation info. Instead, I check for regions with head Line and homebrew the parametrizations. This lets us preserve the implicit orientation: Line[{pt0, pt1, pt2, ...}] should be directed from pt0 to pt1 to pt2, etc. For syntax, no change needs to be made to the input; the code will just automatically react differently to explicit Line regions.

• No way to choose orientation—except for Line regions or explicit parametrizations, integrals are only unique up to a sign, and you may get the opposite sign than the one you bargained for without any indication of this. We should create a new OrientedRegion datatype.

• When we don't have enough info for orientation, we should at least have messages for alerting the user as to what kind of integral will be taken (absolute or not). There are also arguments to be made (or had!) about whether regions that automatically get converted to parametric form should have a sign or not, and if not, where the sign should be set to "positive". There's a big difference between $\int_{\vec{\gamma}} |\vec{v}\cdot d\vec{\gamma}|$ and $\left|\int_{\vec{\gamma}} \vec{v}\cdot d\vec{\gamma}\right|$!

• Just realized I demand that the argument be an explicit vector field (a list). I should instead allow arbitrary expressions, like v[x,y,z,...] as well; this should be an easy fix when I get back.

• We put a lot of trust in formal variables being definitionless, and also we allow expressions like v and f to evaluate fully with those formal variables inside. (Not to mention the newly-exposed conditions in ImplicitRegion!) This could be risky, in part because they might have a definition, but mostly because parts of our given expression might evaluate to something undesirable when acting on them outside of an integral—we don't know, and don't want to risk it.

• No error messages yet; it just returns unevaluated. Ideally we should say what's wrong if we can't evaluate.

• We could generalize to higher dimensions! Why only integrate on curves? (Note that the current implementation supports any embedding dimension, by the way.)

• Options! To, e.g., specify the preferred representation of our region, or include extra assumptions in our internal Simplifys.

• Mathematica has access to a great curated collection of curves via SpaceCurve. These often come with tangent vectors included as properties! We could extend this to use those too—not just regions—but that's pretty straightforward.

• We could add support for simple-enough BooleanRegions.

Tests

Here are some tests demonstrating the different functionality! (The only one from the original post that's excluded is the Circle3D one, as Mathematica (frustratingly) does not have a corresponding built-in for circles in 3D.)