search

ccnmtl / econplayground

aka EconPractice - Environment for authoring and interacting with economics concepts
https://econpractice.ctl.columbia.edu/
GNU General Public License v3.0
3 stars 1 forks source link

Demand-Supply graph: Intersection bug #3345

Open nikolas opened 1 month ago

nikolas commented 1 month ago

In the initial state of the Demand-Supply graph, changing the slope of either line tilts the line at its intersection. When you drag the lines with the mouse to new positions and then change the slope, the line is tilted at an arbitrary location deemed its "center" by the graph-drawing system. This is due to how the lines in this graph type are drawn: https://github.com/ccnmtl/econplayground/blob/master/media/js/src/graphs/DemandSupplyGraph.js#L9

I intentionally didn't make these lines jsxgraph functiongraph objects, because they are draggable. This isn't set in stone though - and can change if there is a better method for doing this.

This is a long-standing, but relatively minor issue. But there is possibly a solution involving some math.

Evan-CTL commented 1 month ago

Since they're all lines why don't we use the y-intercept as the pivot? Or to put it another way, it pivots from the origin (0, 0) offset by the y-intercept. Translating the line in any direction would affect the y-intercept which provides a new pivot point, and changing the slope wouldn't matter at x=0.

nikolas commented 1 month ago

The goal is to pivot the lines at the point where they intersect. Pivoting at the y-intercept wouldn't really make sense, but maybe I'm not understanding this suggestion. I just put this bug here as a record of this issue, but if you have a proposed solution it may be easier to articulate with code.

The solution has to take into account that the user can drag the lines freely, and we have code which updates their position in the system based on that. If they were not draggable we wouldn't have this problem.

Now that I mention that, I think a possible solution is to have code to adjust the line's center point after each drag from the user. In this graph type, these lines are treated more as graphical objects than mathematical functions, so maybe we don't need math after all to solve this - I'll do some experiments.