chore(website,examples):fix typos (#1230)

fix a couple of typos in doc

Co-authored-by: Frank Laub <flaub@risc0.com>

examples/smartcore-ml/README.md

@@ -56,7 +56,7 @@ let model: KMeans<{float}, u8, DenseMatrix<{float}>, Vec<u8>> = trained_model;
 let model: PCA<{float}, DenseMatrix<{float}>> = trained_model;
 ```
 
-NOTE:  Deserialization of SVC and SVR does not includes that `SVCParametersmake` field.  It must be added back into the model struct manually after deserialization.  The RISC Zero SmartCore fork has amended the visbility of the model `struct`, making the parameters field public and thereby allowing the parameters field to be directly inserted into the model struct after deserialization.  You must insert the same parameters that were used when training the model.
+NOTE:  Deserialization of SVC and SVR does not includes that `SVCParametersmake` field.  It must be added back into the model struct manually after deserialization.  The RISC Zero SmartCore fork has amended the visibility of the model `struct`, making the parameters field public and thereby allowing the parameters field to be directly inserted into the model struct after deserialization.  You must insert the same parameters that were used when training the model.
 ```
 let mut model: SVC<{float}, i32, DenseMatrix<{float}>, Vec<i32>> = deserialized_svc_trained;
 let params = &SVCParameters::default().with_c(200.0).with_kernel(Kernels::linear());

examples/smartcore-ml/methods/guest/src/main.rs

@@ -62,7 +62,7 @@ pub fn main() {
             .with_c(200.0)
             .with_kernel(Kernels::linear());
 
-        // Now we can update the model with params_same.  The RISC Zero fork changes the visbility of the parameters field of the SVC and SVR model structs to public to allow for this reinsertion
+        // Now we can update the model with params_same.  The RISC Zero fork changes the visibility of the parameters field of the SVC and SVR model structs to public to allow for this reinsertion
         model.parameters = Some(params_same);
 
         // Now that the parameters have been loaded back into the SVC model struct, we can call predict on the model.

website/api/zkvm/developer-guide/guest-code-101.md

@@ -11,7 +11,7 @@ This page serves as an introduction to writing RISC Zero [guest code], to help y
 
 The full functionality of the guest is documented in the [`guest` module] of the [`risc0-zkvm` Rust crate].
 
-## Basic Guest Funtionality: Reading, Writing, and Committing
+## Basic Guest Functionality: Reading, Writing, and Committing
 
 To build a zkVM application, we need our guest program to be able to:
 

website/api/zkvm/developer-guide/optimization.md

@@ -440,7 +440,7 @@ A short description and associated cycle counts are listed below.
 <!-- prettier-ignore-start -->
 [^2]:
     Here “sampling” is in quotes because the profiler actually captures the call stack at every cycle of program execution. Capturing a call stack on every cycle of execution is not done in most programs on physical CPUs for a few reasons:
-    <!-- HACK: This comment prevents the list below from being interpretted to be a code block -->
+    <!-- HACK: This comment prevents the list below from being interpreted to be a code block -->
     - It would be cost prohibitive to do so for all but quite short program executions.
     - Introducing such heavy profiling would actually alter the performance characteristics in significant ways.
     <!-- -->

website/api/zkvm/developer-guide/profiling.md

@@ -85,7 +85,7 @@ Refer to the [pprof docs] for more inforamtion about the web interface.
 <!-- prettier-ignore-start -->
 [^1]:
     Here “sampling” is in quotes because the profiler actually captures the call stack at every cycle of program execution. Capturing a call stack on every cycle of execution is not done in most programs on physical CPUs for a few reasons:
-    <!-- HACK: This comment prevents the list below from being interpretted to be a code block -->
+    <!-- HACK: This comment prevents the list below from being interpreted to be a code block -->
     - It would be cost prohibitive to do so for all but quite short program executions.
     - Introducing such heavy profiling would actually alter the performance characteristics in significant ways.
     <!-- -->

website/api_versioned_docs/version-0.18/zkvm/developer-guide/guest-code-101.md

@@ -11,7 +11,7 @@ This page serves as an introduction to writing RISC Zero [guest code], to help y
 
 The full functionality of the guest is documented in the [`guest` module] of the [`risc0-zkvm` Rust crate].
 
-## Basic Guest Funtionality: Reading, Writing, and Committing
+## Basic Guest Functionality: Reading, Writing, and Committing
 
 To build a zkVM application, we need our guest program to be able to:
 

website/api_versioned_docs/version-0.19/zkvm/developer-guide/guest-code-101.md

@@ -11,7 +11,7 @@ This page serves as an introduction to writing RISC Zero [guest code], to help y
 
 The full functionality of the guest is documented in the [`guest` module] of the [`risc0-zkvm` Rust crate].
 
-## Basic Guest Funtionality: Reading, Writing, and Committing
+## Basic Guest Functionality: Reading, Writing, and Committing
 
 To build a zkVM application, we need our guest program to be able to:
 

website/docs/proof-system/proof-system-sequence-diagram.md

@@ -108,8 +108,8 @@ For a more formal articulation of the protocol, refer to the [ZKP Whitepaper].
   - After computing the `data columns` and `auxiliary/accum columns,` the Prover adds some random `noise` to the end of those columns in order to ensure that the protocol is zero-knowledge.
 - The Prover encodes the `trace` as follows:
   - The Prover converts each `column` into a polynomial using an `iNTT`. We'll refer to these as `Trace Polynomials`, denoted $P_i(x)$.
-  - The Prover evaluates the `data polynomials` and the `control polynomials` over an expanded domain. The evaluations of the `data polynomials` and the `control polynomials` over this larger domain is called the `Extended Main Exeution Trace`.
-  - The Prover commits the `Extended Main Exeuction Trace` into two separate Merkle Trees, sending the roots to the Verifier.
+  - The Prover evaluates the `data polynomials` and the `control polynomials` over an expanded domain. The evaluations of the `data polynomials` and the `control polynomials` over this larger domain is called the `Extended Main Execution Trace`.
+  - The Prover commits the `Extended Main Execution Trace` into two separate Merkle Trees, sending the roots to the Verifier.
 
 ### Extended Auxiliary Execution Trace