Long running time

One user of mine liked so much the app that he left it running for a LOOOONG time until it misbehaved.

Since my app uses event.time heavily (among other things) I believe that maybe event.time gets overly imprecise over time or overflows…

Or one of my variables are overflowing…

I can fix my own overflows, but how I check (without running the thing for hours) if it is not event.time causing problems? [import]uid: 142895 topic_id: 30339 reply_id: 330339[/import]

Since Lua uses Doubles as it’s default format, the range is absolutely massive.
You would be thinking less about running it for hours, and more about running it for multiple millenia.

Many systems will use floats, which have orders of magnitude less precision:

Float Range: ±1.5 × 10^?45 to ±3.4 × 10^38

VS

Double Range: ±5.0 × 10^?324 to ±1.7 × 10^308

The underlying OS time call will run out of values before Corona does.

Also, comparing Floats the Doubles, the main focus is on higher precision over higher range, meaning that you get many, many more significant digits at any particular value (the precision portion of the number (called significand) uses 52 bytes compared to a floats 23). And it can average approximately 16 significant digits over it’s range, allowing for potentially millisecond precision when running for over 300 000 years. [import]uid: 134101 topic_id: 30339 reply_id: 121547[/import]

How long is a “long time”?

Behind the scenes I think one of our timers might be in 32-bit unsigned integers measured in milliseconds depending on platform. This will overflow in a little over 49 days. But I think that timer suspends when backgrounded.

Accelerometer and Gyroscope timer callbacks are also fairly short depending on platform and hardware. These may overflow in some cases though usually you might only get one data point hiccup.

Over 2 years ago I remember a bug where we overflowed a timer because we were multiplying and then dividing instead of dividing and then multiplying. This would happen after about 11 minutes. But this was fixed. This was found/fixed by sitting around for long periods until things freaked out.

Anyway, I think (but you should verify) that event.time is the same value as system.getTimer() which is the time since launch. I think this timer is somewhat platform dependent so it may overflow at different values. If you can narrow down which timer is overflowing on which system and after how long, I encourage you to file a bug report with us.
[import]uid: 7563 topic_id: 30339 reply_id: 121572[/import]

Since Lua uses Doubles as it’s default format, the range is absolutely massive.
You would be thinking less about running it for hours, and more about running it for multiple millenia.

Many systems will use floats, which have orders of magnitude less precision:

Float Range: ±1.5 × 10^?45 to ±3.4 × 10^38

VS

Double Range: ±5.0 × 10^?324 to ±1.7 × 10^308

The underlying OS time call will run out of values before Corona does.

Also, comparing Floats the Doubles, the main focus is on higher precision over higher range, meaning that you get many, many more significant digits at any particular value (the precision portion of the number (called significand) uses 52 bytes compared to a floats 23). And it can average approximately 16 significant digits over it’s range, allowing for potentially millisecond precision when running for over 300 000 years. [import]uid: 134101 topic_id: 30339 reply_id: 121547[/import]

How long is a “long time”?

Behind the scenes I think one of our timers might be in 32-bit unsigned integers measured in milliseconds depending on platform. This will overflow in a little over 49 days. But I think that timer suspends when backgrounded.

Accelerometer and Gyroscope timer callbacks are also fairly short depending on platform and hardware. These may overflow in some cases though usually you might only get one data point hiccup.

Over 2 years ago I remember a bug where we overflowed a timer because we were multiplying and then dividing instead of dividing and then multiplying. This would happen after about 11 minutes. But this was fixed. This was found/fixed by sitting around for long periods until things freaked out.

Anyway, I think (but you should verify) that event.time is the same value as system.getTimer() which is the time since launch. I think this timer is somewhat platform dependent so it may overflow at different values. If you can narrow down which timer is overflowing on which system and after how long, I encourage you to file a bug report with us.
[import]uid: 7563 topic_id: 30339 reply_id: 121572[/import]