Hello @naveen_pcs

There is many solution, I have write down one but without testing.

local myMonney="10000000000" -- I assume all number began by not a 0
local function myStringNumbertoNumber(myNumber)
    local theNumber={}
    local i=0
    while(i*30<string.len(myNumber)) do
       theNumber[i]=tonumber(string.sub(myNumber,i*30,(i+1)*30))
       i=i+1
    end
    return theNumber
end
local function myNumberToMyString(myNumber)
    local theNumber=""
    for(i=0,#myNumber)do
       theNumber=theNumber..myNumber[i]
    end
    return theNumber
end
local function compareLargeNumber(myNumber,myMonney)
     local theMyNumber=myStringNumbertoNumber(myNumber)
     local theMyMonney=myStringNumbertoNumber(myMonney)
     local result=0 -- 0 for equal, 1 for >,2 for <
     if(#theMyNumber>#theMyMonney) then   
         result=1
     else if(#theMyNumber<#theMyMonney) then    
         result=2
     else
         local i=0
         while(i<#theMyMonney) do
             if(theMyNumber[i]>theMyMonney[i])then
                result=1
                i=100 -- large number
             else if(theMyNumber[i]<theMyMonney[i])then
                result=2
                i=100 --large number
             else
                i=i+1
             end
         end
     end
     return result
end
local function addOrMinus(myNumber,myMonney,addOrMinus)--addOrMinus is true for add and false to minus
    local theMyNumber=myStringNumbertoNumber(myNumber)
    local theMyMonney=myStringNumbertoNumber(myMonney)
    -- continue like this, I think you have understood the logic behind
end

In my game. But lua looses precision after numbers greater than 2^53.

 

It's not Lua at fault, it's IEEE754 doubles.

But what's the real issue - just output fomatting or actual internal precision?

I'll tell you that the vast majority of incremental games out there (including ones that I've worked on) just use IEEE754 doubles and get away with it just fine.  Because they're NOT trying to add 1 to 1E33, for example.

That is, it's the nature of the game that in order to get a ridiculously large "bank", you need correspondingly ridiculously large "producers".  So all the math is always happening "within range" of what double precision is capable of.

Yes, you'd start losing "pennies" eventually, as you run out of bits to represent them, but who cares?! Most of these games, once beyond a certain point (usually about 1e9) start using some sort of modified scientific notation and maybe give you four or five decimals at most (fe 1.2345De for decillions, rarely would you see all 33 digits printed)

Consider:  If your balance is in the 1e33 range, and you THINK you need to be worried about some "producer" making $1/second, .... it would take something like 1e12 years before it even affected the 15th decimal place!  Few of your players will live that long.

(As nick sherman said) How about using a table like so: 

local money = {ones=0, hundreds=0, thousands=0, millions=0, billions=0, trillions=0, quadrillions=0}

Then you only need a string building function to parse the table and print the proper 0's and commas.

Whoops sorry. You did already suggest that.