A detail he mentioned, was that during his tests SymPy frequently failed to solve integrals that Sage (using Maxima) was able to solve. An explanation, in which I like to believe, would be that he was testing an old version of SymPy lacking the new integration routines implemented during the last few GSoC projects. Hence my decision the compare the most recent versions of both projects.

The tested versions are SymPy 0.7.2 and Sage 5.3.

Depending on screen size and wordpress theme the table might be badly formatted so here is a link to the wiki html page and a pdf version.

It should be noted that Sage is more rigorous about the assumptions on its symbols and so it fails to integrate something like if is not explicitly different than -1. I personally think that this is a feature and not a bug. Due to this difference however the script used to test Sage differs from the one used for SymPy.

Another minor methodological difference in the tests is the fact that the timeout pattern that I used failed to work for the Sage interpreter. Hence, SymPy integration timeouts at about 120 seconds while Sage integration is manually interrupted when it takes too much time.

Final methodological difference is that I purge the SymPy cache between each integral as otherwise the RAM usage becomes too great.

The results show that SymPy is slightly better in using special functions to solve integrals, but there are also a few integrals that Sage solves while SymPy fails to do so. On few occasions Sage fails disgracefully, meaning  that it returns an error instead of unevaluated integral. When both packages fail to evaluate the integral SymPy is much slower to say so (timeout for SymPy compared to 1 or 2 seconds for Sage to return an unevaluated integral). Finally, on some occasions the results by Sage seem better simplified.

Integrals solved better by SymPy (if you consider special functions “better”):

• with the use of a special function while Sage returns unevaluated integrals
• with the use of a special function while Sage returns unevaluated integrals
• with the use of a special function while Sage returns unevaluated integrals
• with the use of a special function while Sage returns unevaluated integrals

Integrals solved better by Sage:

• solved by both but Sage’s result is simpler (it uses arctan instead of log)
• SymPy fails this simple integral
• solved by both but Sage’s result is much simpler
• SymPy fails
• SymPy fails
• SymPy fails
• SymPy fails

The code for the SymPy tests:

import signal
from time import clock
from sympy import *
from sympy.core.cache import clear_cache

class TimeoutException(Exception):
pass

def timeout_handler(signum, frame):
raise TimeoutException()

a, b, x = symbols('a b x')
n, m = symbols('n m', integer=True)

integrants = [
x,
a*x**n,
a*x**n + 1,
a*x**b + 1,

1/x,
1/(x + 1),
1/(x**2 + 1),
1/(x**3 + 1),
1/(a*x**n),
1/(a*x**n + 1),
1/(a*x**b + 1),

a*x**2/(b*x**2 + 1),
a*x**3/(b*x**3 + 1),
a*x**n/(b*x**m + 1),
(a*x**2 + 1)/(b*x**2 + 1),
(a*x**3 + 1)/(b*x**3 + 1),
(a*x**n + 1)/(b*x**m + 1),
(a*x**5 + x**3 + 1)/(b*x**5 + x**3 + 1),

sqrt(1/x),
sqrt(1/(x + 1)),
sqrt(1/(x**2 + 1)),
sqrt(1/(x**3 + 1)),
sqrt(1/(a*x**n)),
sqrt(1/(a*x**n + 1)),
sqrt(1/(a*x**b + 1)),
sqrt(a*x**2/(b*x**2 + 1)),
sqrt(a*x**3/(b*x**3 + 1)),
sqrt(a*x**n/(b*x**m + 1)),
sqrt((a*x**2 + 1)/(b*x**2 + 1)),
sqrt((a*x**3 + 1)/(b*x**3 + 1)),
sqrt((a*x**n + 1)/(b*x**m + 1)),
sqrt((a*x**5 + x**3 + 1)/(b*x**5 + x**3 + 1)),

log(x),
log(1/x),
log(1/(x + 1)),
log(1/(x**2 + 1)),
log(1/(x**3 + 1)),
log(1/(a*x**n)),
log(1/(a*x**n + 1)),
log(1/(a*x**b + 1)),
log(a*x**2/(b*x**2 + 1)),
log(a*x**3/(b*x**3 + 1)),
log(a*x**n/(b*x**m + 1)),
log((a*x**2 + 1)/(b*x**2 + 1)),
log((a*x**3 + 1)/(b*x**3 + 1)),
log((a*x**n + 1)/(b*x**m + 1)),
log((a*x**5 + x**3 + 1)/(b*x**5 + x**3 + 1)),

sin(x),
sin(x)**n*cos(x)**m,
sin(a*x)**n*cos(b*x)**m,
1/sin(x),
1/(sin(x) + 1),
1/(sin(x)**2 + 1),
1/(sin(x)**3 + 1),
1/(a*sin(x)**n),
1/(a*sin(x)**n + 1),
1/(a*sin(x)**b + 1),
a*sin(x)**2/(b*sin(x)**2 + 1),
a*sin(x)**3/(b*sin(x)**3 + 1),
a*sin(x)**n/(b*sin(x)**m + 1),
(a*sin(x)**2 + 1)/(b*sin(x)**2 + 1),
(a*sin(x)**3 + 1)/(b*sin(x)**3 + 1),
(a*sin(x)**n + 1)/(b*sin(x)**m + 1),
(a*sin(x)**5 + sin(x)**3 + 1)/(b*sin(x)**5 + sin(x)**3 + 1),
]

