We concluded that RPN was not coming to SC anyway, so the latter might be a workable solution. It is on this matter that I mentioned that RPN would still not work. Hadrien suggested that a (reduced) token should carry along original tokens it is made of.
A tree contains all the information about the original input. This represents quite a task, but will (probably?) solve the issues above.
I suggested rewriting the parser so that it generates a parse tree rather than opcodes. (I had to hackishly include some strings into opcodes to make unit conversion work at all.) The opcodes do not carry any information about the string anymore, so they are useless in that regard. However, currently the compiler just produces opcodes (which are essentially RPN). This can only be done after the compiler has done its job. RPN for instance will totally wreck it as well.Ī more reliable way would actually consult the semantics of the expression. new operators) that will break this scheme. Also I can imagine additions to the grammar (e.g. Currently we only rely on the tokenized input, which is unsatisfactory, as it traverses the tokens twice (once for finding the string, and then once more when actually evaluating the expression), and applies precedence rules each time. For instance in (a+b -> c*d) * e we'd want to get c*d. This is useful for the conversion operation, as here we need to extract the right hand side of the -> operator. In particular the parser should also be able to produce a string (substring of the user input) that corresponds to the subexpression that is currently being evaluated. Such a tree based parser would also enable branched flows (think of the ternary operator ? : in C++), recursive user functions, pretty printing. This way, when a conversion operation is evaluated, the corresponding sub-tree would contain all the information of the unit, including the necessary string (either stored from the scanning step, or constructed on the fly from the nodes). For the evaluation we would just call an eval method of the root node, it would then recursively evaluate its children. It would be very nice if the compiler would instead generate a parse tree (either abstract or concrete). Think autocompleter, or the unit parsing you mention. There are quite a few places that would benefit from being able to query the semantics of the expression. The parser could indeed do with some improvements just compiling the tokens into opcode is fairly limited. You can just install it using your distributions regular method.While the units update was still in the works, we had a discussion on this over on Hadrien's repo. And the more advanced features are there the few times you do need them.Īll the Linux distributions have SpeedCrunch in their repositories. It really isn't all the scientist-specific features that make SpeedCrunch such a nice calculator, it's simply very efficient to use for all purposes. It probably is a great calculator for those use-cases. SpeedCrunch advertises itself as a calculator for rocket scientists. How these are placed and configured is remembered when you close it so you get an identical layout the next time you open it. 
These items can be detached into their own separate utility windows. You are not limited to Pi and the Golden Ratio and a few more like you are in KDE's KCalc.įormulas, functions and constants are placed in an area on the right of the calculation terminal window. There's a vast amount of formulas and more than 150 built-in constants. It can be configured to only show the terminal window and it can be configured to show a keypad, constants, functions, variables and a formula book. It displays a "Current results" above the numbers you enter as you type and the final result's shown in the "terminal" together with the numbers or equation when you press the Enter key. SpeedCrunch has a terminal-like window where you can enter numbers right away. It's a great choice if you are looking for something to assign to that Calc(ulator) key found on many modern keyboards. The homepage describes it as a "high-precision scientific calculator" and while that's true it is also the by far best general-purpose calculator available on Linux platforms. SpeedCrunch is a very efficient and easy to use free calculator program for Linux, Windows and macOS.
0 kommentar(er)
