Hm, it's been many many years since I've used ScmUtils, it's changed quite a bit. Someone with more recent experience may want to jump in. :-)
If I recall correctly, L-free-particle is a function accepting a single argument, mass, and returns a function (representing a free particle Lagrangian, for those who know about these things). The variable `'local' should be a tuple of the form (q,v,t), where q is a vector of reals (particle position) and v = another vector (velocity). The `velocity' procedure just accesses the second slot. I'm guessing the `up' procedure constructs a vector from its arguments; it is presumably called up because ScmUtils distinguishes vectors from covectors, and in the usual Einstein notation vectors get superscript indices. There should also be a `down' procedure for constructing covectors. (The distinction becomes useful when one gets to Hamiltonian mechanics.) ScmUtils implements automatic differentiation (along with other operations on functions, e.g., +, *, composition) via generic functions, and the expression (literal-function 'x) constructs a function object named "x" that can be manipulated within this system. Functions like L-free-particle are generic too. So if you did something like (define state (up (literal-function 'q) (literal-function 'v))) ((L-free-paricle 'm) state) then you would get a symbolic representation of the free particle Lagrangian for a particle with mass m and state vector (q,v), which you can then use to e.g. derive the Euler-Lagrange equations, which in traditional notation looks like d/dt [L_v(q(t),v(t))] - L_q(q(t),v(t)) = 0. This involves differentiating the Lagrangian L, as well as time-differentiating the composition of a partial derivative of L with the particle path. This makes use of ScmUtil's automatic differentiation facility -- in the free particle example, this means dot-product and * are rigged so that they do the right thing when their inputs are functions. If you passed in numeric values instead, the same function should evaluate the Lagrangian, e.g., ((L-free-particle 1) (up (vector 1 2) (vector 3 4))) should give you 25/2. Again, in the example above, this would work because dot-product and * have been rigged to do the right thing when their inputs are numbers or numeric vectors. (Sorry if this doesn't make complete sense; there's a lot to explain, and my memory's a bit hazy. Also, I don't have ScmUtils installed and haven't run any of the examples above, but hopefully they convey the idea.) Anyway, I'd imagine duplicating the full functionality of ScmUtils in Julia is not only possible, but may even be fun to do because one can exploit multiple dispatch. But it might be a fair bit of work. KL On Friday, October 10, 2014 8:44:53 AM UTC-7, Erik Schnetter wrote: > > I'm not quite certain about Scheme syntax. So L-free-particle is a > function accepting one argument "mass" that returns another function > accepting an argument "local"? And you are renaming "local" to > "tuple"? (I would have gone with "loc".) > > What do you mean by "constructor for symbolic manipulation"? Julia > does support symbolic manipulation; this is e.g. used in macros, and > there is a class "Expr" that holds unevaluated expressions. However, > there are no built-in functions in Julia e.g. for differentiation or > simplification of such expressions as you would find in a computer > algebra system. Do SCMUTILS provide these? > > Let me take a wild guess: The function q assembles a tuple consisting > of three functions. These functions are known by their names, but > their definitions may not be available yet. This would read the > following way in Julia: > > ``` > q = quote (x,y,z) end > ``` > or in a more concise notation > ``` > q = :(x,y,z) > ``` > > Later, in an environment where x, y, and z are defined, you can > "eval(q)", as in "eval(q)[1](value)", which would be equivalent to > "x(value)". > > -erik > > > > On Fri, Oct 10, 2014 at 9:32 AM, Amuthan A. Ramabathiran > <[email protected] <javascript:>> wrote: > > Any updates on this? > > > > Amuthan > > > > On Tuesday, January 14, 2014 3:31:16 PM UTC-8, Brian Cohen wrote: > >> > >> Most code examples for Julia are aimed at users of existing statistical > >> and numerical software without demonstrating how functional programming > can > >> be substantially more useful for their field. In many ways, Julia is a > Lisp > >> without S-Expressions, so I didn't think it would be unwise to port > code > >> examples from Structure and Interpretation of Classical Mechanics from > >> Scheme to Julia. This book shows how functional programming can be > directly > >> applied to the formalism of Lagrangian and Hamiltonian Mechanics, but > Scheme > >> & SCMUtils may be too obscure and syntactically different from what > people > >> are used to for most people in the physical sciences. > >> > >> Book review: http://www.ids.ias.edu/~piet/publ/other/sicm.html > >> > >> I was impatient, and decided to just start porting code, so the first > >> example was easy enough: > >> > >> (define ((L-free-particle mass) local) > >> (let ((v (velocity local))) > >> (* 1/2 mass (dot-product v v)))) > >> > >> would become something like lFreeParticle(mass) = tuple -> begin v = > >> velocity(tuple); mass * dot(v,v) / 2 end. So far so good. > >> > >> But it's not long that I encounter usage of SCMUTILS > >> > >> (define q > >> (up (literal-function 'x) > >> (literal-function 'y) > >> (literal-function 'z))) > >> > >> So I turn to the Appendix which talks about Symbolic values in Scheme, > and > >> confirming it in the SCMUTILS documentation, it appears that symbols > have > >> the same type as real numbers, which seems very different than symbolic > >> expressions as described in the Julia documentation. Here, up > constructs a > >> tuple, and literal-function is a constructor for symbolic manipulation. > At > >> this point, I'm not sure how to proceed, but am still looking into the > >> matter. I see that the only packages that mention symbolic manipulation > are > >> a SymPy interface and a Calculus package. > > > > -- > Erik Schnetter <[email protected] <javascript:>> > http://www.perimeterinstitute.ca/personal/eschnetter/ >
