From fd742dcca5c70f2f7ed66afc3eea838f933412b1 Mon Sep 17 00:00:00 2001 From: T045TN1NJ4 Date: Sat, 8 Mar 2025 15:15:43 -0500 Subject: [PATCH] Update explicit-accuracy-for-math-round.md --- docs/explicit-accuracy-for-math-round.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/explicit-accuracy-for-math-round.md b/docs/explicit-accuracy-for-math-round.md index c02d148..df037cb 100644 --- a/docs/explicit-accuracy-for-math-round.md +++ b/docs/explicit-accuracy-for-math-round.md @@ -11,7 +11,7 @@ The motivation for this proposal lies solely in improving user convenience. Albe 1. It's a 'one-more-than-necessary' utility users have to carry around 2. Though the difference is negligible in most scenarios, it's computationally slower, even in `native` -Allowing users to specify to what degree of accuracy `math.round` should round to feels like a very simple and appropriate expansion of the standard library. The change is also inherently a performance microoptimization [thanks to the fastcall op]. +The change, as proposed below, feels like a very simple and appropriate expansion of the standard library, and is inherently a performance microoptimization [thanks to the fastcall op]. ## Design As of writing this, a well-rounded implementation of rounding to a decimal place is something like so: