Update README

Author: WrathfulSpatula

README.md

@@ -61,7 +61,7 @@ The developer anticipates this single-function set of parameters, as API, is the
 
 Advantage for `use_congruence_of_squares` is beyond the hardware scale of the developer's experiments, in practicality, but it can be shown to work correctly (at disadvantage, at small factoring bit-width scales). The anticipated use case is to turn this option on when approaching the size of modern-day RSA semiprimes in use.
 
-If this is your use case, you want to specifically consider `smoothness_bound_multiplier`, `batch_size_multiplier`, and potentially `thread_count` for managing memory. By default, as many primes are kept for "smooth" number sieving as bits in the number to factor. This is multiplied by `smooth_bound_multiplier` (and cast to a discrete number of primes in total). This multiplier tends to predominate memory, but `batch_size_multiplier` can also cause problems if set too high or low, as a high value might exhaust memory, while a low value increases potentially nonproductive Gaussian elimination checks, which might be more efficient if batched higher.
+If this is your use case, you want to specifically consider `smoothness_bound_multiplier`, `batch_size_multiplier`, and potentially `thread_count` for managing memory. By default, as many primes are kept for "smooth" number sieving as bits in the number to factor. This is multiplied by `smooth_bound_multiplier` (and cast to a discrete number of primes in total). This multiplier tends to predominate memory, but `batch_size_multiplier` can also cause problems if set too high or low, as a high value might exhaust memory, while a low value increases potentially nonproductive Gaussian elimination checks, which might be more efficient if batched higher. Our expectation is that most systems will benefit from setting `batch_size_multiplier` _much_ higher than default, potentially to the point of using about half of available memory, but this will require user experimentation to determine.
 
 `wheel_factorization_level` and `gear_factorization_level` are common to both `use_congruence_of_squares` (i.e., Gaussian elimination for perfect squares) and "brute force." `11` for gear and `5` for wheel limit works well for small numbers. You'll definitely want to consider (gear/wheel) `13`/`7` or `17`/`11` (or even other values, maybe system-dependent) as your numbers to factor approach cryptographic relevance.