One of the subjects which I had written about only yesterday, is that the Computer Algebra / Numerical Tool System called ‘SageMath‘ was available in the repositories, for Debian / Stretch – which is in itself news – and that additionally, the default way to use it under Debian is through a Web-interface called ‘SageNB’. Well what I’ve now learned is that the SageMath developers no longer support SageNB, and are continuing their work with the graphical front-end called ‘Jupyter‘.
But, installing Jupyter under Debian is a bit of a chore, because unlike how it is with custom-compiles, Debian package maintainers tend to break major software down into little bits and pieces. At one point, I had Jupyter running, but with no awareness of the existence of SageMath. What finally did the trick for me today, was to install the following packages:
Needless to say, that last package out of the three is the most important, and may even pull in enough of the other packages, to be selected by itself. It’s just that I did not know immediately, to install that last package.
So this is what SageMath 7.4 looks like, through Jupyter:
(Corrected 09/18/2018, 3h50 … )
(Updated 09/18/2018, 5h40 … )
(As of 09/16/2018, 20h10 : )
Frankly, I was a bit disappointed at first. My main disappointment seemed to be with the fact, that this GUI did not offer to typeset the Math. It does allow us to ‘download’ our Notebooks as PDF-Files, but when we do, we simply get the same, highlighted text, and graphics, only as a PDF – in code – or with whatever appearance the browser-view is already showing us. Also, the support for 3D plots is lackluster, as the plot above is non-interactive. At least with SageNB, I was able to select the ‘canvas3d’ viewer, which allowed the plot to be rotated. Also, if we use SageMath from the command-line, it defaults to using ‘JMol’ as its viewer, which is full-featured.
But as it turns out, I have discovered ‘the trick’, to getting Jupyter to typeset the users’ Math…
For each cell, we can decide whether it’s to be a Code cell or a Markdown cell (or something else, a ‘Raw NBConvert cell’, the purpose of which I do not know). What took me some time to learn is that the markdown language of the markdown cells, is just a little more powerful, than mere HTML would be – although we can use that, to format our comments.
If we choose to put a markdown cell, one thing we can do is to place Mathematical
pseudo-notation – i.e., the same sort of syntax that programs such as Sage or Maxima use – between single dollar-signs, and Jupyter will typeset that Math for us !
In other words, we can copy Code which has been output, create a Markdown cell, and then type in a dollar sign, paste the code we just copied, type another dollar sign, and hit <Shift>+<Enter> . Voila! We just need to make sure that we do not have any spaces on the inside of the single dollar-signs.
So now I feel much better, for having installed Jupyter.
(Erratum 09/18/2018, 3h50 : )
Actually, It seems that I was just mistaken, in thinking that I had put SageMath syntax between the dollar-signs, to obtain typeset Math. The rules for typesetting with single dollar-signs are the same as below: They are LaTeX rules. I could easily have kept LaTeX -code on my clipboard, and re-pasted that.
And so an alternative which users of Jupyter Notebook have, is to allow SageMath to generate the LaTeX code for any given object it has defined – SageMath has a function for that. And then, Debian users can copy and paste LaTeX between doubled dollar signs as easily (‘$$’), so that again we get a typeset, Comment / Markdown cell. I have updated the screen-shot above to reflect this situation.
For exporting the Notebook to some other format – let’s say, in order to publish it – an indispensable tool eventually comes to Debian users, in the form of the package:
At first glance it might seem, that I used the incorrect delimiters for the copied and pasted LaTeX in the screen-shot above, because the symbols ‘\left[‘ and ‘\right]’ are not being rendered correctly. The real reason for this artifact appears to be, that the version of MathJax installed on my own computer, is unable to stretch the fonts for those two symbols, when I’m using doubled dollar-sign delimiters ! The same LaTeX symbols render intact, but not stretched, when I use single dollar signs as delimiters.
I can finally recognize that the syntax is correct either way, because I can use ‘nbconvert’ to export to ‘LaTeX’, to ‘HTML’, and to ‘PDF’, without creating an error-code of any kind. The only special significance of the single dollar-signs seems to be that when flowed with text as part of HTML, they toggle back and forth between text and Math mode.
But, if I export the Notebook above directly to PDF, then one side-effect is that all the equations are single-line equations, so that some of them crawl off the right-hand side of the page. So, to be able to export to ‘LaTeX’ is most-useful, because I can then edit the actual .TEX-File, and subsequently, obtain a PDF-File, which is presentable:
(Update 09/18/2018, 5h40 : )
I suppose that at some point, the user might want to be able to format longer, typeset LaTeX equations, to fit on more than one line, but without having to edit an actual .TEX-File, since that last component would involve yet another syntax to learn. And I think I’ve found a way to do it just with SageMath 7.4 and co-packaged Jupyter.
When copying and pasting the LaTeX code for the SageMath object / symbol, it can be interspersed with single dollar-sign delimiters, as long as each beginning delimiter has no space to the right of it, and as long as each terminating delimiter has no space to the left of it. At the same time, no single delimiter-characters should be joined with LaTeX code on both sides.
Each pair of delimiters will define a line of text, effectively, and the lines of text can be made recognizable to ‘nbconvert’, with <br> HTML-tags, each of which have a space on both sides, between the <br> tag in question and its neighboring ‘$’ delimiters.
This results in somewhat unreadable Markdown, because it also forbids following any one <br> tag directly with a newline character. To put a newline character, would also place the following (beginning) delimiter at the very beginning of its own line of text, which would cause it to join with the <br> tag at the end of the previous line of text.
Further, the LaTeX ‘\left[‘ and ‘\right]’ tags must be replaced with ordinary square brackets, because to have either of the original tags on one line by itself, will indicate to LaTeX immediately, that their pairing has gone awry. But ironically, LaTeX doesn’t complain about plain ‘[‘ and ‘]’ characters not being paired on one line.
What the reader should also know, is that when ‘nbconvert’ generates an HTML-File, the resulting file is a stand-alone file, that contains image-data as base-64 -encoded. What I’m used to myself, is that so-called embedded images always existed as URLs, pointing to separate files on the Web-server. But above, the images are actually embedded base-64 blobs, that stand for binary data.
- If the Web-browser is not up-to-date, it won’t know what to do.
- Some anti-virus software may complain, precisely because in a case like this, determining whether the binary contains viruses becomes difficult.