Fix spelling

Author: Victor Samoilov

docs/jlearch/execution-state-changes.md

@@ -26,16 +26,16 @@ classDiagram
 
 `StateAnalyticsProperties` maintains properties of `ExecutionState`, which don't need for symbolic execution, but need for `JLearch`.
 
-* `depth: Int` - number of forks on state's path excluded current state, if it is fork. In this case, fork is a state with more than one successors excluded implicit `NPE` branches.
-* `visitedAfterLastFork: Int` - number of `stmt`, that was visited by `states` on this state's path after last fork in first time.
-* `visitedBeforeLastFork: Int` - number of `stmt`, that was visited by `states` on this state's path before last fork in first time.
-* `stmtsSinceLastCovered: Int` - number of `states` on this state's path after last state that visited any `stmt` in first time.
+* `depth: Int` - number of forks on the state's path excluded current state, if it is fork. In this case, fork is a state with more than one successor excluded implicit `NPE` branches.
+* `visitedAfterLastFork: Int` - number of `stmt`, that was visited by `states` on this state's path after the last fork in first time.
+* `visitedBeforeLastFork: Int` - number of `stmt`, that was visited by `states` on this state's path before the last fork in first time.
+* `stmtsSinceLastCovered: Int` - number of `states` on this state's path after the last state that visited any `stmt` in first time.
 * `parent: ExecutionState?` - parent of current `state`. If `UtSettings.featureProcess == false`, then it is always null, because we don't need this field in this case. If it is not null, then we can't delete `state` until all successors of this state will be deleted, which may cause memory issue.
 * `executingTime: Long` - amount of time, during which this state was traversed.
 * `reward: Double?` - calculated reward of this state
 * `features: List<Double>` - list of extracted features for this state
 
-Field with `successor` prefix is used for constructor of successor properties.
+Field with `successor` prefix is used for a constructor of successor properties.
 
-* `updateIsFork()` - set `isFork` on true. This method called when traversing of `stmt` produce more than one explicit state. Now it may be during traversing of `IfStmt`, `SwitchStmt`, `AssignStmt` or `InvokeStmt`.
+* `updateIsFork()` - set `isFork` on true. This method is called when traversing of `stmt` produces more than one explicit state. Now it may be during the traversing of `IfStmt`, `SwitchStmt`, `AssignStmt` or `InvokeStmt`.
 * `updateIsCoveredNew()` - set `isVisitedNew` on true, set `stmtsSinceLastCovered` on zero and increase `visitedAfterLastFork` on 1. This method is called in `UtBotSymbolicEngine` after new state `s` is polled and `s.stmt` was not visited yet.

docs/jlearch/jlearch-architecture.md

@@ -65,7 +65,7 @@ This diagram doesn't illustrate some details, so read them below.
 
 # FeatureProcessor
 
-It is interface in framework-module, that allow to use implementation from analytics module.
+It is interface in framework-module, that allows to use implementation from analytics module.
 
 * `dumpFeatures(state: ExecutionState)` - dump features and rewards in some format on disk. Called at the end of traverse in `UtBotSymbolicEngine`
 
@@ -115,28 +115,28 @@ classDiagram
 
 Maintains calculation of reward. 
 
-* `calculateRewards(List<TestCase>): Map<Int, Double>` - calculates `coverage` for each state and `time` for each state. `Coverage` - sum of `newCoverage` by `TestCase` that contain its state. `Time` - sum of `state.executingTime` by all states, that has this state on its path. Then calculates `reward(coverage, time)`.
+* `calculateRewards(List<TestCase>): Map<Int, Double>` - calculates `coverage` for each state and `time` for each state. `Coverage` - sum of `newCoverage` by `TestCase` that contains its state. `Time` - sum of `state.executingTime` by all states, that has this state on its path. Then calculates `reward(coverage, time)`.
 
 ## FeatureProcessorWithStatesRepetition
 
 * `onVisit(state: ExecutionState)` - extractFeatures for state
 * `onTraversed(state: ExecutionState)` - create `TestCase`, so we go from `state` to `state.parent` while it is not root, for each `state` on path add its features to `dumpedStates`, calculate coverage of its `TestCase`, increment `generatedTestCases` on 1 and add new `TestCase` in `testCases`.
-* `dumpFeatures()` - call `RewardEstimator.calculateRewards()` and write `csv` file for each `TestCase` in format: `newCov,features,reward` for each `state` in it. `newCov` - flag that indicates whether this `TestCase` cover something new or not. So in this approach, each `state` will be written as many times as number of `TestCase` that has it.
-For creating `FeatureExtractor` it uses `FeatureExtractorFactory` from `EngineAnalyticsContext`.
+* `dumpFeatures()` - call `RewardEstimator.calculateRewards()` and write `csv` file for each `TestCase` in format: `newCov,features,reward` for each `state` in it. `newCov` - flag that indicates whether this `TestCase` cover something new or not. So in this approach, each `state` will be written as many times as the number of `TestCase` that has it.
+For creating `FeatureExtractor`, it uses `FeatureExtractorFactory` from `EngineAnalyticsContext`.
 
 # FeatureExtractor
 
