Conversation
|
|
docs/math-constants.md
Outdated
| - `math.nan`: some `NaN` value as defined by IEEE 754. | ||
| - The exact representation (payload and sign) is unspecified. | ||
| - Comparing to `math.nan` will always return `false`; lint rules recommend using `math.isnan`. | ||
| - `math.e`: the mathematical constant $e = 2.71828182845904523536$. | ||
| - `math.tau`: the mathematical constant $\tau$, defined as `2 * math.pi`. |
There was a problem hiding this comment.
We can also include the golden ratio here as well, as another commonly relevant math constant. Others worth considering:
- sqrt(2)
- natural log of 2
- natural log of 10
I could see an argument for including precomputed logarithms as being a bit of a slope into a bunch of other constants since there's three log bases that are relevant to computing in some form (e, 10, and 2), but sqrt(2) is just something that comes up all the time as well.
There was a problem hiding this comment.
I added sqrt(2) but left out the logarithms for now.
Although, math.sqrt2 vs math.sqrt(2) seems like a sort of trivial difference.
There was a problem hiding this comment.
nan, phi and e are good as constants since there's no easy way to represent them save for typing them out fully or using non-obvious tricks like 0/0 and math.exp(1).
I don't like precomputed constants like tau and sqrt2 on principle that you can already represent them inline. The only argument that can be made in favor of them is that they would save writing time, which I would like to see some field evidence gathered on their use to support that.
There was a problem hiding this comment.
phi can be written as (1 + math.sqrt(5)) / 2. I don't think this is non-obvious because if you're using ϕ you definitely already know this definition. math.phi isn't descriptive either unless you're already introduced to ϕ (maybe math.goldenratio would be more descriptive?)
There was a problem hiding this comment.
tau, pi, and e are all computable to the degree of precision allowed by floating points too. The basis for any and all of them is "they're essential quantities that arise all the time in doing math in all sorts of domains, including the one that our language is designed to suit."
There was a problem hiding this comment.
math.goldenratio would be a fine name, though math.pi and math.tau already have the same problem of being just a greek letter you'd have to google to find out what they mean if you don't already know
There was a problem hiding this comment.
Yeah, I wouldn't rename it to math.goldenratio, we can use docstrings for this purpose.
There was a problem hiding this comment.
As I've said, I'm fine with nan, phi and e as they're all very common and just make sense to have in any standard library. I'm just on the fence with tau and especially sqrt2 since they aren't as quintessential and have obvious inline counterparts.
|
a way to obtain nan, e would be a nice addition since doing 0/0 or exp(1) arent very readable. adding tau and sqrt2 would be a bad idea since they can be represented by code thats just as readable ( pi*2 and sqrt(2) ). as for phi its on the line of bloat and a good feature since it doesnt have many use cases but i dont think it fits personally. |
Hi there, folks! We're back with another weekly Luau release! # Language * Adds the `const` keyword for defining constant bindings that are statically forbidden to be reassigned to. This implements [luau-lang/rfcs#166](luau-lang/rfcs#166). * Adds a collection of new math constants to Luau's `math` library per [luau-lang/rfcs#169](luau-lang/rfcs#169). # Analysis * Fixes a class of bugs where Luau would not retain reasonable upper or lower bounds on free types, resulting in types snapping to `never` or `unknown` despite having bounds. ```luau --!strict -- `lines` will be inferred to be of `{ string }` now, and prior -- was local lines = {} table.insert(lines, table.concat({}, "")) print(table.concat(lines, "\n")) ``` ```luau --!strict -- `buttons` will be inferred to be of type `{ { a: number } }` local buttons = {} table.insert(buttons, { a = 1 }) table.insert(buttons, { a = 2, b = true }) table.insert(buttons, { a = 3 }) ``` * Disables the type error from `string.format` when called with a dynamically-determined format string (i.e. a non-literal string argument with the type `string`) in response to user feedback about it being too noisy. * Resolves an ICE that could occur when type checking curried generic functions. Fixes #2061! * Fixes false positive type errors from doing equality or inequality against `nil` when indexing from a table * In #2256, adds a state parameter to the `useratom` callback for consistency with other callbacks. # Compiler - Improves the compiler's type inference for vector component access, numerical for loops, function return types and singleton type annotations, fixing #2244 #2235 and #2255. # Native Code Generation - Fixes a bug where some operations on x86_64 would produce integers that would take up more than 32-bits when a 32-bit integer is expected. We resolve these issues by properly truncating to 32-bits in these situations. - Improves dead store elimination for conditional jumps and fastcalls arguments, improving overall native codegen performance by about 2% on average in benchmarks, with some benchmarks as high as 25%. --------- Co-authored-by: Vyacheslav Egorov <vegorov@roblox.com>
6 participants
Rendered.