On 2018-03-03, Eric Gourgoulhon <egourg...@gmail.com
> To cope with standard mathematical notations, these operators are
> introduced as functions in the global namespace, which merely invoke the
> corresponding method of their argument, e.g. if v is a vector field,
> sage: div(v)
What's wrong with v.div(), to cope with standard notation in SageMath?
"div", as a notation for "divergence", could also easily be mistaken
with "division", "divisor", or also "dividend" (IIRC, there *is* some
mathematical finance in SageMath).
Also one should be aware that "standard mathematical notation" is
usually strongly dependent on context. Here is a little anecdote: In
some test, I gave my students the little problem "What is the definition
of the order of a group element?". Surprisingly many of them gave the
definition of an order relation. So, in the next homework, I asked them
to do a little research and find as many different mathematical notions
that are named "order". I think they found more than 10.
Conclusion: Functions in the global name space lack context, and are thus
often unsuited for mathematical notations.
And even if you absolutely want to put divergence into the global name
space (which already is too much bloated, IMHO), then I think it would
still be a bad idea to put an *abbreviated* function name into the global
name space ("div" instead of "divergence") just because in *some* branch
of mathematics that abbreviation is standard.
> Is it OK to introduce five new names in the global namespace:
> grad, div, curl, laplacian, dalembertian
> and possibly a sixth one: rot as an alias of curl?
> An alternative (disapproved by the reviewer) is to inject these names in
> the global namespace only if any pseudo-Riemannian manifold is constructed,
Again, what is wrong with the Python standard notation v.div(), where v
is a vector field? Since v.div is a method of a vector field, it
automatically adds the context that were missing if div() was a global