Return to Answer

In graduate school, I wrote some algorithm-heavy code myself. It's a bit of a tough nut to crack. To put it coarsely, a lot of programming conventions are built around the idea of putting information into a database, retrieving it at the right time, and then massaging that data to present it to a user, typically using a library for any math- or algorithm-heavy parts of that process.¹ For these programs, everything you've heard about OOP, breaking code into short functions, and making everything easily understandable at a glance where possible is excellent advice. But it doesn't quite work for algorithm-heavy code, or code that implements complex mathematical calculations and little else.

^{1 There are of course a lot of other types of commercial development. But most of them share the idea that for most of the math- and algorithm-heavy parts of a program, it's usually preferred to use an existing library than write the algorithm yourself when possible. That's not a bad thing, it's just the reason why math-oriented programming is better served by different conventions.}

In graduate school, I wrote some algorithm-heavy code myself. It's a bit of a tough nut to crack. To put it coarsely, a lot of programming conventions are built around the idea of putting information into a database, retrieving it at the right time, and then massaging that data to present it to a user, typically using a library for any math- or algorithm-heavy parts of that process. For these programs, everything you've heard about OOP, breaking code into short functions, and making everything easily understandable at a glance where possible is excellent advice. But it doesn't quite work for algorithm-heavy code, or code that implements complex mathematical calculations and little else.

In graduate school, I wrote some algorithm-heavy code myself. It's a bit of a tough nut to crack. Most programming conventions are built around the idea of stuffing some data into a database, getting it back out again at the right time, and then doing a little bit of straightforward massaging of that data to present it to a user. For these programs, everything you've heard about OOP, breaking code into short functions, and making everything easily understandable at a glance where possible is excellent advice. But it doesn't quite work for algorithm-heavy code, or code that implements complex mathematical calculations and little else.

In graduate school, I wrote some algorithm-heavy code myself. It's a bit of a tough nut to crack. To put it coarsely, a lot of programming conventions are built around the idea of putting information into a database, retrieving it at the right time, and then massaging that data to present it to a user, typically using a library for any math- or algorithm-heavy parts of that process.¹ For these programs, everything you've heard about OOP, breaking code into short functions, and making everything easily understandable at a glance where possible is excellent advice. But it doesn't quite work for algorithm-heavy code, or code that implements complex mathematical calculations and little else.

^{1 There are of course a lot of other types of commercial development. But most of them share the idea that for most of the math- and algorithm-heavy parts of a program, it's usually preferred to use an existing library than write the algorithm yourself when possible. That's not a bad thing, it's just the reason why math-oriented programming is better served by different conventions.}

// Solve the scalar Jacobi equation // // j''(s) + K(s)*j(s) = 0 , (1) // // where K is the Gaussian curvature and (.)' := d(.)/ds denotes differentiation // with respect to the arc length s. Then, j is the directional sensitivity and // we obtain the corresponding variational vector field by multiplying b*j. For // a sphere, K = R^(-2) and the solution of equation (1) becomes // // j = R * sin(1/R * s) (2) // j' = cos(1/R * s) , (3) // // where equation (2) is the standard solution of a non-damped oscillator. Its // period is 2*pi*R and its amplitude is R. // Forward directional sensitivity from P to Q Vec2 jPQ(R*sin(k * s), cos(k * s)); geod.addDirectionalSensitivityPtoQ(jPQ); // Backwards directional sensitivity from Q to P Vec2 jQP(R*sin(k * (L-s)), cos(k * (L-s))); geod.addDirectionalSensitivityQtoP(jQP); 

// Solve the scalar Jacobi equation // // j''(s) + K(s)*j(s) = 0 , (1) // // where K is the Gaussian curvature and (.)' := d(.)/ds denotes differentiation // with respect to the arc length s. Then, j is the directional sensitivity and // we obtain the corresponding variational vector field by multiplying b*j. For // a sphere, K = R^(-2) and the solution of equation (1) becomes // // j = R * sin(1/R * s) (2) //  j' = cos(1/R * s) , (3) // // where equation (2) is the standard solution of a non-damped oscillator. Its // period is 2*pi*R and its amplitude is R. // Forward directional sensitivity from P to Q Vec2 jPQ(R*sin(k * s), cos(k * s)); geod.addDirectionalSensitivityPtoQ(jPQ); // Backwards directional sensitivity from Q to P Vec2 jQP(R*sin(k * (L-s)), cos(k * (L-s))); geod.addDirectionalSensitivityQtoP(jQP);