Plasmapy: Physics symbols

[lemmatum]

Copy of SpectroscoPy 19

Include a dictionary of common physics symbols. This includes Greek letters, and other symbols, such as Angstrom.

There is currently no easy way to print these symbols (in contrast to rendering LaTeX equations via matplotlib). Yet, they are all accessible by Unicode, so just need to collect them into a dictionary and associate them with LaTeX-like keys (e.g., 'alpha' and 'Alpha' for lower case and upper case alpha respectively)

@StanczakDominik mentioned SymPy being potentially useful here.

[namurphy]

I've been thinking about a related accessibility issue regarding how we can make the equations that we have in our documentation screen-reader (text-to-speech) compatible. That would make PlasmaPy more accessible to blind, visually impaired, and dyslexic students and scientists. LaTeX formatting is really not useful for screen readers since it focuses on the layout but does not include information on what the different symbols mean. Something like $x^2$ leaves potential ambiguity because the 2 could refer to an exponent, a label, or a tensor index.

There are other specifications like MathML that also try to encode the _meaning_ of mathematical constructs as well as the layout. I've also been wanting to learn more about MathJax which seems to be undergoing really active development. I should really create an issue on this, but thought it would be good to put this on our radar for this issue too.

In any case, this would be a really useful capability. Thank you for bringing it up!

Cross-reference: #174 (since we need symbols for particles as well)

[lemmatum]

@namurphy would you then replace the LaTeX equations we have in the docstrings for each function with some alternative that is more text-to-speech compatible?
Is there any such standard currently being used in the scientific Python community?

If not, we may have to develop such functionality on our own.

[StanczakDominik]

This seems like a lofty, grandiose and worthy goal. However, while I'm all for adding on reasonable features, I fear that if we branch out too much, the core of the package will suffer from neglect.

[lemmatum]

Alright so ignoring tangents...
@StanczakDominik mentioned that sympy is one way of handling these symbols.
Another way is to use a dictionary, which is what I've done in my own private code.

Thoughts on pros and cons?

[StanczakDominik]

Pros for dictionaries:

• light
• simple, does what it's supposed to

Cons for dictionaries:

• could be difficult to extend
• probably need to write a good bunch of code from scratch (@lemmatum you said you already have some)

Pros for SymPy:

• likely does most of what we already need out of the box
• really extensible, we can do whatever the want once we get a base of symbols

Cons for SymPy:

• an additional dependency (but one already supplied with Anaconda and generally popular)
• relatively heavy

[lemmatum]

So my dictionary that I linked in the previous comment already has lowercase and uppercase Greek symbols. We could add miscellaneous symbols like Angstrom and hbar, which probably wouldn't be too much work.
One thing to be mindful of is handling superscripts and subscripts. I haven't figured out how to do this nicely via dictionaries and I think sympy may be better in this case.

[StanczakDominik]

Yeah, sympy can do those out of the box

[namurphy]

If we put in analytical tools later on (which I'm hoping we eventually will), then we'll probably end up putting SymPy in as a dependency independent of this issue.

[lemmatum]

Then my vote goes for sympy

[apooravc]

@lemmatum @StanczakDominik Starting work on this issue. Please correct me if I'm wrong - I've to implement (mostly using Sympy):

• Greek letters both lowercase & uppercase

• other Physics symbols

• their superscripts & subscripts as well

But where should I start changing the code for symbols? Like a particular file or all files?

[hzxusx]

It might not be necessary to use SymPy. In Jupyter/IPython notebook, special printing can be done by implementing _repr_latex_ method as mentioned here.

For example, in my Jupyter notebook

In [1]:
  class TexStr(object):
      def __init__(self, string):
          self.string = string
      def _repr_latex_(self):
          return f"${self.string}$"
In [2]:
  TexStr(r"\alpha")
Out[2]:
  α # rendered by Mathjax in my browser

For me, a Latex/MathJax style output is already great. But a potential solution to @namurphy 's worries is using SymPy's srepr method, which generates executable code, gives more information on its computational process than only layout, and is generated automatically.

I'm personally concerned about MathML's future development. Chrome once implemented it in version 24, but soon dropped its support in the next version. Some discussion on this subject: 1 2

[lemmatum]

@apooravc As far as applications, I'm not sure that we are using symbols within python code at the moment, though we may in the future (for printing physics warnings/exceptions, for example). So I would first look through the exceptions we raise and see if any of the notation can be replaced by symbols in a clear/sensible way.

On the notebook front, @hzxusx raises a good point; the LaTeX renderer is already pretty good there.