The only problem with that is that there is no way of knowing how much digits to print in the regex. You would imagine doing
local f = 0.1234567890123456789
print(string.format("%." .. string.len(tostring(f)) .. "f", f)
But that would not work because if he wants to use a fraction as the only input, tostring() will only return a certain number of digits, so if he does not have a fixed number in place of string.len(tostring(f)), then it will not work.
didn’t I literally say in my post that tostring stops at 13 decimal places, also it will count the “0.” as an extra 2 in the string.len()
Yes, you did. But you said that you don’t want it stopped at 13 decimal places, and that you wanted it to be stopped at wherever the fraction ends. That is my point. I am saying that it won’t work, not that it will work.
I believe I know what is going on here. You would be partially correct. It is not a bug but it is not intentional either. A computer stores information in RAM in all different data types. In this case, the fraction would be a float (decimal places). A computer does not have that much precision, and this is because you need to look at how a float even works.
You can see that it raises the mantissa to the power of the exponent. The mantissa can only be 23 bits and the exponent can only be 8 bits (binary: 8 bits = 1 character/number). Therefore, a float does not have infinite storage. Without an infinite amount of storage, it cannot keep storing additional numbers, it has to stop at some point. So, there is nothing much that you can do about this if you need to have a fraction of that length.
Well since fixing the precision issue is next to impossible with floating point numbers, we can at least fix the unneccesarry digits issue by turning our thinking around, what if we just remove the 0s at the end with string patterns?
print(string.gsub(string.format("%.20f", 0.12340000000000000000), "^%d*.?%d-([0]*)$", ""))
what does this print out?
I am on the road right now
this is very interesting, thanks for this
I don’t know, since I have no computer to test it with, so I’m going completely on brain and logic here.
It’s not possible to do it with integers since there is a limit.
Lua automatically shortens every number to 13 decimal places, so this:
tostring(0.12345678901234) -- "0.1234567890123"
Gets automatically transformed into this before tostring even gets called:
tostring(0.1234567890123) -- "0.1234567890123"
Your only option is to make your own system for storing numbers with a better decimal precision using strings for example, but that might be a difficult task to do in Lua so I wouldn’t really try attempting it at your level.
I’m not sure if there are already modules for that. You can try searching, because i remember a few ones that let you store numbers greater than the integer limit.
Yes, I believe that the only way that you would be able to store and convert this number would be to make your own numbering system. It would be a challenge, though just because you would literally need to rewrite addition, subtraction, comparisons, conditionals, and built-in functions.
yea you are right
I could do it at my level(if I actually wanted to do it in the first place), but I don’t think making a whole system is worth it for this simple function
if I have to, I will stick with the 13 decimal place limit, not a big deal
if @BenMactavsin’s idea doesn’t work then I’ll just stick with the 13 decimal place limit
tostring internally rounds to 14 significant digits, not 13 fractional digits in contrast to what many post here say.
You can see it here: Lua 5.1.5 source code - luaconf.h
therefore tostring is essentially string.format("%.14g", value).
Assuming you mean Luau “number”, you are factually incorrect and way off. All Luau “numbers” are double precision, not single precision which you’re talking about.
Depends what do you mean by “character” and “number”, to say 8 bits = 1 character/number without any context is simply incorrect.
Where on earth did you get this from? tostring isn’t a reliable source as it rounds it to 14 significant digits. This is factually incorrect as all Luau “numbers” are specified by the IEEE 754 double precision floating point format.
This statement is also incorrect, there’s no integer data type in Luau, all Luau “numbers” are IEEE doubles.
I thought it was up to 14 decimal places but after a point it only came up to 13, which I thought was odd because it did go up to 14 places yesterday for me anyways
Here is where I got this from.
Guess what? print in Luau calls the internal __tostring similar to Lua 5.4 that has virtually the exact same functionality as tostring), and I’ll repeat, tostring rounds the values to 14 significant digits.
Based on this image, how do you know it’s rounded to decimal places and not significant figures? How does that image lead you to conclude your statement?
No, I am not talking about Luau numbers. I am talking about numbers in binary data. I just explained what a number was in my post, and it just happened to be that there are numbers, not of any type such as a float, int, or double, literally just some binary.
sorry I accidentally made that the solution, misclick
oh and I’m still gone btw
yea this literally outputs as 1
I am going to make this the solution unless someone actually came up with something
gonna stick with the 14 decimal place limit for now
Okay so, this is my idea.
Find a way to multiply the number to a power of 10 so that there is no decimal left. Then you could use tostring and obviously make the changes you need (like adding “0.” in front of it or something).
Disregard this, found out that this has the exact same limits 
yep I realized this as I have already tried it before