integrated = []
durations = []

f_integrants = open('dump_integrants', 'w')
f_integrated = open('dump_integrated', 'w')
f_durations = open('dump_duration', 'w')

for index, integrant in enumerate(integrants):
clear_cache()
print '====================================='
print index, ' of ', len(integrants)
print '###', integrant
start = clock()
try:
old_handler = signal.signal(signal.SIGALRM, timeout_handler)
signal.alarm(120)
integrated.append(integrate(integrant, x))
signal.alarm(0)
except TimeoutException:
integrated.append(TimeoutException)
finally:
signal.signal(signal.SIGALRM, old_handler)
durations.append(clock() - start)
print '###', integrated[-1]
print 'in %f seconds'%durations[-1]

f_integrants.write(str(integrant))
f_integrated.write(str(integrated[-1]))
f_durations.write(str(durations[-1]))
f_integrants.write('\n')
f_integrated.write('\n')
f_durations.write('\n')

And for Sage:

import signal
from time import clock
from sage.all import *
from sage.symbolic.integration.integral import indefinite_integral

class TimeoutException(Exception):
pass

def timeout_handler(signum, frame):
raise TimeoutException()

a, b, x = var('a b x')
n, m = var('n m')
assume(n, 'integer')
assume(m, 'integer')

assume(n != 1)
assume(n != -1)
assume(n != 2)
assume(n>0)
assume(b != 1)
assume(b != -1)
assume(b>0)
assume(a>0)

integrants = [
x,
a*x**n,
a*x**n + 1,
a*x**b + 1,

1/x,
1/(x + 1),
1/(x**2 + 1),
1/(x**3 + 1),
1/(a*x**n),
1/(a*x**n + 1),
1/(a*x**b + 1),

a*x**2/(b*x**2 + 1),
a*x**3/(b*x**3 + 1),
a*x**n/(b*x**m + 1),
(a*x**2 + 1)/(b*x**2 + 1),
(a*x**3 + 1)/(b*x**3 + 1),
(a*x**n + 1)/(b*x**m + 1),
(a*x**5 + x**3 + 1)/(b*x**5 + x**3 + 1),

sqrt(1/x),
sqrt(1/(x + 1)),
sqrt(1/(x**2 + 1)),
sqrt(1/(x**3 + 1)),
sqrt(1/(a*x**n)),
sqrt(1/(a*x**n + 1)),
sqrt(1/(a*x**b + 1)),
sqrt(a*x**2/(b*x**2 + 1)),
sqrt(a*x**3/(b*x**3 + 1)),
sqrt(a*x**n/(b*x**m + 1)),
sqrt((a*x**2 + 1)/(b*x**2 + 1)),
sqrt((a*x**3 + 1)/(b*x**3 + 1)),
sqrt((a*x**n + 1)/(b*x**m + 1)),
sqrt((a*x**5 + x**3 + 1)/(b*x**5 + x**3 + 1)),

log(x),
log(1/x),
log(1/(x + 1)),
log(1/(x**2 + 1)),
log(1/(x**3 + 1)),
log(1/(a*x**n)),
log(1/(a*x**n + 1)),
log(1/(a*x**b + 1)),
log(a*x**2/(b*x**2 + 1)),
log(a*x**3/(b*x**3 + 1)),
log(a*x**n/(b*x**m + 1)),
log((a*x**2 + 1)/(b*x**2 + 1)),
log((a*x**3 + 1)/(b*x**3 + 1)),
log((a*x**n + 1)/(b*x**m + 1)),
log((a*x**5 + x**3 + 1)/(b*x**5 + x**3 + 1)),

sin(x),
sin(x)**n*cos(x)**m,
sin(a*x)**n*cos(b*x)**m,
1/sin(x),
1/(sin(x) + 1),
1/(sin(x)**2 + 1),
1/(sin(x)**3 + 1),
1/(a*sin(x)**n),
1/(a*sin(x)**n + 1),
1/(a*sin(x)**b + 1),
a*sin(x)**2/(b*sin(x)**2 + 1),
a*sin(x)**3/(b*sin(x)**3 + 1),
a*sin(x)**n/(b*sin(x)**m + 1),
(a*sin(x)**2 + 1)/(b*sin(x)**2 + 1),
(a*sin(x)**3 + 1)/(b*sin(x)**3 + 1),
(a*sin(x)**n + 1)/(b*sin(x)**m + 1),
(a*sin(x)**5 + sin(x)**3 + 1)/(b*sin(x)**5 + sin(x)**3 + 1),
]

integrated = []
durations = []

