akkuankka/matheriser

An algebraic calculator written in rust

matheriser

Evaluates maths expressions of increasing complexity

Features

• Algebraically handles rational numbers, surds, and irrational constants like pi
• Avoids using floating point numbers as much as possible, because they're inherently imprecise
• Currently only a terminal interface, with scope for a GUI later down the line

Installing

If you can install Debian packages on your system, grab the deb package from Releases, and install it with sudo dpkg -i matheriser-VERSION-ARCHITECTURE.deb Or you can use a graphical deb client like Eddy.

Otherwise, the way to get a matheriser is to build it from source by cloning the github repository

Building

You need a rust installation to build it, so if you don't have one (If you don't know what that is then you don't have one), follow the directions here

Linux, Mac, WSL (BSD?)

In a terminal, go to a directory you don't mind a mess, and git clone this repository like so:

$ git clone https://github.com/akkuankka/matheriser 

Then, depending on your OS, run the appropriate install script like so:

$ install-linux.sh # on Linux
$ install-mac.sh # on Mac

If you get an error saying "file install-[whatever].sh is not executable by this user", you can run

$ chmod +x ./*.sh

which will make all of the install scripts executable.

Windows

If you don't have git for windows you can get it here. Then open up a CMD window, a Powershell window, or a Git Bash window (Comes with git for windows), or Windows Terminal if you have it, type the command

git clone https://github.com/akkuankka/matheriser

Open wherever you were in the command prompt in File Explorer and copy the assets folder. Press WindowsKey + R, and in the box that comes up enter %appdata%, then press enter, this should bring up a folder, From there, go into the folder Local and then create a folder matheriser, then paste the assets folder you copied earlier there.

You should now be able to run matheriser from a terminal by typing in matheriser at the command prompt

Where to next:

• Make a package
• A TUI frontend
• A GUI frontend (not electron so currently it's looking like Druid?)
• LINEAR ALGE BRUH
• *** Learn how linear algebra works *** -> Profit???

matheriser's Issues

Trig functions and logarithms

It goes without saying that trig functions will allow us to make good use of all the rational and radical support, so it would be a waste to just go

fn sin(self) -> Self {
  Self::float(f64::from(self).sin())
}

However calculation of trig functions is really nontrivial, so I think it will be basically a matter of hardcoding some places on the unit-circle and a modulus by 2pi, and then running floats otherwise.

Also without them and logs the calculator feels incomplete

Cargo install doesn't do localisation install for you

Because localisation files are not hard-coded into the binary with includestr!() or such, with the binary installed you can call matheriser from any old where which is fine and good but it does mean that the localisation files are going to have to end up somewhere globally accessible & sensible.

It makes sense that these files should go in ~/.local/share/matheriser ( possibly /.cargo/matheriser, more on that later ), but getting them there for the user is somewhat of a deal.

There could be a post_install.sh that copies the language files into whatever directory it ends up being, but this assumes that the end user has a functioning bash (i.e. not Windows users probably). Because of this, and because its an extra step, and because its a random shell script which we expect users to just go with, and because using things that aren't rust don't seem particularly rusty I'd rather have a way of packing up the assets.

There is a an rfc on cargo install that would allow for an install.rs file that specifies where asset files, manpages, etc etc go. It was postponed in March of this year, for reasons that seem to amount to 'it wasn't really being worked-upon' or something like that, I don't really know how the Rust RFC system works, but I could learn if it became a priority to not use a shell script.
If someone else gets that RFC back off the ground we should definitely use that.

Errors Parsing Symbols to a power

(:pi)^2 is fine but :pi^2 is an error (and :pi ^ 2 is fine)
This suggests its probably an error with tokenisation

The pass-by-value catastrophe

Currently everything in the computation side of the code (i.e. not the lexer) is pass-by value (i.e. fn foo(self)). I think this is mostly OK, because stuff doesn't need to be used once it's combined into another value e.g. let c = a + b once that's been done it really doesn't matter what a is, it can go out of scope, but for things like DivisibleBy where you are just gaining some knowledge about a number and then using that to decide what to do with the number, pass-by-reference (i.e. fn foo(&self)) should be used.

The great result-ification

More things should return Result where currently unwrap_or() is being used.

Display produces some less-than-ideal output

For example:
matherise> 3*:pi outputs (3)^1pi, when really it should output 3π.
This is somewhat peculiar because matherise> :pi outputs π.
Some of this is due to the limitations of the terminal as a medium: roots and fractions can't be rendered properly, so there will inevitably be more brackets than there would be if someone had typed it out in LaTeX.

The fix to this should at the very least:

1. display x instead of x^1, (x), (x)^1 or whatever else,
2. properly display Greek letters.

Roots of symbols come out negative

:pi^(1/2) >=> -\sqrt{\pi}
This is probably due to the should_flip logic in roots.rs

A better prompt

Currently, the prompt just reads from stdin verbatim, which is bad for various reasons, among them:

1. Security issues maybe
2. No cursor
3. Arrow keys are useless

The last two in particular are basically the main reason it is so unergonomic currently.

A fix to this would probably involve: grabbing the terminal into raw mode, calculating where the cursor should be within the string being put-in, inserting text there. I don't like this because it feels like a baby TUI. Maybe there are libraries that do this for you.

std::ops::Add implementation is sort of bad

With the insight that

1. Add is used to do subtraction as well.
2. Add can cause Symbols to turn into Symbolics
3. Add can cause Symbolics to turn into Symbols or their constant terms.
   The current implementation of Add is
   a) Inefficient
   b) likely to result in illformed data.