RFC: math.truncate

[karl-police]

math.truncate it cuts off digits after the decimal point, without having to use math.floor or math.clamp.
🤔

Render

[ishtar112]

This RFC aligns with an RFC I made a while back that was rejected, however, your proposal does a great job of "answering" the reasons why mine was rejected. Would be happy to see this happen.

[MagmaBurnsV]

You can already achieve number truncation with math.modf.

Furthermore, it is trivial to construct a function that truncates to a specific decimal digit with this, which is what I assume you mean by the term "idp" in the RFC.

local function truncate(value: number, digits: number): number
	local factor = 10 ^ digits
	return math.modf(value * factor) / factor
end

The only value a new standard function could bring is streamlining arbitrary digit truncation, which I do not believe is a common enough operation to justify addition.

[karl-police]

You can already achieve number truncation with math.modf.

Furthermore, it is trivial to construct a function that truncates to a specific decimal digit with this, which is what I assume you mean by the term "idp" in the RFC.

local function truncate(value: number, digits: number): number
	local factor = 10 ^ digits
	return math.modf(value * factor) / factor
end

The only value a new standard function could bring is streamlining arbitrary digit truncation, which I do not believe is a common enough operation to justify addition.

Since that one returns a tuple, What happens to the the second tuple in memory? Does it just get reliably garbage collected?

[aatxe]

Since that one returns a tuple, What happens to the the second tuple in memory? Does it just get reliably garbage collected?

Luau does not have tuples. modf returns two numbers on the stack, and if they are not used, they are not used. There's no heap allocation associated with returning two numbers.

[karl-police]

Since that one returns a tuple, What happens to the the second tuple in memory? Does it just get reliably garbage collected?

Luau does not have tuples. modf returns two numbers on the stack, and if they are not used, they are not used. There's no heap allocation associated with returning two numbers.

Ah, I see. Tuples to me are just a list of values, not sure if it has any other meanings.

You can already achieve number truncation with math.modf.

Is.modf more expensive than math.ceil and or math.floor?

[hardlyardi]

Is.modf more expensive than math.ceil and or math.floor?

I would guess that it's more expensive. But, with the advent of native codegen, I don't personally see why it would need to be inherently slower than a new builtin for the long term? Correct me if I'm wrong.

[karl-police]

Is.modf more expensive than math.ceil and or math.floor?

I would guess that it's more expensive. But, with the advent of native codegen, I don't personally see why it would need to be inherently slower than a new builtin for the long term? Correct me if I'm wrong.

Oh, yeah native codegen. But it would still run what it would run otherwise in the implementation I think.

[hardlyardi]

Is.modf more expensive than math.ceil and or math.floor?

I would guess that it's more expensive. But, with the advent of native codegen, I don't personally see why it would need to be inherently slower than a new builtin for the long term? Correct me if I'm wrong.

Oh, yeah native codegen. But it would still run what it would run otherwise in the implementation I think.

Native can do lots of funky stuff. I am honestly starting to think this is a question of "is the utility and standardization worth adding a new library function?"