f_integrants = open('dump_integrants', 'w')
f_integrated = open('dump_integrated', 'w')
f_durations = open('dump_duration', 'w')

for index, integrant in enumerate(integrants):
print '====================================='
print index, ' of ', len(integrants)
print '###', integrant
start = clock()
try:
old_handler = signal.signal(signal.SIGALRM, timeout_handler)
signal.alarm(120)
integrated.append(indefinite_integral(integrant, x))
signal.alarm(0)
except Exception, e:
integrated.append(e)
finally:
signal.signal(signal.SIGALRM, old_handler)
durations.append(clock() - start)
print '###', integrated[-1]
print 'in %f seconds'%durations[-1]

f_integrants.write(str(integrant))
f_integrated.write(str(integrated[-1]))
f_durations.write(str(durations[-1]))
f_integrants.write('\n')
f_integrated.write('\n')
f_durations.write('\n')

Below is the complete table (available as a wiki html page and a pdf).

This graph, besides showing naively in a rather simplistic way the structure of the theory of differential geometry (and most of what I have implemented in the diffgeom module), brings attention to the one non-trivial part of the module on which I have spent most of my time lately. Namely, implementing covariant derivatives.

All directional derivatives are defined as a limiting procedure on a transport operator. Besides the Lie derivatives which use a certain transport operator that is easy to express in a coordinate free way, all other derivatives, called covariant derivatives have to be expressed using something called Christoffel symbols. And these are the ugly coordinate-dependent sources of pain, as the module structure becomes very cumbersome when such dependence must be accounted for. Thankfully, I think I have found a nice way to implement them in a new CovariantDerivativeOperator class on its own, that will contain all the logic in the same way in which the Base*Field classes do it. This will also require rewrite of the LieDerivative into a LieDerivativeOperator class.

• The basics about coordinate systems and fields are already in. There are numerous issues with all the simplify-like algorithms inside SymPy, however they are slowly ironed out.
• Some simplistic methods for work with integral curves are implemented.
• The basics of tensor/wedge products are in. Many simplification routines can be added. Contraction between tensor products and vectors is possible (special case of “lowering of an index”).
• Over-a-map, pushforwards and pullbacks are not implemented yet.
• Instead of them I have focused my work on derivatives and curvature tensors. For the moment work on these can be done in a limited coordinate-dependent way. A longer post explaining the theory is coming and with it an implementation slightly less dependent on coordinates (working with Christoffel symbols is a pain).
• Hodge star operator – still not implemented.

An example that I want to implement is a theorem that in irrotational cosmology isotropy implies homogeneity. Doing this will be the first non-trivial example in this module.

A serendipitous detour from the project was my work on the differential equations solver. Aaron had implemented a very thorough solver for single equations. I had tried to extend it in a few simple ways in order to work with systems of ODEs and initial conditions. However this led me to Jordan forms of matrices, generalized eigenvectors and a bunch of interesting details on which I work in my free time (especially this week).

За всяка демокрация е важно гражданите лесно да могат да се свържат с избранниците си. Ние трябва да влияем на народните представители не само когато ги избираме. През целият им мандат трябва да посочваме остро когато сме разочаровани от глупави действия. Също така е важно да посочваме на работливите и примерни депутати, че оценяваме когато се опълчват на глупави решения.

За жалост сайтът на парламента не дава списък с адресите на депутатите. Всеки адрес трябва отделно да се прочита от различна страница. Тук давам списък с всички тези адреси събрани чрез скрипт, който ще споделя по-долу.

Ако се питате за каква добра кауза може да ползвате този списък днес, знайте че ще е полезно да изразите острото си несъгласие с идиотския начин, по който ГЕРБ погребва математическите гимназии в момента.

ГЕРБ 39.70%

