Warnings » Histórico » Versión 6
Federico Vera, 2018-07-17 09:55
1 | 1 | Federico Vera | # Warnings |
---|---|---|---|
2 | |||
3 | 2 | Federico Vera | {{>toc}} |
4 | |||
5 | 1 | Federico Vera | # Checking for errors |
6 | 5 | Federico Vera | |
7 | ## Concatenating comparison operators |
||
8 | |||
9 | This is a brutal **_and very common_** error. Imagine the following equation: `a < b < c`, now let's set `a = 1`, `b = 3` and `c = 2` so it will roughly translate to `1 < 3 < 2`. Those of you not familiarized with operator precedence evaluation might think that this will result in `false` but it will actually return `true`. Why? Well: |
||
10 | ``` |
||
11 | a < b < c -> ((a < b) < c) |
||
12 | ``` |
||
13 | So the example will become: |
||
14 | ``` |
||
15 | 1 < 3 < 2 -> ((1 < 3) < 2) -> ((1) < 2) -> 1 |
||
16 | ``` |
||
17 | 6 | Federico Vera | So the morality of this tale is: **if unsure, DON'T CONCATENATE OPERATORS** |
18 | 5 | Federico Vera | |
19 | 1 | Federico Vera | # Variable naming |
20 | Avoid variables and functions with the same name as build-in functions, constant or operators (or even custom functions). Even though this is possible and permitted by this version of `exp4j` we intent to create a more strict version in the future. |
||
21 | |||
22 | Why is this bad? well... if we have a built-in function called `sin(x)` and create a second function called `sin(x, y)` and use a variable called `sin` you might end up with expressions like: `sin(sin(sin, sin(sin)) + sin) ` this may sound dumb, but unfortunately is very common. |
||
23 | |||
24 | # Performance |
||
25 | |||
26 | ## Multiple calls to `Expression#evaluate()` |
||
27 | This is a common mistake, values returned from `Expression#evaluate()` are not cached, so every call will reevaluate the entire expression. There are two options: |
||
28 | 1. Save the value of `Expression#evaluate()` instead of calling it multiple times |
||
29 | 1. Implement the result cache! Checkout #752 for some details |
||
30 | 4 | Federico Vera | |
31 | ## Simplifier enabled for single evaluation |
||
32 | |||
33 | The simplifier needs to do a full evaluation of the code in order to make the simplifications, so it should not be enabled for single evaluation, since this will create a 100% loss in performance (the expression needs to be evaluated twice). |
||
34 | ## Write simplifiable expressions |
||
35 | |||
36 | Even though you can use the `Expression#toString()` method to checkout the number of tokens, the rule of thumb is to sort the expression: |
||
37 | |||
38 | For instance the expression `2 + 3x - 1` is not simplifiable, because the `Simplifier` does not alter the order of the operators (Operators can be overridden and there's no way of handling those scenarios). |
||
39 | If you change `2 + 3x - 1` to `2 - 1 + 3x` it will be simplified to `1 + 3x`. |