I think this looks pretty good, the only thing is it doesn't use colour to show magnitude, which I feel would be a nice feature. I don't want to duplicate code that's already in the heatmap PR however.

The example in #438 shows the size of the arrowhead scaling with the magnitude of the vector... perhaps this would make the gap at X=0 look less awkward? Maybe something similar for line width? 🤔

EDIT: nah, line width seems like it should stay fixed-size

Matplotlib calls these "quiver plots". Makes sense since a quiver is a collection of arrows 😄

• https://problemsolvingwithpython.com/06-Plotting-with-Matplotlib/06.15-Quiver-and-Stream-Plots/
• https://krajit.github.io/sympy/vectorFields/vectorFields.html
• https://matplotlib.org/2.0.1/examples/pylab_examples/quiver_demo.html

I think PlotVectorField() like you have it reads better...

Makes sense since a quiver is a collection of arrows 😄

Oooooohhh... that's why it's called that. I was thinking quiver the verb, and I couldn't think of any way that it made sense.

I added the pendulum example, because it is the canonical example of vector fields, at least for physics:

I'm curious what your thoughts would be on having LaTeX axis labels? For example, the y axis in the pendulum screenshot is a little bland in comparison to

\dot{\theta}

Or if you insist on Leibniz's notation:

\frac{d\theta}{dt}

I know you aren't keen on dependencies, and this isn't exactly something that's fun or easy to implement on your own. Especially when it's just to make labels and titles look a little spicier.

I'm curious what your thoughts would be on having LaTeX axis labels?

I like the concept... but I don't see System.Drawing being able to keep up. We'd have to bring in a tight dependency to another package, and right now ScottPlot is dependency-free and I'd love to keep it that way.

If a user really wants that level of customization, the way to go is probably for them to use their tex package to render a Bitmap then draw it on top of an existing plot.

I just committed another quiver plot pull request (#440), Wasn't aware that this exists already.

I just committed another quiver plot pull request (#440), Wasn't aware that this exists already.

no worries! I'll close that PR, merge this one shortly, and we can continue to experiment with alternative implementations in new PRs as ideas pop up

@Benny121221 it might be cool to make a variant of this like PlotFunction, where you pass in a formula and the lines are generated programmatically...

I really want to find something more elegant than passing in a Vector2[,] and two double[] arrays. This feels convoluted, and it's weirdness is apparent in the quickstart code...

I'm surprised how few structs system.numerics actually offers. I don't want to make my own struct here, but I'm really limited. Vector4 is close but no cigar 😝

I could make an array of tuples or something that pairs a System.Drawing.PointF with a System.Numerics.Vector2 but that seems like a weird mash-up of libraries.

Going the other direction, I'm looking at what matplotlib does. https://matplotlib.org/3.1.0/api/_as_gen/matplotlib.pyplot.quiver.html This is interesting. Their quiver method takes in the equivalent of 4 double[]... I might like this 🤔 It inherently supports non-rectangular grids too, though I can't think of a use case there.

plt.PlotVectorField(posXs, posYs, vecX, vecY);

perhaps an optional argument could be used to scale how long the arrows are

plt.PlotVectorField(posXs, posYs, vecX, vecY, vecScale);

I'm between this or writing my own struct to hold these values. Perhaps PointVector?

I really want to find something more elegant than passing in a Vector2[,] and two double[] arrays. This feels convoluted, and it's weirdness is apparent in the quickstart code...

I think the weirdness comes from how there are two competing ideas of vectors. The CS perspective where they are points defined by the position of their tail, and the Physics perspective where they are quantities defined by their direction and magnitude.

The CS perspective is most convenient for the evolution of a phase space under a differential equation, which is why the pendulum example is so simple, there's no trig required to convert between the two interpretations.

The Physics perspective is more convenient for situations where you care about the direction, not the position of the tail, which is why the slope field example feels klunky.

Personally, my recommendation would be to keep with the CS perspective, and offer a function to convert between, something like Tools.GetTailPosition()

Ah, I misunderstood you, you meant argument list weirdness. My only idea that you didn't already bring up was to do the same as heatmaps, where they take Vector2[,], and then optional parameters to move or scale the axis: double[] axisOffsets, double[] axisMultipliers. I don't think that really solves the problem though :/

Going the other direction, I'm looking at what matplotlib does. https://matplotlib.org/3.1.0/api/_as_gen/matplotlib.pyplot.quiver.html This is interesting. Their quiver method takes in the equivalent of 4 double[]... I might like this 🤔

That's what the other vector field PR did, it's what I'd lean towards personally. Plus I liked his demo, I think electromagnetism is a lot simpler when you see it as a phase space.

The reason why my demo looks 'nice' is because I removed the CustomEndCap and drew the arrow head myself. I encountered nothing but pain when I tried to make scaling work nicely with a CustomEndCap.
There is quite a bit more work involved in doing all the trig calculations. However, this shouldn't be much of an issue. Quiver plots with more than 10,000 vectors are usually way too crowded to be useful.

The reason why my demo looks 'nice' is because I removed the CustomEndCap and drew the arrow head myself. I encountered nothing but pain when I tried to make scaling work nicely with a CustomEndCap.
There is quite a bit more work involved in doing all the trig calculations. However, this shouldn't be much of an issue. Quiver plots with more than 10,000 vectors are usually way too crowded to be useful.

@hhubschle is referring to #440

I didn't notice that before! This is good to take note of. I agree the System.Drawing caps are pretty lousy. Thanks for pointing it out!

I ran dotnet-format so idk what that's about

I ran dotnet-format so idk what that's about

This just started happening! #452 was affected too. I think a recent update to dotnet changed the behavior of dotnet format to now sort using statements (#425).

I just started working on ScottPlot again tonight, so I'm free to merge this if/when you think it's ready. Want me to leave it as it is for you to keep poking at it or do you think it's ready for a merge now?

I think I'll add hhubschle's demo, to me it looked like two opposite charges but looking at the source I didn't recognize the math.

Other than that I can't think of much which needs adding, idk how you feel about changing the parameter list, I remember you bringing that up earlier?