peter.petrov@parliament.bg, yordan.andonov@parliament.bg, valentin.mikev@parliament.bg, v.mikev@abv.bg, vladimir.toshev@parliament.bg, vtoshev@gmail.com, hristo.hristov@parliament.bg, daniela.petrova@parliament.bg, hristina.yancheva@parliament.bg, krasimir.tsipov@parliament.bg, plamen.roussev@parliament.bg, stefan.gospodinov@parliament.bg, teodora.georgieva@parliament.bg, stefan.dedev@parliament.bg, antoniy.yordanov@parliament.bg, dimitar.lazarov@parliament.bg, georgi.plachkov@parliament.bg, katya.koleva@parliament.bg, nedyalko.slavov@parliament.bg, daniel.georgiev@parliament.bg, cem_dimitrova@abv.bg, ivelin.nikolov@parliament.bg, iliya.pashev@parliament.bg, emil.dimitrov@parliament.bg, nikolay.petkov@parliament.bg, evgeni.stoev@parliament.bg, svetomir.mihaylov@parliament.bg, stanka.shaylekova@parliament.bg, ralitsa.todorova@parliament.bg, stefani.mihaylova@parliament.bg, vesselin.davidov@parliament.bg, katya.chalakova@parliament.bg, r.stoilov@parliament.bg, velichka.shopova@parliament.bg, dimitar.atanasov@parliament.bg, boris.grozdanov@parliament.bg, vladislav.dimitrov@parliament.bg, galina.mileva@parliament.bg, s.tanchev@parliament.bg, p.daskalov@parliament.bg, dimitar.avramov@parliament.bg, monika.panayotova@parliament.bg, diana.yordanova@parliament.bg, angel.daskalov@parliament.bg, zoya.georgieva@parliament.bg, dzhema.grozdanova@parliament.bg, emanouela.spassova@parliament.bg, lyubomila.stanislavova@nt52.parliament.bg, fani.hristova@parliament.bg, aleksandar.nenkov@parliament.bg, todor.dimitrov@parliament.bg, ivaylo.toshev@parliament.bg, ivan.valkov@parliament.bg, emil.radev@parliament.bg, krasimir.velchev@parliament.bg, z.todorov@parliament.bg, vyara.petrova@parliament.bg, dimitar.boychev@parliament.bg, dobroslav.dimitrov@parliament.bg, ivan.petrov@parliament.bg, plamen.nunev@parliament.bg, s.dukova@parliament.bg, anastas.anastasov@parliament.bg, tsveta.karayancheva@parliament.bg, cveta_@abv.bg, dimitar.glavchev@parliament.bg, svetlana.angelova@parliament.bg, tsvetan.sichanov@parliament.bg, menda.stoyanova@parliament.bg, LachezarBogomilov@parliament.bg, r.danev@parliament.bg, kiril.kalfin@parliament.bg, nikolay.rashev@parliament.bg, stanislav.ivanov@parliament.bg, petko.petkov@parliament.bg, v.angelov@parliament.bg, vanya.doneva@parliament.bg, kostadin.yazov@parliament.bg, stoyan.gyuzelev@parliament.bg, fidosova@gbg.bg, georgi.andonov@parliament.bg, ivan.kolev@parliament.bg, krasimir.petrov@parliament.bg, genoveva.aleksieva@parliament.bg, svetoslav.nedelchev@parliament.bg, emil.karanikolov@parliament.bg, asparuh.stamenov@parliament.bg, tsvetomir.mihov@parliament.bg, nikolay.kostadinov@parliament.bg, pavel.dimitrov@parliament.bg, lili.boyanova@parliament.bg, ginche.karaminova@parliament.bg, miroslav.petkov@parliament.bg, ioana.kirova@parliament.bg, ivan.bozhilov@parliament.bg, silviya.hubenova@parliament.bg, svetoslav.tonchev@parliament.bg, Predsedatel@parliament.bg, l.tatarski@parliament.bg, yanko.ivanov@parliament.bg, galina.bankovska@parliament.bg, daniela.mitkova@parliament.bg, yuliana.koleva@parliament.bg, emil.gushterov@parliament.bg, anatoliy.yordanov@parliament.bg, ivan.ivanov@parliament.bg, krasimira.simeonova@parliament.bg, daniela.daritkova@parliament.bg, mitko.zahov@parliament.bg, dian.chervenkondev@parliament.bg, i.sokolova@parliament.bg, liliya.hristova@parliament.bg, plamen.tachev@parliament.bg, neli.kalneva@parliament.bg, neli_iva@abv.bg, aleksandar.stoykov@parliament.bg, a.krustev@parliament.bg, desislava.taneva@parliament.bg

“Коалиция за България” 17.70%

asen.gagauzov@parliament.bg, spas.panchev@parliament.bg, rumen.petkov@parliament.bg, dragomir.stoynev@parliament.bg, e.maslarova@parliament.bg, Takorov@parliament.bg, m.hristova@parliament.bg, boyko.velikov@parliament.bg, kiril.dobrev@parliament.bg, i.nikolov@parliament.bg, a.radoslavov@parliament.bg, dimitar.gorov@parliament.bg, dimcho.mihalevski@parliament.bg, ganastasov@parliament.bg, dimitar.dabov@parliament.bg, kornesov@parliament.bg, rumen.ovcharov@parliament.bg, G.Pirinski@parliament.bg, stanishev@parliament.bg, petar.mutafchiev@parliament.bg, anaydenov@parliament.bg, , atanas.merdjanov@parliament.bg, evgeniy.zhelev@parliament.bg, georgi.petarneychev@parliament.bg, a.pantev@parliament.bg, z.georgiev@parliament.bg, P.Oresharski@parliament.bg, anton.kutev@parliament.bg, korneliya.ninova@parliament.bg, pkouroumbashev@parliament.bg, P.Atanasov@parliament.bg, p.dimitrov@parliament.bg, valentina.bogdanova@parliament.bg, yanaki.stoilov@parliament.bg, gbojinov@parliament.bg, mmikov@nt52.parliament.bg, Prof.St.Danailov@parliament.bg

ДПС “Движение за права и свободи” 14.50%

