main.rs/tests::test_basic fails at this assertion

        assert_eq!(
            full_eval("5 kilograms + 4 grams").to_string(),
            "5004 g".to_string()
        );

With the following message:

thread 'tests::test_basic' panicked at 'assertion failed: `(left == right)`
  left: `"9000 g"`,
 right: `"5004 g"`', src/main.rs:57:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

X = -10
X*(1) = ?
X/(1) = ?
(X+1)/(1) = ?
(X-1)/(1) = ?
-X = ?

gives

X*(1) = -10   // yes
X/(1) = 10    // no...
(X+1)/(1) = -9  // yes!
(X-1)/(1) = 11  // no...
-X = ?    // Invalid statement -X = ?

I like CalcuLatex, but CalcuLatex doesn't like negative variables... :-)

Right now the number and integer parsing rules allow for a '-' at the start so parse::<f64> just parses it in but this makes it weird to work with negating variables etc.

Hi, I've been hit by this weird bug. Smallest example I managed to make is this below.

Input:

k = -8
p = 8

lo = 0 + k*p  = ?
hi = 0 - k*p  = ?

k = -8
p = 10

lo = 0 + k*p  = ?
hi = 0 - k*p  = ?

Output:

k=−8 p=8

lo=0+k×p=64 % note: wrong, should be -64 hi=0−k×p=−64 % note: wrong, should be +64

k=−8 p=10

lo=0+k×p=−80 % note: correct hi=0−k×p=80 % note: correct

Thanks for this interesting work. I'm curious about how you render the math. Do you use some external library like pandoc? Or it's implement in the code?

Overview

Added a bunch of simple tests for Unit structs. A lot of them are pretty trivial, but I thought the obvious stuff should be covered. If these changes are accepted, you'll have to make sure they pass when you change Unit in the future.

Blocking issues

There was some unexpected behavior when dividing- you get empty output (unit.to_string() = "") for dividing meters^4 by meters^2, which should give "m^2" as the output unless I'm missing something. You get the same output when dividing two identical Unit instances, but that seems acceptable for identical numerator and denominator.

I left example tests (w/ commented assertions) for both of those cases. If you clarify what's intended and/or fix the behavior, I'll add tests for those cases as well.

UNIT_PREFIXES previously used a power of 21 for the "yotta" prefix; this PR changes it to the correct value of 24. No test failures were introduced, which makes me think that a test for this should be added, but I don't have the time to do it right now.

The issue can be revealed by typing 1 yottawatt / (1 exawatt) into the CalcuLaTeX demo website, which yields 1000 instead of the expected 1000000. Incidentally, I tried to test this with 1 yottawatt / (1 zettawatt) but was met with an error message, which probably also warrants investigation.

Hi Mikhail, thanks for fixing that weird sign bug! Now I calculated some more and stumbled across another issue:

4^0.5 = ?
0.25^0.5 = ?

Output is:

4^0.500=2 % correct

0.250^{0.500} = 1.581 % incorrect, should be sqrt(1/4) = 1/2 = 0.5

CalcuLaTeX supports declaring a variable using latex syntax, e.g. m_0 and \frac{x}{y} are valid variable names and will be rendered properly, but they're annoying to type. It should be possible to alias a variable to LaTeX.

This is probably related to #2 since I'd imagine we use a separate statement to set a variable's display LaTeX

Would it be possible to add to the README (or elsewhere) information about how to compile and run this program for those who aren't familiar, and what libraries / tools are required to do so? Thank you!

According to standards, units must be typeset in upright font. Consider typesetting units using \mathrm{} or even better, siunitx package if possible.

See for example SI Brochure:

Unit symbols are written using roman (upright) type, regardless of the type used in the surrounding text

CalcuLaTeX has potential, but it's held back by messy code and a badly designed arbitrary precision unit math system.

Arbitrary precision unit math is a pain. There are a number of libraries for it in Rust, but many of them are either made for type safe compile-time usecases, or are text based calculators.

An obvious solution is to use one of these text based calculators with a custom parser and then compile the result to LaTeX. However, an easier and less efficient solution is to use the language as an IR.

For example, with fend, we could compile CalcuLaTeX input to fend input, run fend, and then re-parse fend output and display it with LaTeX. It would probably be easier to intercept a FendResult on the output end and compile it to LaTeX. However, on the input side I believe it would be a lot easier to generate a fend input string than to actually create a Fend IR.

Using this method, a lot of CalcuLaTeX's general design might stay the same. Right now, input expressions (left side of the = ?), are basically directly translated to LaTeX, and that won't change.

Right now it's very messy. One thing which might be nice is adding comments which are just the corresponding CalcuLaTeX line that produces the LaTeX line

This is super long term since CalcuLaTeX doesn't even support booleans yet, but I wanted to write out a general plan.

Basically, user defined functions need to have an option to inline themselves in the LaTeX. We also need LaTeX string interpolation to work. This way, truth tables can be implemented as just syntax sugar and just expand to a table.