we need to pick some names for those. Sage uses:
bessel_J
spherical_bessel_J
scipy uses:
jn
sph_jn
mpmath uses:
besselj
(it doesn't have the spherical one yet)
the XSI extension to math.h
(http://en.wikipedia.org/wiki/Math.h#XSI_Extensions) has
jn
(no spherical one)
mathematica uses:
http://reference.wolfram.com/mathematica/ref/BesselJ.html
http://reference.wolfram.com/mathematica/ref/SphericalBesselJ.html
e.g. BesselJ and SphericalBesselJ
and sympy currently doesn't have them, but I wrote patches for the
spherical_bessel_J, the question is how it should be named.
I like the mathematica version the most, e.g. I think I'll post
patches with creating BesselJ and SphericalBesselJ classes, that would
represent those functions symbolically, and of course one can evaluate
them numerically using .n(). The other option is to create them as
functions, and then I would just translate it (as always in Python) to
bessel_J and spherical_bessel_J, just like in Sage.
What do you think?
Ondrej
I was just thinking about this too. Basically I think we should stick
to Python convention and that's it. Python convention is to use
CamelCase() for classes and lower_case_with_underscores() for
functions. Most of the things are implemented as classes in SymPy,
thus it should just be BesselJ, Heaviside, Gamma, Zeta, etc.
As to trig. functions, currently the classes are called sin, cos, but
it seems to me we should rename them to Sin, Cos and provide
sin = Sin
cos = Cos
for backwards compatibility -- in fact I think lots of people may
prefer to use "sin", not Sin. Just like we have log and
ln = log
There are just a few of the most common functions, where we could
provide both ways, but in general I think we should just stick to
Sin/Cos, BesselJ.
> By the way, once this gets in, I will want to add in a case in dsolve
> that returns it.
Excellent.
Ondrej
In general I really push for this convention. However, when the fact that
it is a class or an instance (or function) is an implementation detail, I
don't know if I would push for this or not.
For instance, let us suppose that we have a mixing of functions and
classes. For instannce BesselJ is a class, and spherial_bessel_j a
function. The mixing of names will be confusing to the user.
So consistency is the most important thing, IMHO. If the class
characteristic is consistent, then the naming should be consistent.
Gael
As pointed out before, a big advantage of this convention is that it
can be made absolutely consistent while avoiding clashes with
Python builtins. So we can have Sum() without shadowing Python's sum(),
Abs() without shadowing abs(), etc.
Fredrik