-It is interface in framework-module, that allow to use implementation from analytics module.
-* `extractFeatures(state: ExecutionState)` - create features list for state and store it in `state.features`. Now we extract all features, which was described in [paper](https://files.sri.inf.ethz.ch/website/papers/ccs21-learch.pdf). In feature, we can extend feature list by other features, for example, NeuroSMT.
+It is interface in framework-module, that allows to use implementation from analytics module.
+* `extractFeatures(state: ExecutionState)` - create features list for state and store it in `state.features`. Now we extract all features, which were described in [paper](https://files.sri.inf.ethz.ch/website/papers/ccs21-learch.pdf). In feature, we can extend the feature list by other features, for example, NeuroSMT.
 
 # NNStateRewardPredictor
 
 Interface for reward predictors. Now it has two implementations in `analytics` module:
 
-* `NNStateRewardPredictorSmile`: it uses our own format to store feedforward neural network and it uses `Smile` library to do multiplication of matrix.
-* `NNStateRewardPredictorTorch`: it assumed that model is any type of model in `pt` format. It uses `Deep Java library` to use such models.
+* `NNStateRewardPredictorSmile`: it uses our own format to store feedforward neural network, and it uses `Smile` library to do multiplication of matrix.
+* `NNStateRewardPredictorTorch`: it assumed that a model is any type of model in `pt` format. It uses the `Deep Java library` to use such models.
 
-It should be created at the beginning of work and stored at `Predictors` class to be used in `NNRewardGuidedSelector` from `framework` module.
+It should be created at the beginning of work and stored at `Predictors` class to be used in `NNRewardGuidedSelector` from the `framework` module.
 
 
 # NNStateRewardGuidedSelector
@@ -149,4 +149,4 @@ We have two different implementantions:
 
 # EngineAnalyticsContext
 
-It is object that should be filled by factories in the beginning of work to allow objects from `framework` module using objects from `analytics` module. 
+It is an object that should be filled by factories in the beginning of work to allow objects from the `framework` module using objects from `analytics` module. 

docs/jlearch/new-heuristical-path-selectors.md

@@ -30,7 +30,7 @@ classDiagram
 ```
 `Subpath` = `List<Edge>`
 
-This class maintains frequency of each subpath with length `2^index`, which is presented as `List<Edge>`, on certain instance of `InterproceduralUnitGraph`
+This class maintains frequency of each subpath with length `2^index`, which is presented as `List<Edge>`, in a certain instance of `InterproceduralUnitGraph`
 
 * `onVisit(state: ExecutionState)` - we calculate subpath of this state and increment its frequency on `1`
 * `subpathCount(state: ExecutionState)` - we calculate subpath of this state and return its frequency
@@ -45,7 +45,7 @@ classDiagram
 
 Inspired by [paper](http://pxzhang.cn/paper/concolic_testing/oopsla13-pgse.pdf).
 
-We override `ExecutionState.weight` as `-StatementStatistics.subpathCount(this)`, so we pick `state`, which `subpath` is less traveled.
+We override `ExecutionState.weight` as `-StatementStatistics.subpathCount(this)`, so we pick the `state`, which `subpath` is less traveled.
 
 # StatementStatistics
 
@@ -66,11 +66,11 @@ classDiagram
     TraverseGraphStatistics o-- InterProceduralUnitGraph
 ```
 
-This class maintains frequency of each `Stmt` and number of `Stmt`, that was visited in some `SootMethod`, on certain instance of `InterproceduralUnitGraph`.
+This class maintains frequency of each `Stmt` and number of `Stmt`, that was visited in some `SootMethod`, on a certain instance of `InterproceduralUnitGraph`.
 
-* `onVisit(state: ExecutionState)` - increment frequency of state's `stmt` on 1. If we visit this `stmt` for the first time, then increment number of `Stmt`, that we visit in current state's `method`, on 1.
-* `statementCount(state: ExecutionState)` - get frequency of state's `stmt`
-* `statementsInMethodCount(state: ExecutionState)` - get number of `stmt`, that was visited in current state's `method`.
+* `onVisit(state: ExecutionState)` - increment frequency of state's `stmt` on 1. If we visit this `stmt` for the first time, then increment number of `Stmt`, that we visit in the current state's `method`, on 1.
+* `statementCount(state: ExecutionState)` - get a frequency of state's `stmt`
+* `statementsInMethodCount(state: ExecutionState)` - get number of `stmt`, that was visited in the current state's `method`.
 
 # CPInstSelector
 
@@ -89,5 +89,5 @@ classDiagram
     ForkDepthSelector --|> NonUniformRandomSearch
 ```
 
-Override `ExecutionState.cost` as `ExecutionState.depth`, so we are more likely to explore the least deep `state` in terms of number of forks on its path.
+Override `ExecutionState.cost` as `ExecutionState.depth`, so we are more likely to explore the least deep `state` in terms of the number of forks on its path.