## Archive for the ‘**Mathematics**’ Category

## Bouncing Back

I need to retract the mathematics in my previous post. A few simulations revealed that large masses were getting bounced around a bit too much, and tiny masses were exceptionally steady, hardly budging as big balls pounded them from all sides. Clearly, something was wrong.

I was right to be skeptical of the cubic mass, but wrong to trust my second set of equations, for I had made the same wrong substitution. From m₁·Δv₁=-m₂·Δv₂ I had ended up substituting -Δv₁·m₂/m₁ for Δv₂ in the conservation of energy equation. One mistake in a single term, and the whole equation explodes.

Way back when I thought Java was a good idea, I encountered a program that would let you drag around terms in an equation, and almost started an open-source version. Then again, Maple would probably have helped me even more in this case. I was very lucky to have physics professors who accepted homework in the form of Maple printouts.

Anyway, the corrected and verified equations:

`dx = (a.x - b.x)`

`dy = (a.y - b.y)`

`factor = 2 * (dx*(b.v.x - a.v.x) + dy*(b.v.y - a.v.y)) / ((a.m + b.m) * (dx**2 + dy**2))`

`a.v.x += factor * b.m * dx`

`a.v.y += factor * b.m * dy`

`b.v.x -= factor * a.m * dx`

`b.v.y -= factor * a.m * dy`

This set also has some simplifications, particularly with the `dx`

and `dy`

calculations. Since they were already needed in two places, using them to replace the radius made the whole thing more correct for very little cost.

In fact, it now looks decent even when we let the balls slip inside each other, with one caveat: A negative `factor`

means the balls are already moving away from each other; they may already have bounced, but haven’t yet separated. Don’t adjust the velocities in that case, or things can get jittery. Granted, this rule of thumb lets really fast collisions pass by undetected, but that doesn’t look nearly as bad.

## Bouncing Math

It should normally be impossible for three-dimensional balls of different sizes to be forced into a two-dimensional plane together. Nevertheless, I’ve discovered a situation where I want to calculate their trajectories when they bounce off each other.

Fortunately, I get to assume perfect elasticity. A bit more realism would be nice, but letting the input energy cancel out completely turns a quadratic equation linear. (The other solution is where the balls miss each other completely.) Because it’s been long enough since my mechanics course, I incidentally proved conservation of momentum along the way, but came up with the following:

`factor = 2*((a.x-b.x)*((b.m**2)*b.v.x - (a.m**2)*a.v.x) + (a.y-b.y)*((b.m**2)*b.v.y - (a.m**2)*a.v.y))/((a.m**3 + b.m**3) * (a.r + b.r)**2)`

`a.v.x += factor * a.m * (a.x-b.x)`

`a.v.y += factor * a.m * (a.y-b.y)`

`b.v.x -= factor * b.m * (a.x-b.x)`

`b.v.y -= factor * b.m * (a.y-b.y)`

Yes, it’s messy. Messy enough that I distrusted it at first (mass cubed, really?), despite the units working out properly, until I derived it again through a different method. It’s much simpler in the coordinates of the impact force, but gets just as complicated on translation back to cartesian coordinates.

Forgive my combination of programming syntax with physics-length variable names, for I have been delving into both worlds at once. They should all be obvious from the context, except that `.r`

is for the radius of the ball; that bit is a shortcut for calculating the absolute distance between their centers, which itself is part of a proxy for the impact force angle. The whole thing only really applies at the precise moment of collision, assuming the balls are perfectly rigid. Fortunately, I’m defining the universe in which this happens, so I get to make the rules.

Now I have to decide whether to use this, or whether a vastly simpler calculation will produce results that look good enough.

Update: My math was wrong. Use the new equations instead.

## Feasibility Results

I’ve been able to run through the full combinations for two-, three-, and four-candidate ballots, with specific winners for the plurality and/or Borda Count methods. The last one in particular is a huge mess of data, but some interesting patterns emerge.

The first thing of note is that a problem is never infeasible solely due to a plurality winner, except in the two-candidate cases. That means that under the most commonly used voting method, if there are more than two candidates, the winner may have very little to with the actual preferences of voters. As we saw in the AC>AD>BC>BD>CD” href=”https://eswald.wordpress.com/2011/07/19/abacadbcbdcd/”>very first case, a candidate can win even when it would lose to each of the others in a one-on-one situation.

Borda, on the other hand, isn’t nearly so susceptible to such messiness. There are still over eleven thousand four-candidate preference permutations that can be manipulated to have more than one winner, but that’s less than half of them. Fewer than two thousand admit more than two winners, and fewer than a hundred can swing all four ways. In addition, the potential Borda winners in each permutation frequently participate in cycles on the preference graphs, meaning that they’re each in the Smith set.

Not always, however. In particular, the Condorcet criterion counter-example listed on Wikipedia was reproduced exactly, but with different names, in the `AB>CA=CB,A`

row. For my next trick, I would like to figure out when exactly a non-Smith candidate can win a Borda election, and exactly how bad those results feel.

Sometime I’ll also compare the pairwise methods (Ranked Pairs, Beatpath, River, Minimax, and Kemeny-Young) to each other, but at least part of that work has already been done. Meanwhile, I’m spending a ridiculously large amount of processing power on the five-candidate ballots, just to ensure that my four-candidate results remain valid.