Differences between sicmutils and scmutils in Functional Differential Geometry #380

phasetr · 2021-10-26T09:19:04Z

phasetr
Oct 26, 2021

When we write codes in Functional Differential Geometry, we manage several discrepancies. It is because we simply does not implement corresponding functions now or we face language specification problems. In the comment the former example is define-coordinates and let-coordinates, and the latter is a syntactic problem, d/dt in Scheme and d:dt in Clojure.
I will list up some remarks and questions when coding the book.

Remarks (Added)

Code samples

We have code samples in the test directory, especially here.

Typos in the book

@sritchie summarizes them in the comment.

`define-coodinates`

@sritchie added define-coordinates in a pull request and fix a bug. We should use this macro for the book coding!

phasetr · 2021-10-26T09:26:05Z

phasetr
Oct 26, 2021
Author

Prologue

Remarks

P.xix, Gamma: already defined in sicmutils.mechanics.lagrange
P.xix Lagrange-equations: defined in sicmutils.mechanics.lagrange

Questions

P.xx, show-expression: do I use (def render (comp ->infix simplify)) instead?

1 reply

< 8000 div class="d-flex flex-items-center"> sritchie Oct 26, 2021
Maintainer

That's correct, about your render function. I am working on a guide for how to use Nextjournal's Clerk project to render TeX, which would let you do

(def render (comp ->TeX simplify))

I also want to plug Nextjournal... all of this code will ALSO work in the browser! See

Here's an interactive version of one of the exercises from SICM: https://nextjournal.com/try/sicm/ex-1-12. Interactive == you can edit any of the text or cells, and re-run the cell to see the result. Expressions are rendered as TeX by default in this environment.

My next goal is to use Clerk to get this sort of experience working locally, using your local editor and process. Coming soon!

phasetr · 2021-10-26T12:30:28Z

phasetr
Oct 26, 2021
Author

1. Prologue

Remarks

P.9, geodesic-equation-residuals, and define-coodinates at the footnote 8: now we have let-coordinates, but not define-coodinates. So we should write a function as follows.