korman@parliament.bg, r.atalay@parliament.bg, n.sahlim@parliament.bg, elin.andreev@parliament.bg, gyunay.sefer@parliament.bg, H.Hadjihasan@parliament.bg, jordan.tsonev@parliament.bg, G.Serbest@parliament.bg, lyutvi.mestan@parliament.bg, n.ali@parliament.bg,nedzhmi.ali@parliament.bg, remzi.osman@parliament.bg, yanko.yankov@parliament.bg, ahmed.dogan@parliament.bg, emil.ivanov@parliament.bg, musa.palev@parliament.bg, arif.agush@parliament.bg, kamen.kostadinov@parliament.bg, h.bisserov@parliament.bg, ademov@parliament.bg, U.Tasim@parliament.bg, t.naimov@parliament.bg, belgin@parliament.bg, kasim.dal@parliament.bg, i.mihailova@parliament.bg, mithat.metin@parliament.bg, hamid.hamid@parliament.bg, DMustafa@parliament.bg, delyan.peevski@parliament.bg, emel.etem@parliament.bg, younal.loutfi@parliament.bg, djevdet.chakarov@parliament.bg, erdoan.ahmedov@parliament.bg, a.imamov@parliament.bg, Kardjaliev@parliament.bg, p.raeva@parliament.bg, tab61@parliament.bg

Партия “Атака” 9.36%

lyubomir.vladimirov@parliament.bg, kamen.petkov@parliament.bg, pavel.shopov@parliament.bg, ognyan.peychev@parliament.bg, stanislav.stanilov@parliament.bg, pehlivanov@parliament.bg, ognian.tetimov@parliament.bg, dgajeva@abv.bg,denitsa.gadjeva@parliament.bg, kalina.krumova@parliament.bg, stoyan.ivanov@parliament.bg, stoichkov@parliament.bg, volen.siderov@parliament.bg, ventsislav.lakov@parliament.bg,  vencilakov@abv.bg, tsveta.georgieva@parliament.bg, dimitar.karbov@parliament.bg, b.stoyanov@parliament.bg, valentin.ivanov@parliament.bg, D.Chukolov@parliament.bg, yavor.notev@parliament.bg, kiril.gumnerov@parliament.bg

“Синята коалиция” 6.76%

e.michaylova@parliament.bg, jordan.bakalow@parliament.bg, l.toshev@parliament.bg, kdimitrov@parliament.bg, veselin.metodiev@parliament.bg, tsvetan.kostov@parliament.bg, dimitrovmartin@parliament.bg, dimo.gyaurov@parliament.bg, ivan.n.ivanov@parliament.bg, m.mihaylov@parliament.bg, Agov@parliament.bg, lyubomir.ivanov@parliament.bg, ivan.kostov@parliament.bg, dsb@nt14.parliament.bg

“Ред, законност и справедливост” 4.13%

e.vasilev@parliament.bg, m.tagarinski@parliament.bg, b.petrova@parliament.bg, t.velikov@parliament.bg, georgi.terziyski@parliament.bg, k.petrova@parliament.bg, d.matov@parliament.bg, d.kolev@parliament.bg, yanev@parliament.bg, y.yanev@parliament.bg

За обновяване на адресите

Прост и чуплив скрипт за събиране на адресите:

Първо събери идентификационните номера на депутатите (във файла indices)

curl http://www.parliament.bg/bg/MP | grep ">Информация" | sort | cut -d'"' -f6 | cut -d'/' -f4 | sort -n > indices

След това свали адресите им

# -*- coding: utf-8 -*-
import urllib
import xmltodict
import xml
import re

indices = open('indices').readlines()
dicts = []
force_file = open('force', 'w')
mail_file = open('mail', 'w')

for i in indices:
    xml_str = urllib.urlopen('http://www.parliament.bg/export.php/bg/xml/MP/'+i)
    try:
        r = xmltodict.parse(xml_str)
        force = r['schema']['Profile']['PoliticalForce']['@value']
        mail = r['schema']['Profile']['E-mail']['@value']
        force_file.write(force.encode('UTF-8'))
        force_file.write('\n')
        force_file.flush()
        mail_file.write(mail.encode('UTF-8'))
        mail_file.write('\n')
        mail_file.flush()
    except xml.parsers.expat.ExpatError:
        pass

force_file.close()
mail_file.close()
force_file = open('force', 'r')
mail_file = open('mail', 'r')

forces_list = force_file.readlines()
forces_set = set(forces_list)
mails_list = mail_file.readlines()
mails_dict = dict(zip(mails_list, forces_list))

c = 0
for f in forces_set:
    mails = [k for k, v in mails_dict.items() if v==f]
    string = ', '.join(m.strip() for m in mails)
    string = re.sub(';', ', ', string)
    string = re.sub(':', ', ', string)
    dump = open('dump%d'%c, 'w')
    dump.write(f)
    dump.write('\n')
    dump.write(string)
    dump.close()
    c += 1

The difference is that the scalars of a vector space form an algebraic field while the scalars of a module form a ring. For us humans (as opposed to “those higher beings that I do not understand (a.k.a. mathematicians)”) this means that the scalars in the vector field can divide each other while the scalars in the spaces spanned by fields (i.e. a module) can not.

