Optimizing a Math Expression Parser in Rust
rpallas.xyz
Optimizing a Math Expression Parser in Rust
1–10 of 60 posts
Re: Optimizing a Math Expression Parser in Rust
#2This reminds me I should actually write a "natural" arithmetic expression parser for my Rust crate realistic
Right now, realistic can parse "(* (^ 40 0.5) (^ 90 0.5))" and it will tell you that's 60, because yeah, it's sixty, that's how real arithmetic works.
But it would be nice to write "(40^0.5) * (90^0.5)" or similar and have that work instead or as well. The months of work on realistic meant I spent so long without a "natural" parser that I got used to this.
Re: Optimizing a Math Expression Parser in Rust
#3This would be a perfect class project. First lesson is letting them go loose, second lessen would be to find out which optimizations they used and which are available
Re: Optimizing a Math Expression Parser in Rust
#4[dead]
Re: Optimizing a Math Expression Parser in Rust
#5I very much like those optimizations articles , what could be interesting is to look at benchmarks not only wall time but also other metrics :
- cpu time (better CPU usage can mean shorter wall time but higher CPU)
- memory usage
- but also and maybe more interestingly complexity of code (not an absolute metric, but a very complex/non portable code for 5% speedup may or may not be worth it)
EDIT: formatting
Re: Optimizing a Math Expression Parser in Rust
#6I am not even a newbye in Rust and also this could be just nitpicking, but it seems that match is comparing strings and not characters, if this is the case then I think Common Lisp can optimize more, since there is a special comparison for characters in CL.
Edited: In the optimized version the author use bytes and generators and avoid using strings. I don't know if Rust generators are optimized for speed or memory, ideally you could define the length of the buffer according to the memory cache available.
Edited: I find strange using input = read_input_file()? and then using eval(&input), what happens when there is an error reading the file? Rust is supposed to be a high security language. In CL there are keyword like if-does-not-exists to decide what to do and also read accepts additional parameters for end-of-file and for expressing that this read is inside a recursive procedure inside another read.
I should stop comparing Rust to CL, better learn Rust first. I consider this kind of articles a very good way of learning Rust for those interested in parsing and optimizations. Rust seems to be a very nice language when you can afford the time to develop your program.
Re: Optimizing a Math Expression Parser in Rust
#7Can somebody explain this line:
n => Token::Operand(n.parse().unwrap()),
Re: Optimizing a Math Expression Parser in Rust
#8Can somebody explain this line: n => Token::Operand(n.parse().unwrap()), How does the compiler derive the type of n?
[deleted]
Re: Optimizing a Math Expression Parser in Rust
#9Can somebody explain this line: n => Token::Operand(n.parse().unwrap()), How does the compiler derive the type of n?
We're doing a pattern match, so, this variable n has to be something that matches the entire value matched, its type will be identical to the type of the value matched, s a few lines earlier.
That value is an item from the iterator we got from calling split_whitespace() and split_whitespace() returns a SplitWhiteSpace, a custom iterator whose items are themselves sub-strings of the input string with (no surprise) no white space in them. In Rust's terminology these are &str, references to a string slice.
So, the type is &str
Re: Optimizing a Math Expression Parser in Rust
#10I am a bit surprised that the author didn't try to implement a stream parser. This could avoid loading the entire file in memory or relying on OS features like memory-mapped files.