(def geodesic-equation-residuals
  (let-coordinates [t R1-rect]
    (((((covariant-derivative Cartan gamma) d:dt)
       ((differential gamma) d:dt))
      (chart R2-rect))
     ((point R1-rect) 't))))

Questions

P.4, F->C: this function is defined in sicmutils.mechanics.laglange. But its definition seems different from the original definition. Furthermore the original uses the function time, and this is a predefined function in Clojure. What is time for sicmutils?

2 replies

sritchie Oct 26, 2021
Maintainer

The F->C difference is there to handle local tuples of arbitrary length; the version presented in FDG can only handle local tuples with time, coordinate and velocity entries. A great example of where a literate program would be able to show successive versions of a function, all in one spot!

Search for "We can use Gamma-bar to construct" in this SICM link, and check out footnote 90, to see where this more general definition is introduced.

Good question on time, coordinate and velocity functions. There are two answers:

sicmutils has state->t instead of time, but also has coordinate, velocity, acceleration, like the original scmutils. BUT sicmutils also gets an advantage from Clojure, because the local tuple implements the vector/sequence abstraction. So you can also use (nth tuple 0) or (first tuple) to get the time, or just straight-up destructure:

(defn sphere->R3
  [R]
  (fn [[t [theta phi] v]]
    (up (* R (sin theta) (cos phi))
        (* R (sin theta) (sin phi))
        (* R (cos theta)))))

Notice that the returned function takes a vector, but then destructures it into three arguments. The first and third are t and v, but destructuring can nest, so the coordinate argument is destructured in place into theta and pi.

In the original scmutils this would have to look more like

(defn sphere->R3
  [R]
  (fn [local]
    (let [t (state->t local)
          q (coordinate local)
          v (velocity local)
          theta (ref q 0)
          phi (ref q 1)]
      (up (* R (sin theta) (cos phi))
          (* R (sin theta) (sin phi))
          (* R (cos theta))))))

phasetr Oct 30, 2021
Author

Thank you for your comment! I rewrite my codes.

phasetr · 2021-10-26T14:02:07Z

phasetr
Oct 26, 2021
Author

2. Manifolds

Questions

P.12, U: its definition is (define U (patch ’origin R2)) in the original. What are the correspoindings patch, 'origin and U in sicmutils? (I found attach-patch, and :origin in the variable Rn, sicmutils.calculus.manifold.)
P.13, R2-rect and R2-polar: these are in sicmutils/calculus.manifold, but their definitions are different, e.g., (def R2-rect (coordinate-system-at R2 :rectangular :origin)) in sicmutils. What are differences between them? Can I implement this by U in P.12?
P.16, R2->R, f: How do I implement these?

The discussion after R2->R and f needs f, so I stop reading until I can understand what these are.

3 replies

sritchie Oct 26, 2021
Maintainer

I'll edit this to be a more full answer later, but clues for these will live in the tests under the fdg directory, where each chapter has a namespace:

https://github.com/sicmutils/sicmutils/blob/master/test/sicmutils/fdg/ch2_test.cljc#L54

Clearer answer soon, but here is an example:

https://github.com/sicmutils/sicmutils/blob/master/test/sicmutils/fdg/ch2_test.cljc#L54-L94

EDIT:

Okay, excellent. patch in scmutils is sicmutils.calculus.manifold/get-patch in SICMUtils: https://github.com/sicmutils/sicmutils/blob/master/src/sicmutils/calculus/manifold.cljc#L180-L190

The big difference between the two libraries here is that scmutils uses mutation in its manifold definitions, so attach-patch actually mutates a manifold object.

In SICMUtils, we ride on Clojure's decision to make everything immutable, which is why you see the threading macro in Rn:

(def Rn
  (-> "R(%d)"
      (make-manifold-family)
      (attach-patch :origin)
      (attach-coordinate-system :rectangular :origin ->Rectangular)
      (attach-coordinate-system :polar-cylindrical :origin ->PolarCylindrical)
      (attach-coordinate-system :spherical-cylindrical :origin ->SphericalCylindrical)))

(def R2 (make-manifold Rn 2))
(def R2-rect (coordinate-system-at R2 :rectangular :origin))
(def R2-polar (coordinate-system-at R2 :polar-cylindrical :origin))

That isn't so important for your question, but good background detail.

patch becomes get-patch
The symbol 'origin in scmutils becomes the keyword :origin in SICMUtils, and you can use any patch that has been attached to the original manifold family that your manifold was created from. (Here R2 is a manifold created from the Rn manifold family. You could do (def my-Rn (attach-patch :my-special-point)) and then create (def my-R2 (make-manifold my-Rn 2)), and reference :my-special-point as a patch, for example.)

SO, yes, the difference is you don't provide the U patch here to coordinate-system. I will write up at some point why this difference is here, but for now reference the https://github.com/sicmutils/sicmutils/blob/master/test/sicmutils/fdg/ch2_test.cljc#L54-L94 ch2 tests to see the differences.

R2->R in FDG is defined at the top of page 16. It is almost the same in sicmutils, just use a quote in front of the form:

(def R2->R '(-> (UP Real Real) Real))

I am working on a PR in #262 that will allow you to use ->, UP, Real etc without the quote, provided you want to import them and override Clojure's ->. But for now just quote the form.

Then you define f like this:

(def R2-rect-chi (chart R2-rect))

(def f
  (compose (literal-function 'f-rect R2->R)
           R2-rect-chi))

Or like:

(def f (literal-manifold-function 'f-rect R2-rect))

just like on page 16 of FDG.

sritchie Oct 26, 2021
Maintainer

Okay @phasetr , edited this to have more info. Let me know if this helps.

phasetr Oct 26, 2021
Author

It's fantastic! Thanks to test codes, I can understand the definition for h!

phasetr · 2021-10-27T00:20:11Z

phasetr
Oct 27, 2021
Author

2. Manfolds (Added)

Remarks

P.17, one liners. I write codes for each line, though they are a little cumbersome. See also the comment.

;;; For (x (R2-rect-chi-inverse (up 'x0 'y0)))
(let-coordinates
    [(up x y) R2-rect]
  (x (R2-rect-chi-inverse (up 'x0 'y0))))

Edited: due to a commet. We can write a somewhat simple code.

;;; For (x (R2-rect-chi-inverse (up 'x0 'y0)))
(let-coordinates
    [[x y] R2-rect]
  (x (R2-rect-chi-inverse (up 'x0 'y0))))

The followings are the same.

;;; For (x (R2-polar-chi-inverse (up ’r0 ’theta0)))
(let-coordinates
    [(up x y) R2-rect
     (up r theta) R2-polar]
  (x (R2-polar-chi-inverse (up 'r0 'theta0))))

;;; For (r (R2-polar-chi-inverse (up ’r0 ’theta0)))
(let-coordinates
    [(up r theta) R2-polar]
  (r (R2-polar-chi-inverse (up 'r0 'theta0))))

;;; For (r (R2-rect-chi-inverse (up ’x0 ’y0)))
(let-coordinates
    [(up r theta) R2-polar]
  (r (R2-rect-chi-inverse (up 'x0 'y0))))

;;; For (theta (R2-rect-chi-inverse (up ’x0 ’y0)))
(let-coordinates
    [(up r theta) R2-polar]
  (theta (R2-rect-chi-inverse (up 'x0 'y0))))

;;; For (h R2-rect-point)
(let-coordinates
    [(up x y) R2-rect
     (up r theta) R2-polar]
  (let [h (+ (* x (square r)) (cube y))]
    (h R2-rect-point)))

;;; For (h (R2-polar-chi-inverse (up ’r0 ’theta0)))
(let-coordinates
    [(up x y) R2-rect
     (up r theta) R2-polar]
  (let [h (+ (* x (square r)) (cube y))]
    (render (h (R2-polar-chi-inverse (up 'r0 'theta0))))))

P.18, the top 2 codes. I show the code using let-coordinates.

(let-coordinates
    [(up r theta) R2-polar]
  (render ((- r (* 2 'a (+ 1 (cos theta))))
           ((point R2-rect) (up 'x 'y)))))

1 reply

sritchie Oct 29, 2021
Maintainer

Nice, we definitely need define-coordinates. Note that you can also write the forms using let-style destructuring:

(let-coordinates
    [[x y] R2-rect]
  (x (R2-rect-chi-inverse (up 'x0 'y0))))

phasetr · 2021-10-27T23:53:47Z

phasetr
Oct 27, 2021
Author

03. Vector Fields and One-form Fields

Remarks

P.24, components->vector-fields: This is defined in sicmutils.calculus.vector-field. In sicmutils, this function is multiple-aritied.
P.24, v: In sicmtuils we should write b↑i for 'b^i. (In Japan we can write the character ↑ using Japanese IME. For other (natural) language environment, how does one write? Copy and paste, or some editor's support?)
P.25, coordinatize: This is defined in sicmutils.calculus.vector-field. The definition in sicmutils is a little different from the book, due to the definition of make-operator in sicmutils.operator.

(remarks '[sicmutils.env :as e :refer :all])
(require '[sicmutils.operator :as o])
(defn coordinatize
  [v coordsys]
  (defn coordinatize-v
    [f]
    (fn [x]
      (let [b (compose (v (chart coordsys))
                       (point coordsys))]
        (* ((D f) x) (b x)))))
  (o/make-operator coordinatize-v `(~'coordinatized ~(o/name v))))

P.31, the code beginning series:for-each print-expression: We do not have series:for-each and print-expression. This is in the test code, sicmutils.fdg.ch3-test, as follows.

(let-coordinates [(up x y) R2-rect]
  (let [circular (- (* x d:dy) (* y d:dx))]
    (take 6
          (seq
           (((exp (* 't circular)) (chart R2-rect))
             ((point R2-rect) (up 1 0)))))))

P.31, the function circular and its print: We use the function let-coordinates again. In the test code, we should use other functions for series:for-each or print-expression.

(let-coordinates [(up x y) R2-rect]
  (let [circular (- (* x d:dy) (* y d:dx))]
    (map render
         (take 6
               (seq
                (((exp (* 't circular)) (chart R2-rect))
                 ((point R2-rect) (up 1 0))))))))

P.31, evolution: We have this in sicmutils.calculus.vector-field. We have a somewhat different definition in sicmutils.

(defn evolution
  "P.31, This is defined in `sicmutils.calculus.vector-field`."
  [order]
  (fn [delta-t v]
    (fn [f]
      (fn [m]
        (series/sum (((exp (* delta-t v)) f) m)
                    order)))))

(let-coordinates [(up x y) R2-rect]
  (let [circular (- (* x d:dy) (* y d:dx))]
    (render
     ((((evolution 6) 'delta-t circular)
       (chart R2-rect))
      ((point R2-rect) (up 1 0))))))

P.35, components->1form-field: We have components->oneform-field in sicmutils.
P.35, ((omega (down d/dx d/dy)) m/R2-rect-point)): We should use let-coordinates.
P.35, (def omega (literal-1form-field 'a R2-rect)): We should write (def omega (literal-oneform-field 'a R2-rect)).
P.36, (define-coordinates (up x y) R2-rect): We should use let-coordinates as follows.

(let-coordinates [(up x y) R2-rect]
  ((dx d:dy) R2-rect-point))
(let-coordinates [(up x y) R2-rect]
  ((dx d:dx) R2-rect-point))

P.37, oneliners: We should use let-coordinates as follows.

;;;((dx circular) R2-rect-point)
(let-coordinates [(up x y) R2-rect]
  (let [circular (- (* x d:dy) (* y d:dx))]
    ((dx circular) R2-rect-point)))

4 replies

sritchie Oct 29, 2021
Maintai 9E88 ner

On p24, components->vector-field is a bit more bare than the actual scheme definition, which includes the extra arity version to supply a name:

https://github.com/Tipoca/scmutils/blob/master/src/calculus/vector-fields.scm#L58-L62

I would love a better solution for embedding simple-then-more-complex versions of a function into text.

for the b↑i character I have indeed been making one then copy pasting!! But we should totally add a function. Name suggestions? Maybe contra, since this is Einstein notation? https://en.wikiversity.org/wiki/Tensors/Calculations_with_index_notation

(contra 'a 2)
;;=> a↑2

Let's think of something better...

for the coordinatize definition I think the sicmutils version is better, since we follow convention GJS used elsewhere and give a proper symbolic name to the resulting operator. This is again the sort of thing that is nice for the user, but muddies up the code listing in the book proper.

Further Notes

you don't have to use seq, you can just (take 5 ...) and everything will Just Work.
For any place in the book that uses series:for-each, you can use doseq:

(doseq [x some-series]
  (clojure.pprint/pprint x))

We don't need a special series:for-each, we can use doseq which is that same thing for all sequences. (Works with up, down etc too!)

the evolution definition should be identical, except for some of the names that I expanded, and my use of the -> macro to let me write the statements in a slightly less nested order. Let me know if you see any bugs or differences! You can see the expanded names in the Scheme code here: https://github.com/Tipoca/scmutils/blob/master/src/calculus/vector-fields.scm#L366-L377

phasetr Oct 29, 2021
Author

Thank you for your replies and comments! I'll rewrite the comments and my codes.

Name suggestions? (for b↑i)

This is difficult, certainly. My ideas are flat by musical isomorphisms or b**i in some symbolic notation. The latter is from the exponentiation in other languages, e.g. Python. However these are confusing, of course.

sritchie Oct 29, 2021
Maintainer

@phasetr unfortunately there is a sharpen already... but possibly sharp-sym, flat-sym? or sharpen-sym, flatten-sym? That could be nice.

i am not as keen on b**i because it is not actually exponentiation, just an index thing. and then when we nest these we get a**i_j**k...

phasetr Oct 30, 2021
Author

@sritchie Why don't you use a name hat, just like a tex command name if using a function or macro for it?

phasetr · 2021-10-28T06:15:57Z

phasetr
Oct 28, 2021
Author

04. Basis Fields

Remark

P.45, Jacobian: Defined in sicmutils.calculus.basis.
P.50, R3-rect: Defined in sicmutils.calculus.manifold.
P.50, commutator: Defined in sicmutils.operator.
P.51, tests for e_x, e_y, e_z: We can check them as follows. See also the test code.

(let-coordinates [[x y z] R3-rect
                  [theta phi psi] Euler-angles]
  (let [e_x (+ (* (cos phi) d:dtheta)
               (* -1 (/ (* (sin phi) (cos theta)) (sin theta)) d:dphi)
               (* (/ (sin phi) (sin theta)) d:dpsi))
        e_y (+ (/ (* (cos phi) (cos theta) d:dphi) (sin theta))
               (* (sin phi) d:dtheta)
               (* -1 (/ (cos phi) (sin theta)) d:dpsi))
        e_z d:dphi
        f (literal-manifold-function 'f-Euler Euler-angles)
        SO3-point ((point Euler-angles) (up 'theta 'phi 'psi))]
    (list
     (render (((+ (commutator e_x e_y) e_z) f) SO3-point))
     (render (((+ (commutator e_y e_z) e_x) f) SO3-point))
     (render (((+ (commutator e_z e_x) e_y) f) SO3-point)))))

Edited: We can write the code as follows. See also the reply of this comment.

(let-coordinates [[x y z] R3-rect
                  [theta phi psi] Euler-angles]
  (let [e_x (+ (* (cos phi) d:dtheta)
               (* -1 (/ (* (sin phi) (cos theta)) (sin theta)) d:dphi)
               (* (/ (sin phi) (sin theta)) d:dpsi))
        e_y (+ (/ (* (cos phi) (cos theta) d:dphi) (sin theta))
               (* (sin phi) d:dtheta)
               (* -1 (/ (cos phi) (sin theta)) d:dpsi))
        e_z d:dphi
        f (literal-manifold-function 'f-Euler Euler-angles)
        SO3-point ((point Euler-angles) (up 'theta 'phi 'psi))]
    (render
     [(((+ (commutator e_x e_y) e_z) f) SO3-point)
      (((+ (commutator e_y e_z) e_x) f) SO3-point)
      (((+ (commutator e_z e_x) e_y) f) SO3-point)])))

(let-coordinates [[x y z] R3-rect
                  [theta phi psi] Euler-angles]
  (let [e_x (+ (* (cos phi) d:dtheta)
               (* -1 (/ (* (sin phi) (cos theta)) (sin theta)) d:dphi)
               (* (/ (sin phi) (sin theta)) d:dpsi))
        e_y (+ (/ (* (cos phi) (cos theta) d:dphi) (sin theta))
               (* (sin phi) d:dtheta)
               (* -1 (/ (cos phi) (sin theta)) d:dpsi))
        e_z d:dphi
        f (literal-manifold-function 'f-Euler Euler-angles)
        SO3-point (typical-point Euler-angles)]
    (render
     ((up
       ((+ (commutator e_x e_y) e_z) f)
       ((+ (commutator e_y e_z) e_x) f)
       ((+ (commutator e_z e_x) e_y) f))
      SO3-point))))

2 replies

sritchie Oct 29, 2021
Maintainer

Nice! My only note is that if you like, you can define SO3-point as (typical-point Euler-angles). It's nice and explicit the other way, and if you list everything out WITHOUT simplifying it's nicer to give explicit names. Just noting some further items from the API!

You could also put all three items in a vector or up and render the entire thing in one shot:

(render
 [(((+ (commutator e_x e_y) e_z) f) SO3-point)
  (((+ (commutator e_y e_z) e_x) f) SO3-point)
  (((+ (commutator e_z e_x) e_y) f) SO3-point)])

Another fun note is that an up of functions can be applied like a function. So you could make an up (not a vector, that is the difference, vectors as functions take an index and look up the item at the position of that index) and pass SO3-point to it a single time, then render the final result once:

(render
 ((up
   ((+ (commutator e_x e_y) e_z) f)
   ((+ (commutator e_y e_z) e_x) f)
   ((+ (commutator e_z e_x) e_y) f))
  SO3-point))

phasetr Oct 30, 2021
Author

Thank you for your comment! I edited the above code.

phasetr · 2021-10-28T07:25:34Z

phasetr
Oct 28, 2021
Author

05. Integration

Remark

P.63, check for (d theta): See the following code.

(def render (comp ->infix simplify))
(def R3-rect-point ((point R3-rect) (up 'x0 'y0 'z0)))

(def a (literal-manifold-function 'alpha R3-rect))
(def b (literal-manifold-function 'beta R3-rect))
(def c (literal-manifold-function 'gamma R3-rect))
(def X (literal-vector-field 'X-rect R3-rect))
(def Y (literal-vector-field 'Y-rect R3-rect))
(let-coordinates [(up x y z) R3-rect]
  (let [theta (+ (* a dx) (* b dy) (* c dz))]
    (render
     (((- (d theta)
          (+ (wedge (d a) dx)
             (wedge (d b) dy)
             (wedge (d c) dz)))
       X Y)
      R3-rect-point))))

P.64, check for (d omega): See the above and following codes.

(def Z (literal-vector-field 'Z-rect R3-rect))
(let-coordinates [(up x y z) R3-rect]
  (let [omega (+ (* a (wedge dy dz))
                 (* b (wedge dz dx))
                 (* c (wedge dx dy)))]
    (render
     (((- (d omega)
          (+ (wedge (d a) dy dz)
             (wedge (d b) dz dx)
             (wedge (d c) dx dy)))
       X Y Z)
      R3-rect-point))))

P.69, check codes: See the following codes.

(def a (literal-manifold-function 'a-rect R3-rect))
(def b (literal-manifold-function 'b-rect R3-rect))
(def c (literal-manifold-function 'c-rect R3-rect))
(def X (literal-vector-field 'X-rect R3-rect))
(def Y (literal-vector-field 'Y-rect R3-rect))
(def Z (literal-vector-field 'Z-rect R3-rect))
(let-coordinates [(up x y z) R3-rect]
  (let [flux-through-boundary-element (+ (* a (wedge dy dz))
                                         (* b (wedge dz dx))
                                         (* c (wedge dx dy)))
        production-in-volume-element (* (+ (d:dx a) (d:dy b) (d:dz c))
                                        (wedge dx dy dz))]
    (render
     (((- production-in-volume-element
          (d flux-through-boundary-element))
       X Y Z)
      R3-rect-point))))

0 replies

phasetr · 2021-10-28T08:50:55Z

phasetr
Oct 28, 2021
Author

06. Over a Map

Remarks

P.76, evaluation check: we do not have define-coordinates, we have to use let-coordinates.

(let-coordinates [t R1-rect]
  (render
   (((basis->oneform-basis S2-basis-over-mu)
     (basis->vector-basis S2-basis-over-mu))
    ((point R1-rect) 't0))))

(let-coordinates [t R1-rect]
  (render
   (((basis->oneform-basis S2-basis-over-mu)
     ((differential mu) d:dt))
    ((point R1-rect) 't0))))

P.81, literal-1form-field: We should use literal-oneform-field.

Questions

P.72, definition of vector-field->vector-field-over-map: This is defined on sicmutils.calculus.map, but its definition is somewhat different from the original. Why is it?
P.72, differential: This in env, but I cannot find the definition of it. I found (derive ::differential ::v/scalar) in sicmutils.differential.cljc. Is this the definition? (I am a Clojure newbie, I do not know Clojure language characteristics well.)
P.74, definition of form-field->form-field-over-map: This is defined on sicmutils.calculus.map, but its definition is somewhat different from the original. Why is it?

1 reply

sritchie Oct 29, 2021
Maintainer

for page 81, I went with oneform vs 1form because 1form-field by itself is not a valid var name in Clojure.
In vector-field->vector-field-over-map, our definition looks like the one in the actual Scheme codebase: https://github.com/Tipoca/scmutils/blob/master/src/calculus/maps.scm#L275-L287 it's slimmed down in the book to remove the part where a nice name gets assigned, since that makes the code listing a bit longer. Another place where having multiple, increasingly-complex definitions that act identically would be really nice.
For page 72, the definition of differential lives in: https://github.com/sicmutils/sicmutils/blob/master/src/sicmutils/calculus/map.cljc#L58-L72

(Not sure what editor you're in, but the jump-to-definition feature of Emacs and other editors is so nice for tracking down stuff like this. AND, to add to the confusion, sicmutils.differential exists... that implements a data structure that lets us do forward-mode automatic differentiation, and is unfortunately named to clash with this idea.)

page 74, here is the scheme version of that function from the library: https://github.com/Tipoca/scmutils/blob/master/src/calculus/maps.scm#L305-L328. The Clojure code follows this code pretty closely, and staring at it now I can't see any differences in meaning... but if you do, let me know! The only thing I did differently was to use an underscore for the m argument, to highlight that we do NOT use it in the first inner function.

As usual, the book code cut out the assigned symbolic name to the new vector field and nform-field, making the code listing tighter.

phasetr · 2021-10-29T08:59:04Z

phasetr
Oct 29, 2021
Author

07. Directional Derivatives

Remarks

P.92, (series:for-each print-expression (hoge) 5): We should write it as follows. See also ch7_test.cljc.

(let-coordinates [[x y z] R3-rect]
  (let [Jz (- (* x d:dy) (* y d:dx))]
    (render
     (take 5
           ((((exp (* 'a (Lie-derivative Jz))) d:dy)
             (literal-manifold-function 'f-rect R3-rect))
            ((point R3-rect) (up 1 0 0)))))))

P.100 covariant-derivative-form: Defined on sicmutils.calculus.covariant, a private function. This definition is somewhat different from the original.

(require '[sicmutils.calculus.form-field :as ff])
(require '[sicmutils.util.aggregate :as ua])
(require '[sicmutils.generic :as g])
(require '[sicmutils.value :as v])

(defn fdg-covariant-derivative-form
  [Cartan]
  (fn [V]
    (fn [tau]
      (let [k (ff/get-rank tau)
            nabla_V ((covariant-derivative-vector Cartan) V)
            op (fn [& vectors]
                 (let [vectors (into [] vectors)]
                   (assert (= k (count vectors)))
                   (g/- (V (apply tau vectors))
                        (ua/generic-sum
                         (fn [i]
                           (let [xs (update vectors i nabla_V)]
                             (apply tau xs)))
                         0 k))))
            name `((~'nabla ~(v/freeze V))
                   ~(v/freeze tau))]
        (ff/procedure->nform-field op k name)))))

P.103, typo in the original book?: (((((covariant-derivative R2-polar-Cartan) d/dx) J) f) R2-rect-point) is maybe (((((covariant-derivative R2-polar-Cartan) d/dx) circular) f) R2-rect-point).
P.107, sphere: We should write (def sphere (make-manifold S2-type 2 3)).
P.107, S2-spherical: Defined on sicmutils.calculus.manifold.
P.107, S2-Christoffel: Defined on sicmutils.test.sicmutils.calculus.curvature-tests.
P.113, states: You should check the order of the arguments because the one in the sicmutils is different from the one in the book.

(def states
  (coordinate-system-at state-space :rectangular :origin))

Questions

P.110, the code for state-advancer: I write the following code to check, but I ha some error, like Assert failed: (check-point this point). I tried to fix errors, but I could not find the solution. (The problem may be a trivial typo, of course.) What is the true code for it?

(ns functional-differential-geometry.tmp
  (:gen-class)
  (:require [sicmutils.env :as e :refer :all]))
(def sphere (make-manifold S2-type 2 3))
(def S2-basis (coordinate-system->basis S2-spherical))

(defn make-S2-Christoffel
  "P.107, See `sicmutils.test.sicmutils.calculus.curvature-tests`."
  [basis theta]
  (let [zero    zero-manifold-function
        symbols (down (down
                       (up zero zero)
                       (up zero (/ 1 (tan theta))))
                      (down
                       (up zero (/ 1 (tan theta)))
                       (up (- (* (sin theta)
                                 (cos theta)))
                           zero)))]
    (make-Christoffel symbols basis)))

(defn transform
  "P.109"
  [tilt]
  (fn [coords]
    (let [colat (ref coords 0)
          long (ref coords 1)
          x (* (sin colat) (cos long))
          y (* (sin colat) (sin long))
          z (cos colat)
          vp ((rotate-x tilt) (up x y z))
          colatp (acos (ref vp 2))
          longp (atan (ref vp 1) (ref vp 0))]
      (up colatp longp))))

(defn tilted-path
  "P.110"
  [tilt]
  (defn coords [t]
    ((transform tilt) (up (/ pi 2) t)))
  (compose (point S2-spherical)
           coords
           (chart R1-rect)))

;;; P.110: ERROR!
(let-coordinates [(up theta phi) S2-spherical
                  t R1-rect]
  (let [S2-Christoffel (make-S2-Christoffel S2-basis theta)
        sphere-Cartan (Christoffel->Cartan S2-Christoffel)
        g (fn [gamma Cartan]
            (let [omega ((Cartan->forms (Cartan->Cartan-over-map Cartan gamma))
                         ((differential gamma) d:dt))]
              (defn the-state-derivative []
                (fn [state]
                  (prn state)
                  (let [t ((point R1-rect) (ref state 0))
                        u (ref state 1)]
                    (up 1 (* -1 (omega t) u)))))
              the-state-derivative))]
   ((state-advancer (g (tilted-path 1) sphere-Cartan))
    (up 0 (* ((D (transform 1)) (up (/ pi 2) 0)) (up 1 0)))
    (/ pi 2))))

7 replies

sritchie Oct 29, 2021
Maintainer

Here is the definition of covariant-derivative-form in the original scheme: https://github.com/Tipoca/scmutils/blob/master/src/calculus/covariant-derivative.scm#L98-L111

The main difference is that the library version:

moves the calculation of k and nabla_V in the let binding up above the final anonymous function's entry point, which saves the work of calculating those each time the final fn is called. (Let me know if that doesn't make sense!)
The book version doesn't use procedure->nform-field, or have the inner assertion.

The Clojure version follows the full library version. Additionally:

our implementation of sigma is exclusive with respect to its upper bound (and is also named sicmutils.util.aggregate/generic-sum):

(generic-sum identity 1 3)
;;=> 3, ie, (+ 1 2)

And in scheme:

1 ]=> (sigma identity 1 3)
#| 6 |#, ie, (+ 1 2 3)

Since we have a full vector type available, this:

(list-with-substituted-coord
 vectors i
 (nabla_V (list-ref vectors i)))

becomes this:

(update vectors i nabla_V)

sritchie Oct 29, 2021
Maintainer

I TIHNK, @phasetr , that page 92 has another bug. Maybe you can confirm.

The code on the page is written for R3 but the result is for R2. If you run the code in the book, you get:

((((partial 1) f-rect) (up 1 0 0))
 (* a (((partial 0) f-rect) (up 1 0 0)))
 (* -1/2 (expt a 2) (((partial 1) f-rect) (up 1 0 0)))
 (* -1/6 (expt a 3) (((partial 0) f-rect) (up 1 0 0)))
 (* 1/24 (expt a 4) (((partial 1) f-rect) (up 1 0 0))))

While the book shows:

((((partial 0) f-rect) (up 1 0))
 (* -1 a (((partial 1) f-rect) (up 1 0)))
 (* -1/2 (expt a 2) (((partial 1) f-rect) (up 1 0)))
 (* 1/6 (expt a 3) (((partial 0) f-rect) (up 1 0)))
 (* 1/24 (expt a 4) (((partial 1) f-rect) (up 1 0))))

The (partial 0) and (partial 1) are switched, the point is in R2 vs R3 and the negative signs are distributed differently. Strange!

phasetr Oct 30, 2021
Author

I TIHNK, @phasetr , that page 92 has another bug. Maybe you can confirm.

I also found that difference, but I thought it a typo in the book 😅

I am going to read other comments thoroughly. Thank you!

sritchie Oct 30, 2021
Maintainer

@phasetr I spent a bunch of time with your page 110 bug, and managed to get it reproduced in Scheme too. This must be a bug that showed up after the book's publication, in some new version. I sent GJS a note tonight with the reproduction, so maybe he can help us out!

I also noticed that when we do implement define-coordinates, we'll have to be careful to run:

(define-coordinates (up theta phi) S2-spherical)

Since if not, the previous footnote directing us to run

(define-coordinates (up r theta) R2-rect)

will contribute the WRONG theta to functions defined after.

sritchie Oct 30, 2021
Maintainer

Whoops, forgot to submit these notes:

p103, I think that is totally a typo / bug
p107, could also do (def sphere S2)... right now manifolds are identical if they're created identically, but he has some statefulness in the original that MIGHT have been important.
p113, everything is looking good... I moved the manifold argument first so that we could match Clojure style, of data structure arguments first. Also this makes the fn easier to use with the -> threading macro.

phasetr · 2021-11-09T03:28:49Z

phasetr
Nov 9, 2021
Author

Chap08

Remarks

You can consult with sicmutils.test.fdg.ch8_test.cljc.
P.115, Riemann-curvature: Defined on sicmutils.calculus.curvature
P.116, Riemann: Defined on sicmutils.calculus.curvature
P.116, an example code: You should write it as follows.

(let-coordinates [[r theta phi] R3-spherical]
  ;; From `sicmutils.test.fdg.ch8_test.cljc`
  (let [spherical-Gamma (make-Christoffel
                         (let [O (fn [x] 0)]
                           (down
                            (down (up O O O)
                                  (up O (/ 1 r) O)
                                  (up O O (/ 1 r)))
                            (down (up O (/ 1 r) O)
                                  (up (* -1 r) O O)
                                  (up O O (/ (cos theta) (sin theta))))
                            (down (up O O (/ 1 r))
                                  (up O O (/ (cos theta) (sin theta)))
                                  (up (* -1 r (expt (sin theta) 2))
                                      (* -1 (sin theta) (cos theta))
                                      O))))
                         (coordinate-system->basis R3-spherical))
        spherical-Cartan (Christoffel->Cartan spherical-Gamma)]
    (render (((Riemann (covariant-derivative spherical-Cartan))
              dphi d:dtheta d:dphi d:dtheta)
             ((point R3-spherical) (up 'r0 'theta0 'phi0))))))

P.118, in Sigma and U-select: You should use nth instead of ref.
P.123, Ricci: Defined on sicmutils.calculus.curvature. The definition in sicmutils is somewhat different.
P.124, torsion-vector: Defined on sicmutils.calculus.curvature.
P.124, torsion: sicmutils.calculus.curvature
P.124: test for torsion-vector: See sicmutils.test.sicmutils.calculus.curvature_test.

(defn S2-Christoffel
  "From `sicmutils.test.sicmutils.calculus.curvature_test`."
  [basis theta]
  (let [zero    zero-manifold-function
        symbols (down (down
                       (up zero zero)
                       (up zero (/ 1 (tan theta))))
                      (down
                       (up zero (/ 1 (tan theta)))
                       (up (- (* (sin theta)
                                 (cos theta)))
                           zero)))]
    (make-Christoffel symbols basis)))

;;; P.124
(let-coordinates [[theta phi] S2-spherical]
  (let [S2-basis (coordinate-system->basis S2-spherical)
        S2C (S2-Christoffel S2-basis theta)
        sphere-Cartan (Christoffel->Cartan S2C)]
    (render
     (for [x [d:dtheta d:dphi]
           y [d:dtheta d:dphi]]
       ((((torsion-vector (covariant-derivative sphere-Cartan))
          x y)
         (literal-manifold-function 'f S2-spherical))
        ((point S2-spherical) (up 'theta0 'phi0)))))))

Questions

Nothing now.

0 replies

phasetr · 2021-11-09T08:00:24Z

phasetr
Nov 9, 2021
Author

Chap09

Since sritchie is writing new tests and implementations in this pull-request, I only write a memo.

Remarks

P.134-135, lower and raise: Defined on sicmutils.calculus.metric.
P.146, definition of nabla: We should write 'c in sicmutils instead of ':c in the book. (I checked the pull-request for Chapter 9 test).

Questions

Waiting (TODO)

P.146 spacetime-rect-basis: See the pull-request.

2 replies

sritchie Nov 10, 2021
Maintainer

Phew, I finally got that PR sorted out and slayed a bug that has eluded me for months. We can now solve einstein's field equations! And it is much faster than scmutils thanks to some nice memoization. Down to 90 seconds or so...

I am going to get all of this sorted out in the next couple of days and merged in, then cut a release so you can have all the goods.

sritchie Nov 12, 2021
Maintainer

Okay, not released yet, but all merged!!

phasetr · 2021-11-10T03:59:29Z

phasetr
Nov 10, 2021
Author

Chap10

Remarks

Questions

P.158, divergence: I suspect the result in sicmutils is different from the text. Is the implementation right?
P.158, Laplacian: Same as above.
P.160, Laplacian: I have an error in the below code with 1. Unhandled java.lang.IllegalArgumentException No implementation of method: :coordinate-prototype of protocol: #'sicmutils.calculus.manifold/ICoordinateSystem found for class: sicmutils.structure.Structure.
Here we have a symbol SR-basis, not SR-vector-basis in the book.
Or is this simply some typo in the book? (We also see it in 10.2.)

(let [SR R4-rect]
  (let-coordinates [[ct x y z] SR]
    (let [an-event ((point SR) ['ct0 'x0 'y0 'z0])
          a-vector (+ (* (literal-manifold-function 'v-hat-t SR) d:dct)
                      (* (literal-manifold-function 'v-hat-x SR) d:dx)
                      (* (literal-manifold-function 'v-hat-y SR) d:dy)
                      (* (literal-manifold-function 'v-hat-z SR) d:dz))
          g-Minkowski (fn [u v]
                        (+ (* -1 (dct u) (dct v))
                           (* (dx u) (dx v))
                           (* (dy u) (dy v))
                           (* (dz u) (dz v))))
          SR-vector-basis (coordinate-system->vector-basis SR)
          p (literal-manifold-function 'phi SR)]
      (myutil/render
       (((Laplacian g-Minkowski SR-vector-basis) p) an-event)))))

1 reply

sritchie Nov 10, 2021
Maintainer

That is another bug for sure. Add SR-basis to your let binding, defined like this:

(let [,,,,
      SR-basis (e/coordinate-system->basis SR)
      SR-vector-basis (e/basis->vector-basis SR-basis)
      ,,,,]
  ,,,,)

Note that I am now pulling SR-vector-basis from SR-basis, slightly different from the book but a touch more efficient.

phasetr · 2021-11-12T09:05:09Z

phasetr
Nov 12, 2021
Author

Chap10, Question Added

P.164, (d (SR-star F) ,,,): I write the code below.
In (* 4 :pi (SR-star four-current)),
I see Unhandled java.lang.IllegalArgumentException No method in multimethod 'mul' for dispatch value: [java.lang.Long clojure.lang.Keyword].
For 'pi and pi, I see Unhandled java.lang.AssertionError Assert failed: (vf/vector-field? vf).
How do I correct this?

(let [SR R4-rect]
  (let-coordinates [[ct x y z] SR]
    (let [an-event ((point SR) ['ct0 'x0 'y0 'z0])
          g-Minkowski (fn [u v]
                        (+ (* -1 (dct u) (dct v))
                           (* (dx u) (dx v))
                           (* (dy u) (dy v))
                           (* (dz u) (dz v))))
          SR-basis (coordinate-system->basis SR)
          SR-star (Hodge-star g-Minkowski SR-basis)
          Faraday (fn [Ex Ey Ez Bx By Bz]
                    (+ (* Ex (wedge dx dct))
                       (* Ey (wedge dy dct))
                       (* Ez (wedge dz dct))
                       (* Bx (wedge dy dz))
                       (* By (wedge dz dx))
                       (* Bz (wedge dx dy))))
          Maxwell (fn [Ex Ey Ez Bx By Bz]
                    (+ (* -1 Bx (wedge dx dct))
                       (* -1 By (wedge dy dct))
                       (* -1 Bz (wedge dz dct))
                       (* Ex (wedge dy dz))
                       (* Ey (wedge dz dx))
                       (* Ez (wedge dx dy))))
          J (fn [charge-density Ix Iy Iz]
              (- (* / 1 'c) (+ (* Ix dx) (* Iy dy) (* Iz dz))
                 (* charge-density dct)))
          F (Faraday (literal-manifold-function 'Ex SR)
                     (literal-manifold-function 'Ey SR)
                     (literal-manifold-function 'Ez SR)
                     (literal-manifold-function 'Bx SR)
                     (literal-manifold-function 'By SR)
                     (literal-manifold-function 'Bz SR))
          four-current (J (literal-manifold-function 'rho SR)
                          (literal-manifold-function 'Ix SR)
                          (literal-manifold-function 'Iy SR)
                          (literal-manifold-function 'Iz SR))]
      (render
       (((- (d (SR-star F)) (* 4 :pi (SR-star four-current)))
              d:dx d:dy :d:dz)
             an-event)))))

P.166, ((Force ’q F d/dct dx) an-event): I write the below,
and I see the error Unhandled java.lang.AssertionError Assert failed: (vf/vector-field? vf).
How do I fix this?

(let [SR R4-rect]
  (let-coordinates [[ct x y z] SR]
    (let [an-event ((point SR) ['ct0 'x0 'y0 'z0])
          g-Minkowski (fn [u v]
                        (+ (* -1 (dct u) (dct v))
                           (* (dx u) (dx v))
                           (* (dy u) (dy v))
                           (* (dz u) (dz v))))
          Faraday (fn [Ex Ey Ez Bx By Bz]
                    (+ (* Ex (wedge dx dct))
                       (* Ey (wedge dy dct))
                       (* Ez (wedge dz dct))
                       (* Bx (wedge dy dz))
                       (* By (wedge dz dx))
                       (* Bz (wedge dx dy))))
          Maxwell (fn [Ex Ey Ez Bx By Bz]
                    (+ (* -1 Bx (wedge dx dct))
                       (* -1 By (wedge dy dct))
                       (* -1 Bz (wedge dz dct))
                       (* Ex (wedge dy dz))
                       (* Ey (wedge dz dx))
                       (* Ez (wedge dx dy))))
          F (Faraday (literal-manifold-function 'Ex SR)
                     (literal-manifold-function 'Ey SR)
                     (literal-manifold-function 'Ez SR)
                     (literal-manifold-function 'Bx SR)
                     (literal-manifold-function 'By SR)
                     (literal-manifold-function 'Bz SR))
          ;; Not explicitly defined in the book
          eta-inverse (fn [u v]
                        (invert (g-Minkowski u v)))
          SR-basis (coordinate-system->basis SR)
          Force (fn [charge F four-velocity component]
                  (* -1 charge
                     (contract
                      (fn [a b]
                        (contract
                         (fn [e w]
                           (* (w four-velocity)
                              (F e a)
                              (eta-inverse b component)))
                         SR-basis))
                      SR-basis)))
          Ux (fn [beta]
               (+ (* (/ 1 (sqrt (- 1 (square beta)))) d:dct)
                  (* (/ beta (sqrt (- 1 (square beta)))) d:dx)))]
      ((Force 'q F d:dct dx) an-event))))

P.166, ((Force ’q F (Ux ’v/c) dct) an-event):
How do I write the symbol c/v in sicmutils?
v:c?

2 replies

sritchie Nov 12, 2021
Maintainer

p164, 1

You are correct in the guess that anywhere you see :c you should write 'c. Scheme doesn't have keywords, so the authors sometimes use symbols like :c in Scheme.

p164, 2

I think here you have a typo in your J definition. You are missing a set of parens... compare the first (yours) and the second (correct), and notice (/ 1 'c) instead of (* / 1 'c) ....

 J (fn [charge-density Ix Iy Iz]
              (- (* / 1 'c) (+ (* Ix dx) (* Iy dy) (* Iz dz))
                 (* charge-density dct)))

J (fn [charge-density Ix Iy Iz]
              (- (* (/ 1 'c) (+ (* Ix dx) (* Iy dy) (* Iz dz)))
                 (* charge-density 'c dct)))

With that change I get the correct answer.

Here is the full working snippet:

(let [SR R4-rect]
  (let-coordinates [[ct x y z] SR]
    (let [an-event ((point SR) ['ct0 'x0 'y0 'z0])
          g-Minkowski (fn [u v]
                        (+ (* -1 (dct u) (dct v))
                           (* (dx u) (dx v))
                           (* (dy u) (dy v))
                           (* (dz u) (dz v))))
          SR-basis (coordinate-system->basis SR)
          SR-star (Hodge-star g-Minkowski SR-basis)
          Faraday (fn [Ex Ey Ez Bx By Bz]
                    (+ (* Ex (wedge dx dct))
                       (* Ey (wedge dy dct))
                       (* Ez (wedge dz dct))
                       (* Bx (wedge dy dz))
                       (* By (wedge dz dx))
                       (* Bz (wedge dx dy))))
          Maxwell (fn [Ex Ey Ez Bx By Bz]
                    (+ (* -1 Bx (wedge dx dct))
                       (* -1 By (wedge dy dct))
                       (* -1 Bz (wedge dz dct))
                       (* Ex (wedge dy dz))
                       (* Ey (wedge dz dx))
                       (* Ez (wedge dx dy))))
          J (fn [charge-density Ix Iy Iz]
              (- (* (/ 1 'c) (+ (* Ix dx) (* Iy dy) (* Iz dz)))
                 (* charge-density dct)))
          F (Faraday (literal-manifold-function 'Ex SR)
                     (literal-manifold-function 'Ey SR)
                     (literal-manifold-function 'Ez SR)
                     (literal-manifold-function 'Bx SR)
                     (literal-manifold-function 'By SR)
                     (literal-manifold-function 'Bz SR))
          four-current (J (literal-manifold-function 'rho SR)
                          (literal-manifold-function 'Ix SR)
                          (literal-manifold-function 'Iy SR)
                          (literal-manifold-function 'Iz SR))]
      (render
       (((- (d (SR-star F)) (* 4 'pi (SR-star four-current)))
         d:dx d:dy d:dz)
        an-event)))))

p.166, 1

It must be that that definition of eta-inverse is not correct, since I am seeing that same error too (and also noticed that it is missing from the book). I will ask GJS...

p.166, 2

I would recommend writing that as 'c:v, but you could also write it out explicitly as 'c-over-v.

sritchie Nov 12, 2021
Maintainer

This PR implements all of the code for chapters 10 and 11 as tests. Give it a look!

#386

phasetr · 2021-11-16T13:13:24Z

phasetr
Nov 16, 2021
Author

@sritchie Thank you for your a lot of helpful comments!
I checked codes in the book, including Chapter 10 and 11.
From now I will check the test codes to study clojure style.

1 reply

sritchie Nov 16, 2021
Maintainer

Added #393 for define-coordinates, so that should make everything read much better!

sritchie · 2021-11-21T15:58:06Z

sritchie
Nov 21, 2021
Maintainer

@phasetr I wrote up a full set of errata for FDG that I'll include here. Thanks again!!

Errata for FDG

Chapter 1

Page 9: Cartan is used in geodesic-equation-residuals before it is
defined just after. Be careful to flip evaluation order of these two
listings.

Chapter 3

Page 24: the definition of v assumes that R2->R from page 16 is still
defined. This might be nice to add to the scmutils library so that this
code will work if users attempt chapter 3 independently.

The listing at the bottom of the page assumes R2-rect-point is still
defined.

Page 38: Note that omega was already defined on page 35.

Chapter 4

Page 44: Note that you need to install the R2-rect coordinate system:

(define-coordinates (up x y) R2-rect)

Chapter 5

Page 60: This page restates:

(define-coordinates (up x y z) R3-rect)

But assumes that the R3-rect-point binding still exists from the previous
chapter:

(define R3-rect-point ((point R3-rect) (up 'x0 'y0 'z0)))

Page 60: I was concerned that

(define-coordinates (up r theta z) R3-cyl)

installs z, dz and d/dz from cylindrical coordinates over top of the
rectangular coordinates. I know that these are equivalent for all intents and
purposes... just noting that maybe

(define-coordinates (up r theta z-cyl) R3-cyl)

would be more pedantic, and, maybe, more correct? Or maybe this affects
nothing.

Page 67: the definitions of alpha and beta assume that R2->R from page
16 is still defined.

Page 67 uses R2-rect-point without ever defining it. The definition is, of
course,

(define R2-rect-point ((point R2-rect) (up 'x0 'y0)))

Chapter 6

Page 75: the definition of S2 references the nonexistent manifold family
S^2 instead of S^2-type:

(define S2 (make-manifold S^2 2 3))

Chapter 7

On page 92, the result at the top of the page is not correct, and scmutils
won't produce it for the supplied code... I don't know enough to see how the
book result comes about, so I submit it to you for examination! The code on
the page is written for R3 but the result is for R2. If you run the code
in the book, you get:

((((partial 1) f-rect) (up 1 0 0))
 (* a (((partial 0) f-rect) (up 1 0 0)))
 (* -1/2 (expt a 2) (((partial 1) f-rect) (up 1 0 0)))
 (* -1/6 (expt a 3) (((partial 0) f-rect) (up 1 0 0)))
 (* 1/24 (expt a 4) (((partial 1) f-rect) (up 1 0 0))))

While the book shows:

((((partial 0) f-rect) (up 1 0))
 (* -1 a (((partial 1) f-rect) (up 1 0)))
 (* -1/2 (expt a 2) (((partial 1) f-rect) (up 1 0)))
 (* 1/6 (expt a 3) (((partial 0) f-rect) (up 1 0)))
 (* 1/24 (expt a 4) (((partial 1) f-rect) (up 1 0))))

The (partial 0) and (partial 1) are switched, the point is in R2 vs R3
and the negative signs are distributed differently. Strange!

Page 103: I believe the code listing at the end of the page subs in J where
circular belongs. The code shown is:

(((((covariant-derivative R2-polar-Cartan) d/dx) J) f) R2-rect-point)

The correct version is:

(((((covariant-derivative R2-polar-Cartan) d/dx) circular) f) R2-rect-point)

Page 107: the definition of S2-Christoffel will not work without
S2-spherical coordinates installed:

(define-coordinates (up theta phi) S2-spherical)

Page 107: The definition of sphere references the nonexistent S^2
manifold family instead of the correct S^2-type.

Chapter 8

Page 116: The code beginning here requires the S2-spherical coordinate
system:

(define-coordinates (up theta phi) S2-spherical)

Page 127 states "Where omega is an arbitrary one-form field." It would be
nice to add this definition to the setup in footnote 8:

(define omega (literal-oneform-field 'omega S2-spherical))

The torsion example on page 127 uses an f that has not yet been defined:

(let ((X (literal-vector-field ’X-sphere S2-spherical))
      (Y (literal-vector-field ’Y-sphere S2-spherical)))
  ((((torsion-vector nabla) X Y) f) m))

This can be fixed by adding the following to footnote 8's setup instructions:

(define f (literal-manifold-function f S2-spherical))

Chapter 9

Page 135: I'm not sure if it causes any problems, but raise as defined in
the book does not wrap its return procedure in procedure->vector-field,
like the scmutils version does. Other functions in the book are careful to
show this, so it might be worth a note.

Page 136: The code beginning here requires the S2-spherical coordinate
system and S2-basis:

(define-coordinates (up theta phi) S2-spherical)
(define S2-basis (coordinate-system->basis S2-spherical))

Page 141: The simplifier in the current build of scmutils can't simplify the
denominators to the book's terms with the 3/2 power. If this was
hand-simplified, great! Otherwise, maybe this is a regression in the
simplifier. I can't see a setting in rules.scm that would allow this, but I
haven't looked at the full set of rules in a while...

Page 146: The code in section 9.3 requires the spacetime-rect coordinate
system to be installed. spacetime-rect-basis is also used in the first code
block on this page without definition:

(define-coordinates (up t x y z) spacetime-rect)
(define spacetime-rect-basis (coordinate-system->basis spacetime-rect))

Page 147: V is passed as an argument to Newton-metric without first being
defined. V was declared inline above in the definition of nabla, and
should be explicitly defined like so:

(define V (literal-function ’V (-> (UP Real Real Real) Real)))

Page 147: the expression after "If we evaluate the right-hand side expression
we obtain" actually returns

(+ (* 1/2 (expt :c 4) rho)
   (* 2 (expt :c 2) rho (V (up x y z)))
   (* 2 rho (expt (V (up x y z)) 2)))

instead of the stated return value:

(* 1/2 (expt :c 4) rho)

Maybe the shown value is meant to be just the leading term, but this is worth
explaining.

Chapter 10

Page 159: the setup block should define SR-basis, as it is used in the last
example of the section, on page 160:

(define SR-basis (coordinate-system->basis SR))

If the setup block defined SR-basis then the SR-vector-basis definition
on page 160 could become:

(define SR-vector-basis (basis->vector-basis SR-basis))

Page 159: the Minkowski metric is written with a c^2 term, but all of the
following functions, results and discussion seem to assume that c is
normalized to 1. I would recommend a note on page 159 to this effect!

Including the c^2 term explicitly would require, I believe, the following
substitutions (along with result substitutions for the forms below):

;; page 159
(define (g-Minkowski u v)
  (+ (* -1 (square ':c) (dct u) (dct v))
     (* (dx u) (dx v))
     (* (dy u) (dy v))
     (* (dz u) (dz v))))

;; page 160
(define SR-vector-basis (down (* (/ 1 ':c) d/dct) d/dx d/dy d/dz))
(define SR-1form-basis (up (* ':c dct) dx dy dz))
(define SR-basis (make-basis SR-vector-basis SR-1form-basis))

(define (Faraday Ex Ey Ez Bx By Bz)
  (+ (* Ex ':c (wedge dx dct))
     (* Ey ':c (wedge dy dct))
     (* Ez ':c (wedge dz dct))
     (* Bx (wedge dy dz))
     (* By (wedge dz dx))
     (* Bz (wedge dx dy))))

;; page 161
(define (Maxwell Ex Ey Ez Bx By Bz)
  (+ (* -1 ':c Bx (wedge dx dct))
     (* -1 ':c By (wedge dy dct))
     (* -1 ':c Bz (wedge dz dct))
     (* Ex (wedge dy dz))
     (* Ey (wedge dz dx))
     (* Ez (wedge dx dy))))

(define (J charge-density Ix Iy Iz)
  (- (* (/ 1 ':c) (+ (* Ix dx) (* Iy dy) (* Iz dz)))
     (* charge-density 'c dct)))

;; page 163
(((d F) (* (/ 1 ':c) d/dct) d/dy d/dz) an-event)
(((d F) (* (/ 1 ':c) d/dct) d/dz d/dx) an-event)
(((d F) (* (/ 1 ':c) d/dct) d/dx d/dy) an-event)

;; page 164
(((- (d (SR-star F)) (* 4 :pi (SR-star 4-current)))
  (* (/ 1 ':c) d/dct) d/dy d/dz)
 an-event)

(((- (d (SR-star F)) (* 4 :pi (SR-star 4-current)))
  (* (/ 1 ':c) d/dct) d/dz d/dx)
 an-event)

(((- (d (SR-star F)) (* 4 :pi (SR-star 4-current)))
  (* (/ 1 ':c) d/dct) d/dx d/dy)
 an-event)

Page 165: In the definition of Force, eta-inverse is not defined, so the
following two code examples (and, presumably, exercise 10.1b) will not run!

Chapter 11

Page 178: This is not necessarily a "bug", but simplifying the expression
produced by the form at the top of the page is extremely slow on my machine,
in both scmutils and the Clojure port. Could be a regression? I have not
been able to get the computation to complete, and GCD times out.

Page 180 states "Assume that we have a base frame called home." The base
frame defined in the library is the-ether; I would recommend including one
of the the following definitions as setup:

(define home
  ((frame-maker base-frame-point base-frame-chart)
   'home 'home))

(define home the-ether)

0 replies

phasetr · 2021-12-04T01:32:12Z

phasetr
Dec 4, 2021
Author

It took some long days, but I checked the comments.
I also checked merging the pull request (and a bug fix) for define-coordinates.
I will check this, reread book, and rethink my code!

I think this discussion settled.
I may add comments in this discussion when I find some points.
Thank you for many helpful comments, @sritchie!

1 reply

sritchie Dec 4, 2021
Maintainer

@phasetr this was awesome!!! Thank you for the push here, @phasetr . I really needed this to get my act together and polish up FDG support.

I am riding well with this new momentum and, along with @light-matters and @MagusMachinae, converting the FDG book over into a series of org-mode files so that the book will be readable in an editor like Emacs, with an actual executable environment available.

Here is the repo: https://github.com/sicmutils/fdg-book

Here is my current plan: https://github.com/sicmutils/fdg-book/issues

I'd love to hear what you are working on, and any way that I can change up the plan to help you. Let me know!

Uh oh!

Differences between sicmutils and scmutils in Functional Differential Geometry #380

Uh oh!

Uh oh!

phasetr Oct 26, 2021

Remarks (Added)

Code samples

Typos in the book

define-coodinates

Replies: 16 comments · 28 replies

Uh oh!

phasetr Oct 26, 2021 Author

Prologue

Remarks

Questions

Uh oh!

Uh oh!

< 8000 div class="d-flex flex-items-center"> sritchie Oct 26, 2021 Maintainer

Uh oh!

Uh oh!

phasetr Oct 26, 2021 Author

1. Prologue

Remarks

Questions

Uh oh!

sritchie Oct 26, 2021 Maintainer

Uh oh!

phasetr Oct 30, 2021 Author

Uh oh!

Uh oh!

phasetr Oct 26, 2021 Author

2. Manifolds

Questions

Uh oh!

Uh oh!

sritchie Oct 26, 2021 Maintainer

Uh oh!

sritchie Oct 26, 2021 Maintainer

Uh oh!

phasetr Oct 26, 2021 Author

Uh oh!

Uh oh!

phasetr Oct 27, 2021 Author

2. Manfolds (Added)

Remarks

Uh oh!

sritchie Oct 29, 2021 Maintainer

Uh oh!

phasetr Oct 27, 2021 Author

03. Vector Fields and One-form Fields

Remarks

Uh oh!

sritchie Oct 29, 2021 Maintai 9E88 ner

Further Notes

Uh oh!

phasetr Oct 29, 2021 Author

Uh oh!

sritchie Oct 29, 2021 Maintainer

Uh oh!

phasetr Oct 30, 2021 Author

Uh oh!

Uh oh!

phasetr Oct 28, 2021 Author

04. Basis Fields

Remark

Uh oh!

sritchie Oct 29, 2021 Maintainer

Uh oh!

phasetr Oct 30, 2021 Author

Uh oh!

phasetr Oct 28, 2021 Author

05. Integration

Remark

Uh oh!

phasetr Oct 28, 2021 Author

06. Over a Map

Remarks

Questions

Uh oh!

phasetr
Oct 26, 2021

`define-coodinates`

Replies: 16 comments 28 replies

phasetr
Oct 26, 2021
Author

< 8000 div class="d-flex flex-items-center"> sritchie Oct 26, 2021
Maintainer

phasetr
Oct 26, 2021
Author

sritchie Oct 26, 2021
Maintainer

phasetr Oct 30, 2021
Author

phasetr
Oct 26, 2021
Author

sritchie Oct 26, 2021
Maintainer

sritchie Oct 26, 2021
Maintainer

phasetr Oct 26, 2021
Author

phasetr
Oct 27, 2021
Author

sritchie Oct 29, 2021
Maintainer

phasetr
Oct 27, 2021
Author

sritchie Oct 29, 2021
Maintai 9E88 ner

phasetr Oct 29, 2021
Author

sritchie Oct 29, 2021
Maintainer

phasetr Oct 30, 2021
Author

phasetr
Oct 28, 2021
Author

sritchie Oct 29, 2021
Maintainer

phasetr Oct 30, 2021
Author

phasetr
Oct 28, 2021
Author

phasetr
Oct 28, 2021
Author