And just so we all can become even more confused: This has nothing to do with the fact that the “components” of each form field or vector field in certain basis are functions, i.e. themselves elements of a vector space with infinite number of dimensions.

The first way to see this module-not-a-vector-space characteristic is by showing directly that the scalars that form the “coordinate components” of a vector field can not always be divided, even if they are not identically zero. Take, for instance the, manifold with the polar coordinate system and look at the vector . The “scalars” are and . Obviously we can not divide the former by the latter because it will be undefined at .

Another, more amusing way to show that the space spanned by these fields is not a vector space is to explicitly show that a property expected from vector spaces is not fulfilled. Namely, that in dimensions an -uple of linearly independent elements forms a basis. However, in the case of fields over a manifold we can easily have a number of fields that are linearly independent over the manifold as a whole, and are at the same time linearly dependent (or simply equal to zero) on a subdomain. Hence, we have an -uple of linearly independent fields that can not be linearly combined to represent another arbitrary field.

One starts with the most general spherically symmetrical metric and by using Einstein equation deduces the equations that must be fulfilled by the components of the metric (in the chosen basis).

schwarzschild.pdf

I have two favorite ways to define a tensor/tensor field: either as an object with a representation (in the form of a multidimensional array) that transforms in a precise way when one switches from one basis to another, or instead as (sum of) tensor products of some vectors and 1-forms (i.e. an element of some tensor product of the vector space and its dual).

In Terms of Transformation Rules

With regard to the first definition, Wikipedia has this to say:

A tensor of type (n, m−n) is an assignment of a multidimensional array to each basis such that, if we apply the change of basis then the multidimensional array obeys the transformation law .

A tensor field then is a way to map a tensor to each point of a manifold (the tensor is wrt the tangent space at that point).

When we switch from tensors to tensor fields a new object becomes important: the coordinate system. Before proceeding, one must know what a manifold and a tangent space mean. Then we can illuminate the relation between what one calls a “basis” when speaking about tensors and the “coordinate system” in the context of tensor fields. Firstly, a coordinate system gives a way to continuously map a tuple of numbers to a point on the manifold. This continuous map is what physicist love to work with (Cartesian or polar coordinates for instance). The nice thing is that each coordinate system brings with itself a canonical basis for each point of the manifold.

What can be confusing, is that the basis can change from point to point. For example, one can take the manifold that has as its tangent space. Take for instance two points and . The basis vectors in the Cartesian coordinate system are the same for both points: . However in the polar coordinate system the basis vectors for the first point are and for the second point.

Anyway, the only thing that changes in the definition, is that the change-of-basis matrix mentioned above now depends on the coordinate systems.

In Terms of Tensor Products

I prefer this definition, as it relies on the geometrical meaning of vectors and forms. According to Wikipedia, one can express it as:

A type (n, m) tensor T is defined as a map , where V is a vector space and V* is the corresponding dual space of covectors, which is linear in each of its arguments.

One can again try to translate this to the case of tensor fields. The straightforward way is just to say that this map is parametrized, thus it depends on which point on the manifold it is evaluated.

However, a more “geometrical” approach would be to keep the part about “a tensor field is the sum of tensor products of vector fields and 1-form fields” but define vector fields and 1-form fields “geometrically”. Vector fields become differential operators over the manifold instead of maps to elements of the tangent space and 1-forms are defined in terms of differentials instead of duals of vectors.

The Magic

The magic is that this parametrization in terms of tuples of real numbers (a coordinate system) brings automatically a canonical basis and and the transformation matrix for change of basis. Hence defining a coordinate system provides a basis for free. Otherwise the generalization of the first definition would have been clumsier.

Hell, yeah!

Higgs-like particle

When Joe Incandela, the spokeperson for CMS, showed this plot everybody remained silent. He actually forgot to continue his speech for a few moments, sooo happy about being able to show such an insanely cool graph.

Obviously this is a great scientific discovery. Anyhow, it was not a surprise for most physicists, hence I will leave the discussion of the physics out of the way and focus on today’s event itself. (Just to be clear, this is indeed a new particle, however it is not know for sure whether it is the SM Higgs (I will be so happy if it is not (yes, click this link)))

Getting back to the event itself, the atmosphere was indeed great. The conference hall was too small for all the public to fit in, thus, in order to ensure that everybody is happy, CERN had the talks streamed to all meeting rooms on the campus. Regardless, there was a number of enthusiasts that slept in front of the doors to guarantee themselves a place in the main hall. Good for them as it seems that by already 5:30 am there were more than 150 people waiting in front of the hall (the seminar started at 9 o’clock).

After the presentations, the scientists that predicted the particle some 50 years ago were given the opportunity to say a few words. Gerald Guralnik’s comment was very appropriate:

It is wonderful to be at a physics event where there is applause like there is at at football game.

Peter Higgs had tears in his eyes when he said:

It is an incredible thing that it has happened in my lifetime.

