Tried a very simple example in integration test:
assert!(rsc::eval("5^2").unwrap() == 25.0);

Got a compile error:

>cargo test
   Compiling rsc v1.2.0
error[E0554]: #![feature] may not be used on the stable release channel
  --> C:\Users\Youka\.cargo\registry\src\github.com-1ecc6299db9ec823\rsc-1.2.0\src/lib.rs:55:1
   |
55 | #![feature(test)]
   | ^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
error: Could not compile `rsc`.

Seems this crate depends on standard benchmarking which is still not stable. Missing the note about this restriction in crate description.

Hello,
After structuring the code using your library and trying it out, I encountered an error.

For example,
When I input 'asd100/5', it correctly tokenizes into 'asd,,100,/,5', and the calculation works fine.

However, as in the title, the tokens for variable names seem to be incorrect in the following case:
'aaa325azxv1000' -> 'aaa,325,azxv,,1000'

I think modifying only the following part of the tokenize function would fix it.

match c {
            '+' => tokens.push(Token::Operator(Plus)),
            '-' => tokens.push(Token::Operator(Minus)),
            '*' => tokens.push(Token::Operator(Star)),
            '/' => tokens.push(Token::Operator(Slash)),
            '%' => tokens.push(Token::Operator(Percent)),
            '^' => tokens.push(Token::Operator(Caret)),
            '(' => tokens.push(Token::Operator(LParen)),
            ')' => tokens.push(Token::Operator(RParen)),
            '|' => tokens.push(Token::Operator(Pipe)),
            '=' => tokens.push(Token::Operator(Equals)),
            '!' => tokens.push(Token::Operator(Factorial)),
            c => {
                if c.is_whitespace() {
                    continue;
                } else if c.is_digit(10) || c == '.' {
                    let mut number_string = c.to_string(); // Like creating a new string and pushing the character.

                    while let Some(&c) = chars.peek() {
                        if c.is_digit(10) || c == '.' {
                            number_string.push(chars.next().unwrap());
                        } else {
                            break;
                        }
                    }

                    match number_string.parse::<T>() {
                        Ok(num) => tokens.push(Token::Number(num)),
                        _ => return Err(LexerError::InvalidNumber(number_string)),
                    }
                } else if c.is_alphabetic() {
                    let mut full_identifier = c.to_string();

                    while let Some(&c) = chars.peek() {
                        if c.is_alphabetic() || c == '_' {
                            full_identifier.push(chars.next().unwrap());
                        } else {
                            break;
                        }
                    }

                    tokens.push(Token::Identifier((if case_sensitive { full_identifier } else { full_identifier.to_lowercase() }).to_owned()));
                } else {
                    return Err(LexerError::InvalidCharacter(c));
                }
            }
        }

How do I make it thread-safe? I want to use a Computer across threads using std::sync::Arc, but the error says missing lifetime specifier. If I write 'static, it says help: the trait 'std::marker::Sync' is not implemented for 'dyn std::ops::Fn(f64) -> f64 + 'static)'

Hi I noticed that you added initial support for boolean operators in this commit: 2b1ed6a

It appears that in your version 3 rewrite this support was lost. Do you have plans to add support for boolean operations or did you find some blockers in the way the code is correctly structured? What would be the blockers in adding boolean operators into version 3?

Many thanks for a great library.

Since functions having a syntax like func var1 (var2) poses two problems:

1. How do we know var1 isn't a function, since it has parenthesis around var2; presumably a variable since it has no potential arguments, and then, assuming var1 is the function, that must mean func is too since it has an argument. But we were only multiplying var1 by var2! We need to find a way to determine this.
2. This determination needs to be done at computation time, therefore we have to export some information from the interpreter to the computer for it to determine what is a function call and what is not.

We could potentially solve this by having the parser export potential discrepencies (identifier followed by parenthetical expressions) as FunctionOrVariable with its variable name and expression tree, which the computer can possibly index the variables and functions maps to see if there is a function that matches, or if there is a variable, and select one of the two, probably preferring functions.

Since as of posting this issue, computation time only accounts for about 500 ns of time out of the 7.5 microseconds of time the entire evaluation takes, implementing this in the computer should not be such a bad idea, or add much delay.

Expressions like 2 * 5% would translate to 2 * (5/100). Percentages can only be appended to factors and just divides them by 100.

Hi @fivemoreminix (Luke)

I am going to publish typenum-consts, which consists of 4 procedural macros that converts a literal integer to type-level integers provided by the typenum crate.

Within it, I allow for evaluation of simple mathematical expressions, like so:

use typenum_consts::uconst;
use typenum::{U15, assert_type_eq);

type A = uconst![{
    a = 5;
    b = 10;
    a + b; // a + b = 5 + 10 = 15 => `A` is `U15`
}];
assert_type_eq!(U15, A);

I used your crate rsc as the evaluator. Thank you for building this.

I vendored your crate because you didn't put it on crates.io and I needed your crate to support implementing Num for isize.

Thank you.

If I do log2(18000) it results in 5418.54 instead of 14.13 like rustlang f32::log2() or a scientific calculator