Imprecision of timers and working around it (Lua)

[Uncle]

The problem is that the Reals aren't precise. Here's a simple code I made in Lua:

local duration = 5.00

TimerStart(SomeTimer, 0.05, true, function()
    duration = duration - 0.05
    print("Duration = ", duration)
    if duration <= 0 then
        --End the timer
    end
end
end)

When I print out duration it starts out precise displaying "Duration = 5.00, 4.95, 4.90, etc..." but eventually it starts to lose precision and I begin to see "Duration = 3.999" instead of "Duration = 4.0". This is a problem if say I wanted to check when duration was equal to exactly "0.50". So how exactly would you recommend working around this?

local counter = 100

TimerStart(SomeTimer, 0.05, true, function()
    counter = counter - 1
    print("Duration = ", counter)
    if counter == 0 then
        --End the timer
    end
end
end)

I know I can rely on Integers like in the example above but I'd rather not do this since it complicates things (especially if I want the duration to change depending on different variables).

Am I missing something? Can I get precise Reals or am I stuck with using <= and booleans and all sorts of weird tricks to check how much time has elapsed in my repeating timer?

 

[The_Silent]

Looks like floating point errors. Not sure what the best way to get around those in wc3 lua. Usually I would just ignore them, as they are usually so small they are negligible.
Solutions for floating point rounding errors

 

[Dr Super Good]

The solution is to not use reals to meter time. Either use integers to meter ticks/cycles or use timer callbacks which run after the full duration.

Reals are 32 bit software emulated floating point numbers. They are subject to floating point error like all floating point numbers. Nothing stops one from implementing fixed point numbers using integers to meter fractional time in a way that is not subject to floating point error.

 

[WaterKnight]

I often used a separate timer for the duration since this also has the nice effect of decoupling the two things but it depends really. If you want a fixed amount of intervals, better ensure that explicitly with integer ticks.

 

[Ceday]

Never accumulate real values like that. When I am making spells with some kind of duration using timers, I calculate how many timer ticks will occur first and store that value in an integer variable. For example period of your timer is 0.05 and duration of your spell is calculated as 3.42. This means 68 ticks will occur. I accumulate elapsed ticks in timer callback and finish the timer when it reaches 68.

 

[Uncle]

Thanks for the replies. I'll probably end up using two timers for some things.
Anyway, I realized I could still use Integers and achieve what I was trying to do:

A Damage over Time ability with a Duration that differs based on the casting unit's "Skill Duration" stat. As seen in a lot of games like Path of Exile.

SkillDuration[source] = GetRandomReal(1.0, 2.0) 

function Ignite()
    --Configure
    local source = GetTriggerUnit()
    local target = GetSpellTargetUnit()
    local duration = 5.00 * SkillDuration[source]
    local totaldamage = 300.00 * SkillDuration[source]
    local intervals = 10

    local timerinterval = duration / intervals
    local damage = totaldamage / intervals

    TimerStart(CreateTimer(), timerinterval, true, function()
        intervals = intervals - 1
        UnitDamageTarget(source, target, damage, false, true, ATTACK_TYPE_CHAOS, DAMAGE_TYPE_UNIVERSAL, nil)
        if intervals == 0 then
            --destroy timer
        end
    end)     
end
end