In the spirit of these words, we should not forget all the people that were not as lucky and were not able to see the product of their work.

The CERN Director General Rolf Heuer closed the talks by saying:

As a laymen I would now say I think we have it. Do you agree?

And was greeted by ovations from the hall (and all the meeting rooms on campus). This person moderated the talks extremely well.  Indeed, it was a pleasure to watch him and the two collaborations’ spokepeople answering the journalists’ questions during the press conference that followed.

Lastly, a few places to check for more information (there is a number of articles on each blog, so check the prev/next buttons):

• Cosmic Variance
• Quantum Diaries
• Quantum Diaries Survivor
• Backreaction

The notion of “a tensor” is commonly defined in two different ways. The first definition goes roughly like this (“roughly” means “do not tell this to your math teacher”):

A tensor is a geometrical object that can be represented in some coordinate system as an n-dimensional array (it is not the array itself). The quantities in that array depend on the coordinate system in which the representation is done, however there is a precise rule on how these quantities change if we switch to another coordinate system. It is this rule that defines what a tensor (and in particular a vector or a 1-form) is.

The other definition, less used by physicists and more used by mathematicians is (again roughly) the following:

A tensor is the sum of tensor products of forms and vectors. Forms and vectors are themselves given nice geometrical definitions.

It is this second definition that is used in the diffgeom SymPy module. Naturally, we need to define “tensor product”, “vector” and “form” in order to use this definition. Indeed, the structure of the module follows closely these mathematical definitions.

Disclaimer: I have used and will use the words tensor and tensor field interchangeably. In order for this post to make any sense to you, ensure that you understand the difference and are able to find out the exact meaning from the context. The same goes also for vector / vector field and form / form field.

The Implementation

To create the mathematical structure of differential geometry or its implementation in a CAS like SymPy we need to build up the ladder of object definitions. Each new and more interesting notion will depend on the definition of the previous. Hence we start with the boilerplate object “Manifold” and on it we define a “Patch” (the diffgeom module implements all this boilerplate for commonly used manifold, however in order to explain how it works, we will redo everything from scratch):

m = Manifold('my_manifold', 2) # A 2D manifold called 'my_manifold'
p = Patch('my_patch', m) # A patch called 'my_patch'
 

The first object that does something marginally interesting is the “Coordinate System”. Its role is to permit the parametrization of points on the patch by a tuple of numbers:

cs_r = CoordSystem('R', p) # A coordinate system called 'R' (for rectangular)
point = cs_r.point([1,1]) # A point with coordinates (1, 1)

If you have two or more coordinate systems you can tell the computer how to transform a tuple of numbers from one system to another:

cs_p = CoordSystem('P', p)
cs_r.connect_to(cs_p, [x, y], [sqrt(x**2+y**2), atan2(y,x)])
cs_p.connect_to(cs_r, [r, t], [r*cos(t), r*sin(t)], inverse=False)
# Now the point instances know how to transform their coordinate tuples:
point.coords(cs_p)
# output:
#⎡  ___⎤
#⎢╲╱ 2 ⎥
#⎢     ⎥
#⎢  π  ⎥
#⎢  ─  ⎥
#⎣  4  ⎦

However, differential geometry is not about calculating coordinates of points in different systems. It is about working with fields. Thus, we will focus on a single coordinate system from now on, and to be explicit about its complete independence of whether we want rectangular or other coordinates, we will just call it ‘c’ and leave it unconnected to other coordinate systems.

c = CoordSystem('c', p)

Scalar Field

We continue to build up our ladder of definitions in order to obtain a more interesting and useful theory/implementation. The next step is the “scalar field”. A scalar field is a mapping from the manifold (the set of points) to the real numbers (yes, just reals (maybe complex), the rest brings unnecessary complexity). Each coordinate system brings with itself the basic scalar fields (i.e. coordinate functions), that correspond to the mappings from a point to an element of its coordinate tuple. These basic scalar fields are implemented internally as BaseScalarField instances (this is however invisible to the user).

 c.coord_functions()
# output: [c₀, c₁]
point = c.point([a, b])
c.coord_function(0)(point)
# output: a

You can build more complicated fields by using the base scalar fields. This does not produce an instance of some new ScalarField class. The BaseScalarField instances just become a part of the expression tree of an ordinary Expr instance (the base for building expressions in SymPy).

c0, c1 = c.coord_functions()
field = f(c0, 3*c1)/sin(c0)*c1**2
f
# output:
#               -1       2
#f(c₀, 3⋅c₁)⋅sin  (c₀)⋅c₁
field(point)
# output:
# 2
#b ⋅f(a, 3⋅b)
#────────────
#   sin(a)

Vector Field

Then comes the vector field which is defined as an element of the set of differential operators over the scalar fields. All elements of this set can be build up as linear combinations of base vector fields. The base vector fields correspond to the partial derivatives with respect to the base scalar fields. They are implemented in the BaseVectorField class, which also is invisible to the user.

