egg changed the topic of #principia to: Logs: https://esper.irclog.whitequark.org/principia | <scott_manley> anyone that doubts the wisdom of retrograde bop needs to get the hell out | https://xkcd.com/323/ | <egg> calculating the influence of lamont on Pluto is a bit silly…
raptop has quit [Ping timeout: 183 seconds]
<queqiao->
⟨drveyl⟩ Weird to deviate from the planner since the planner actually invokes the full system with simulated positions.
<queqiao->
⟨drveyl⟩ Create a vessel to vessel condition that breaks the rule, and show the debugger please.
<queqiao->
⟨sichelgaita⟩ Yes, the polynomials and the coefficients in the paper are unnormalized, that's much easier to work with. In practice the coefficients found in the litterature (and in our configuration files) are normalized so we "unnormalize" them in the code at the point of use.
<queqiao->
⟨pisslover72⟩ dont you get severe underflow/overfloww
<queqiao->
⟨pisslover72⟩ * underflow/overflow when the degree is like above 10
<queqiao->
⟨pisslover72⟩ * 10?
<queqiao->
⟨sichelgaita⟩ The polynomials have _coefficients_ that are ridiculously large (and alternate in sign), but their final _value_ is in [-1, 1]. You will notice that we never compute the polynomials themselves, we compute their values using recurrence relationships, and that remains well-behaved. (This was not our first implementation attempt, maybe not even the second, and at some point we did indeed run into 64-bit integer overflows.)
<queqiao->
⟨sichelgaita⟩ The normalization coefficients have a similar problem, they involve factorials of large numbers. We computed them offline using _Mathematica_ and put in a table the resulting values.
<queqiao->
⟨sichelgaita⟩ This might be a problem with higher degrees, but it's all fine until degree/order 50. Note that we don't compute the associated polynomials themselves, only their values. So we are not affected by the size of the coefficients.