prettier md

Author: matt-o-how

docs/sha256tree.md

@@ -1,6 +1,6 @@
 # Information on the new (sha256tree) operator
 
-Adding `sha256tree` as a native operator made sense as it is one of the most common functions, used in nearly every shipped ChiaLisp puzzle. 
+Adding `sha256tree` as a native operator made sense as it is one of the most common functions, used in nearly every shipped ChiaLisp puzzle.
 Furthermore it has an innate inefficiency in it's in-language implementation.
 Every internal hash is allocated as an atom in clvm_rs allocator.
 In addition to this, a native operator also opens the door to future optimisations via caching.
@@ -9,8 +9,9 @@ In addition to this, a native operator also opens the door to future optimisatio
 
 The matter of how to assign Cost to the new operator was the subject of intense thought and debate.
 It should be costed in proportion to:
+
 - the time to Cost vs other operators, and especially the `sha256` operator
-- the time to Cost ratio of the ChiaLisp implementation 
+- the time to Cost ratio of the ChiaLisp implementation
 - the size of its inputs
 
 The lattermost being a unique problem with regards to shatree as it is the first operator that parses trees, so utmost care must be taken when assigning cost.
@@ -21,7 +22,7 @@ One final consideration while costing is that we required it to tally the cost d
 
 The `BASE_COST` was set to equal the base cost of `sha256`.
 
-The `COST_PER_BYTES32` was designed as the sha256 operation operates on 32byte chunks. We set the Cost to be on parity with the Cost of `sha256` although sha256 costs `per byte` and `per arg`. 
+The `COST_PER_BYTES32` was designed as the sha256 operation operates on 32byte chunks. We set the Cost to be on parity with the Cost of `sha256` although sha256 costs `per byte` and `per arg`.
 We can ignore `per arg` as `sha256tree` only takes a single argument, and we benchmarked the `cost-per-bytes32` so that it matches `sha256`'s `cost-per-byte`.
 
 The calculations for this can be seen in the file `benchmark-clvm-cost.rs`.
@@ -34,24 +35,25 @@ The calculations for this can be seen in the file `sha256tree-benching.rs`.
 ## Costing Results
 
 `MacOS M1`
+
 ```
-Costs based on an increasing atom per bytes32 chunks: 
+Costs based on an increasing atom per bytes32 chunks:
 Native time per bytes32  (ns): 95.1425
 CLVM   time per bytes32  (ns): 94.9895
 Native implementation takes 100.1611% of the time.
 Native cost per bytes32      : 64.0000
 CLVM   cost per bytes32      : 64.0000
 100.1611% of the CLVM cost is:  : 64.1031
 
-Costs based on growing a balanced binary tree: 
+Costs based on growing a balanced binary tree:
 Native time per node  (ns): 203.8718
 CLVM   time per node  (ns): 517.8038
 Native implementation takes 39.3724% of the time.
 Native cost per node      : 564.0000
 CLVM   cost per node      : 1463.0000
 39.3724% of the CLVM cost is:  : 576.0185
 
-Costs based on growing a list: 
+Costs based on growing a list:
 Native time per node  (ns): 115.0891
 CLVM   time per node  (ns): 397.1927
 Native implementation takes 28.9756% of the time.
@@ -61,6 +63,7 @@ CLVM   cost per node      : 1399.0000
 ```
 
 `Windows`
+
 ```
 Costs based on an increasing atom per bytes32 chunks:
 Native time per bytes32  (ns): 10.4049
@@ -87,7 +90,6 @@ CLVM   cost per node      : 1399.0000
 10.0416% of the CLVM cost is:  : 140.4821
 ```
 
-
 ## Costing Graphs
 
 Below are the generated benchmarking graphs (PNG) from running `sha256tree-benching.rs` on Macbook M1.
@@ -103,5 +105,3 @@ Below are the generated benchmarking graphs (PNG) from running `sha256tree-bench
 ![Tree - Time per Node](graphs/tree_bench.png)
 
 ![Tree - Cost per Node](graphs/tree_cost.png)
-
-