mirror of
https://github.com/luau-lang/rfcs.git
synced 2025-04-03 18:10:56 +01:00
Propose explicit accuracy input for math.round
This commit is contained in:
parent
12a39c3fdb
commit
44c56624cf
1 changed files with 50 additions and 0 deletions
50
docs/explicit-accuracy-for-math-round.md
Normal file
50
docs/explicit-accuracy-for-math-round.md
Normal file
|
@ -0,0 +1,50 @@
|
|||
# Explicit accuracy for math.round
|
||||
|
||||
## Summary
|
||||
This RFC proposes introducing a second parameter to `math.round` to allow users to declare a degree of accuracy to round numbers to.
|
||||
```luau
|
||||
print( math.round(3.1415, 2) ) -- Output: 3.14
|
||||
```
|
||||
|
||||
## Motivation
|
||||
The motivation for this proposal lies solely in improving user convenience. Albeit very simple, the concept's current implementation (demonstrated in **Design**) has two major flaws:
|
||||
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].
|
||||
|
||||
## Design
|
||||
As of writing this, a well-rounded implementation of rounding to a decimal place is something like so:
|
||||
```lua
|
||||
local function round_to( n: number, decimal_places: number? )
|
||||
assert(type(n) == 'number', 'first arg must be a number')
|
||||
assert((decimal_places == nil) or (type(decimal_places) == 'number'), 'second arg must be a number')
|
||||
decimal_places = math.max(decimal_places or 0, 0)
|
||||
local scale = 10 ^ decimal_places
|
||||
return math.round( n * scale )/scale
|
||||
end
|
||||
print( round_to(3.1415, 2) ) -- Output: 3.14
|
||||
```
|
||||
The proposed change provides the same level of convenience as the above `round_to` function without impacting the--for lack of a better term--'visual' size of projects. The change is simple: introduce a second parameter to `math.round` which accepts `number?`s.
|
||||
```lua
|
||||
-- proposed change
|
||||
print( math.round(3.1415, 2) ) -- Output: 3.14
|
||||
```
|
||||
`math.round`'s new type signature would be `( n: number, decimal_places: number? ) -> number`.
|
||||
|
||||
This RFC won't make any suggestions for handling edge cases (ie. if the `decimal_places` input is a negative number, or a non-nil but invalid type) because I don't want to assume any specific way is the best way.
|
||||
|
||||
## Drawbacks
|
||||
Implementing this change would increase the physical size of Luau, which is antithetical to Luau's 'minimal size principle'.
|
||||
|
||||
It may also be worth considering that because `math.round` has gone unchanged for so long, some users may be confused when seeing the new syntax.
|
||||
|
||||
## Alternatives
|
||||
One alternative could be to introduce a new function in the `math` library specifically for rounding to decimal places.
|
||||
```lua
|
||||
-- imagine 'todec' means 'to decimal [precision...?]'
|
||||
print( math.todec(3.1415, 2) ) -- Output: 3.14
|
||||
```
|
||||
The problem with this approach is that it's a rather unnecessary cluttering of the `math` library, especially in comparison to the proposed, much simpler solution. While they both achieve the same thing, this approach feels like it 'takes up too much space'.
|
||||
|
||||
Another alternative could be to continue doing nothing. My only argument against not changing is that I think there's nothing to lose by making the change, however, I recognize that that's largely my personal bias, and that it may also be, in some ways and to some extent, an uneducated take.
|
Loading…
Add table
Reference in a new issue