From 97d0d5074de431ddc762ef63e50b57d964e6fb65 Mon Sep 17 00:00:00 2001 From: Caleb Troyer Date: Fri, 15 Mar 2024 19:29:34 -0400 Subject: [PATCH] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 107f869..98b290e 100644 --- a/README.md +++ b/README.md @@ -25,7 +25,7 @@ The library implementation will be validated using the same methods the paper pr - Need to be able to lock a CPU core to 2.67 GHz for a fair comparison against the paper-- likely possible with Linux # Further Steps -I intend to take the paper a bit further once I implement my own version in Rust. Most of the paper's optimizations center around dropping higher order terms from standard equations and measuring their effects on the system, effectively finding a local minima where accuracy vs. speed was adequate for their purposes. I want to take this a bit further, and allow the number of higher order terms included to be configured at compile-time and on top of that, find other configurations that may compare to their paper in terms of accuracy vs. speed. Each configuration would be defined as the numbers of higher order terms to keep for each of the many sub-equations that make up the mathematical formulas. +I intend to take the paper a bit further once I implement my own version in Rust. Most of the paper's optimizations center around dropping higher order terms from standard equations and measuring their effects on the system, effectively finding a local minima where accuracy vs. speed that was good enough to publish. I want to take this a bit further, and allow the number of higher order terms included to be configured at compile-time and on top of that, find other configurations that may compare to their paper in terms of accuracy vs. speed. Each configuration would be defined as the numbers of higher order terms to keep for each of the many sub-equations that make up the mathematical formulas. # Disclaimer In addition to the disclaimers noted in the license, the author(s) of this are in no way associated with the authors of the SolTrack paper and make no claim to be.