Codecov Report

Merging #384 (ff8c6c9) into master (05302b4) will increase coverage by 0.58%.
The diff coverage is 77.46%.

@@            Coverage Diff             @@
##           master     #384      +/-   ##
==========================================
+ Coverage   84.60%   85.18%   +0.58%     
==========================================
  Files          97       97              
  Lines       12887    12934      +47     
  Branches      692      694       +2     
==========================================
+ Hits        10903    11018     +115     
+ Misses       1292     1222      -70     
- Partials      692      694       +2     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 05302b4...ff8c6c9. Read the comment docs.

(Here's my email describing the big bug and its fix. I was writing to GJS so translated everything to scheme and scmutils files.)

Hey, moving to this thread... I managed to get my bug fixed! The upshot is:

• the first two examples now take ~90 seconds
• Conservation of energy-momentum takes ~13 seconds for all 4 indices
• the final set of 4 examples take 3.5 seconds total.

Pretty quick! I'm sure this is benefitting from some memoization I added during investigation. That would be nice to talk about; it saves a bunch of duplicate calls, but I suspect that it is wiser to try and reduce the duplicate calls at the source. Let me know if you want to chat, or if you would like me to write up where I was able to save time.

If you are curious what the solution was, the problem was quite subtle:

In manifold.scm, manifold points keep a mapping of coordinate system => representation, accessible by COORDINATE-REPS. If you create a point from some manifold like SPACETIME-SPHERICAL using, say, (point spacetime-spherical), you will get a manifold point, BUT that point will have cleverly stashed a clean representation like

(up t r theta phi)

in the COORDINATE-REPS mapping. The representation of the point "as it actually is on the manifold" is in rectangular 4D coordinates:

(up t
    (* r (sin theta) (cos phi))
    (* r (sin theta) (sin phi))
    (* r (cos theta)))

In fact, if you ever try and use (spacetime-spherical 'point->coords) to go back, you will NOT get a nice clean (up r t theta phi); you will get:

(up t
    (sqrt (+ (expt (* r (sin theta) (cos phi)) 2)
             (expt (* r (sin theta) (sin phi)) 2)
             (expt (* r (cos theta)) 2)))
    (acos (/ (* r (cos theta))
             (sqrt (+ (expt (* r (sin theta) (cos phi)) 2)
                      (expt (* r (sin theta) (sin phi)) 2)
                      (expt (* r (cos theta)) 2)))))
    (atan (* r (sin theta) (sin phi))
          (* r (sin theta) (cos phi))))

But that does not matter (in scmutils) because MAKE-MANIFOLD-POINT stashes a mapping of spacetime-spherical => (up r t theta phi) for the point on creation, case closed!

In my port, I (cleverly, I thought) removed almost all mutation, and changed SET-COORDINATE-PROTOTYPE! to WITH-COORDINATE-PROTOTYPE, which takes an immutable coordinate system and prototype and returns a NEW one.

But this breaks the COORDINATE-REPS cache, since now my coordinate system does not match the old one.

What does WITH-COORDINATE-PROTOTYPE have to do with Einstein's Field Equations??

Well, my tests were using my equivalent of USING-COORDINATES; but I structured my tests so there were TWO separate wrappings of USING-COORDINATES. Because of this, my field equations code was working with points that reported their spacetime-spherical coordinate representation as that crazy mess above, instead of a reasonable

(up t r theta phi)

The simplifier was not pleased.