Updated: April 5, 2019
Education and science go hand in hand with Linux. The academy likes open-source in general, and there's a pretty good chance you'll find Linux software in research laboratories worldwide. So if you happen to dabble in sophisticated mathematics tools, you might as well dabble in Linux. Alas, most desktop environments don't have their own edu-sci applications. Well, KDE does.
Cantor is a multi-purpose scientific analysis tool, with support for multiple backends. You can use the program to run Python, R, Octave, Scilab, KAlgebra, Qalculate, Maxima, and other engines. This makes it useful as a single interface for all your mathematics needs. And I like the unique angle. But does it work? Let's find out.
Installation & configuration
This was rather non-trivial. I installed Cantor, and then launched it, and it only had Qalculate in the list. I played with the settings, trying to find a way to add other programs. I had Octave and Scilab in mind, to start with, but there didn't seem to be an integral way to include them. Trying to make progress, I did install Octave manually, but this didn't change a thing.
After some fiddling, I finally realized that the functionality is actually provided by additional backends, which you need to install - much like any other software package. Once I had these on the system, the other programs did show in the Cantor's interface.
apt-cache search cantor
analitza-common - common files for Analitza
cantor - interface for mathematical applications
cantor-backend-julia - Julia backend for Cantor
cantor-backend-kalgebra - KAlgebra backend for Cantor
cantor-backend-lua - Lua backend for Cantor
cantor-backend-maxima - Maxima backend for Cantor
cantor-backend-octave - Octave backend for Cantor
cantor-backend-python - Python backend for Cantor -- transitional package
cantor-backend-python2 - Python2 backend for Cantor
cantor-backend-python3 - Python3 backend for Cantor
cantor-backend-qalculate - Qalculate! backend for Cantor
cantor-backend-r - R backend for Cantor
cantor-backend-sage - Sage backend for Cantor
cantor-dev - interface for mathematical applications - development files
fasttree - phylogenetic trees from alignments of nucleotide or protein sequences
libanalitza-dev - development files for Analitza
libcantor-pythonbackend - Base Python backend for Cantor
But even now, there was a discrepancy - now all of them were shown. Another less known fact; Cantor will display only those that actually have some sort of interface. Indeed, you can verify this through the settings, where the remaining math engines were showing up. 'Tis all a bit confusing, and it could be made easier and simpler. Like a button that says "Add more engines" or whatnot.
Eventually, I had Octave running. I've reviewed this excellent program quite a few times before. It's also almost identical to Matlab, which makes it extremely useful - and makes most sense to my physics-wired brain. Working with matrices is the way it should be done.
I did struggle a little in the beginning. Being slightly rusty with Octave, it took me a little bit of time remembering some of the details, most notably how to install and import packages. I wanted to create several fancy 3D shapes (like Torus), but this is part of the geometry package, which you need to install separately.
Cantor lets you import packages, but strangely - not install them, for some reason:
In the end, I was making progress, but then Octave, on its own, seemed to be doing a better job.
And the same thing plotted through Octave (natively):
Plotting and scheming
I started making graphs of all sorts, to see how practical Cantor is. I didn't reuse my old code for this. Instead, I used free Bessel rings examples from Matlab and Octave help pages. I did this in Octave and Cantor side by side, to see the differences in speed, syntax and quality of created figures.
Overall, the figures and images were much nicer in Octave. One, faster and smoother rendering. Two, images auto-resize, and you don't lose any quality. Three, the system was rather quiet when doing all this, and the results were near-instantaneous. In Cantor, the same actions resulted in huge memory footprint, my CPU fans were shrieking like crazy, and the final figures were all scrunched. I was able to zoom in, but then they looked all fuzzy and blurred.
Another issue is that by default, Cantor inlines images, so they are created in the workspace area. This looks quite bad, and you need to scroll horizontally to find your images - if you realize this is what you need to do in the first place. Jittery behavior, on top of that. I did change the settings to pop the figures out, and this did help a little bit, but I wasn't able to resize them. The figures would just freeze and become non-responsive, and I had to kill Cantor a few times. Meanwhile, the CPU fans would scream and the memory footprint would soar, and even with 16 GB of RAM on my Slimbook, I hit the swap space, w00t!
I was able to use colormaps just fine - so if Octave supports it, Cantor will support it, and I guess the same logic extends to all other backends. This means you don't need to doubt whatever Cantor is doing, you just need to make sure you have the right packages installed.
If you want to have pop-out plots, you can change them through Settings:
Cantor does give you detailed menu options. You can import packages, create 2D and 3D plots, show relevant backend help, and more. Quite useful in this regard, and the guided wizards can be helpful to people who are not too familiar with the syntax. This is doubly useful if you work with multiple backends, so you only need to know what you want to get, and Cantor will handle the translation. Cushty.
Now, in addition to the many usability issues when running Cantor, there are also some aesthetic ones. For example, the main interface feels wrong. It's completely empty save for a few buttons, so I wonder what the original design was, and why it wasn't implemented. Now, you get the backend prompt, and then the tool switches to the relevant engine, so the main interface isn't really necessary.
There were a few niggles here and there, and maybe one or two commands didn't really work in Cantor, compared to Octave. Overall, the interface was also much slower, and it was a pain getting the workspace terminal or whatever it's called to respond. And copy & paste functionality is quite weird. If you grab Matlab code from the web and paste it in Octave, there's almost 100% chance it will be shown line by line and work well. If you copy code from Cantor, the newline characters will be mangled, so it will all be displayed as a single line, and Octave would not really be able to validate it.
It's a song, but it needs refinement. Cantor seems like a clever piece of software, but it lacks refinement and sophistication to match its own goals. I did only test Octave, but I think my findings are pretty indicative. After all, if there were issues with one backend, whatever they are, they need to be fixed. And these weren't trivial issues, either. Slow performance, memory and CPU noise, frozen interface, bad-looking figures.
The configuration also needs to be improved. All in all, it's very difficult doing what Cantor tries, so the idea is really cool. But it seems to be a complex task, and at the moment, it brings more woes than benefits. I'd like to see a smoother integration, and a clever wizard that lets you add backends. Maybe a smart clipboard to share code with other programs. I'd expect a fully HW-accelerated graphics module, so everything responds fast and looks peachy. Finally, Cantor mustn't work any worse than the native engines it represents, because it invalidates its own purpose by doing that (or rather not doing that, hi hi). At the moment, it's a raw product, and it needs a lot of fixes. But me likey, so I will be testing in the future. Unique software, here I go.