c.base_vectors()
# output: [∂_c_0, ∂_c_1]
e_c0, e_c1 = c.base_vectors()
e_c0(c0)
# output: 1
e_c0(c1)
# output: 0

One can also use more complicated fields (again, no need for new VectorField class, just being part of the expression tree of Expr):

v_field = c1*e_c0 + f(c0)*e_c1
v_field
# output: f(c₀)⋅∂_c_1 + c₁⋅∂_c_0
s_field = g(c0, c1)
v_field(s_field)
# output:
#      ⎛ d            ⎞│           ⎛ d            ⎞│
#f(c₀)⋅⎜───(g(c₀, ξ₂))⎟│      + c₁⋅⎜───(g(ξ₁, c₁))⎟│
#      ⎝dξ₂           ⎠│ξ₂=c₁      ⎝dξ₁           ⎠│ξ₁=c₀
v_field(s_field)(point)
# output:
#  ⎛ d           ⎞│            ⎛ d           ⎞│
#b⋅⎜───(g(ξ₁, b))⎟│     + f(a)⋅⎜───(g(a, ξ₂))⎟│
#  ⎝dξ₁          ⎠│ξ₁=a        ⎝dξ₂          ⎠│ξ₂=b

1-Form Field and Differential

The final ingredient needed for the basis of differential geometry is the 1-form field. A 1-form field is a linear mapping from the set of vector fields to the set of reals. The interesting thing is that all 1-forms can be build-up from linear combinations of the differentials of the base scalar fields.

There is the need to define what a differential is. The differential of the scalar field is the 1-form field which has the following property: for every vector field one has .

In the diffgeom module the differential is implemented as the Differential class. The differentials of the base scalar fields are accessible with the base_oneforms() method, however one can construct the differential of whatever scalar field they wish. There is, as always, no dedicated OneFormField class. Everything is build up with Expr instances.

c.base_oneforms()
# output: [ⅆ c₀, ⅆ c₁]
dc0, dc1 = c.base_oneforms()
dc0(e_c0), dc1(e_c0)
# output: (1, 0)

And building up more complicated expressions:

f_field = g(c0)*dc1 + 2*dc0
f_field(v_field)
# output: g(c₀)⋅f(c₀) + 2⋅c₁

The Rest

Now that we have the basic building blocks in order to construct higher order tensors we use tensor and wedge products. More about them in part 2.

What if I Need to Work with a Number of Different Coordinate Systems

The only difference is that the chain rule of differentiation will be necessary. One can express the same statement in a more implementation independent way as “The rule for transformation of coordinates will need to be applied”. Anyhow, it works:

Examples from the already implemented module.

Points Defined in one Coordinate System and Evaluated in Another

point_r = R2_r.point([x0, y0])
point_p = R2_p.point([r0, theta0])
R2.x(point_r)
# output: x₀
R2.x(point_p)
# output: r₀⋅cos(θ₀)
trigsimp((R2.x**2 + R2.y**2 + g(R2.theta))(point_p))
# output:
#  2
#r₀  + g(θ₀)

Vector Fields Operating on Scalar Fields

R2.e_x(R2.theta)
# output:
#            -1
#   ⎛ 2    2⎞
#-y⋅⎝x  + y ⎠
R2.e_theta(R2.y)
# output: cos(θ)⋅r

1-Form Fields Operating on Vector Fields

R2.dr(R2.e_x)
# output:
#         -1/2
#⎛ 2    2⎞
#⎝x  + y ⎠    ⋅x

What if I Need an Unspecified Arbitrary Coordinate System

If it is just one coordinate system, nothing; all the examples in the first part were for a completely arbitrary system. If you want two systems with an arbitrary transformation rules between them, just use an arbitrary function when you connect them:

m = Manifold('my_manifold', 2)
p = Patch('my_patch', m)
cs_a = CoordSystem('a', p)
cs_b = CoordSystem('b', p)
cs_a.connect_to(cs_b, [x, y], [f(x,y), g(x,y)], inverse=False)
cs_a.base_vector(1)(cs_b.coord_function(0))
# output:
#⎛ d            ⎞│
#⎜───(f(a₀, ξ₁))⎟│
#⎝dξ₁           ⎠│ξ₁=a₁

How Does This Relate to the Scheme Code by Gerald Jay Sussman and Jack Wisdom

The diffgeom module is based in its entirety on the work of Gerald Jay Sussman and Jack Wisdom on “Functional Differential Geometry”. The only substantial difference (in what is already implemented) is how the diffgeom module treats operations on fields. Both the diffgeom module and the original Scheme code behave like this:

scalar_field(point) ---> an expression representing a real number

However, the original scheme implementation and the SymPy module behave differently in these cases:

 vector_field(scalar_field)
form_field(vector_field)
 

As far as I know, the original Scheme code produces an opaque object. It indeed represents a scalar field, however will not produce directly . Instead it produces an object that returns 1 when evaluated at a point. The diffgeom module does this evaluation at the time at which one calls without the need to evaluate at a point, thus the result is explicit and not encapsulated in an opaque object.