If you are trying to print out something, you dont need to use tostring(). You can just call print(12345678901234) and I donât think it will cut off the string partially.
this isnât really a fraction, more like an integer
where exactly do you want me to do a second tostring() on
EDIT: honestly my main goal here is to turn a fraction into a string without a limit of 13 decimal places, donât really know how else to turn something into a string without tostring()
this is obviously not a bug, I know this in intentional
ima try it, I will reply back if it works
EDIT1: @BenMactavsin it doesnât work, I printed the exact code you sent but it forced 20 decimal places onto the number, as you can see this isnât the number in the code you send, it is slightly different
EDIT2: I am going to go somewhere so I wonât have access to studio, but I will still talk
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.
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?
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.
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