Hacker News Reader

Comment by marijn | Hacker News Reader

> Your options are to increase the number of bits used, which puts off the overflow, or you could work with infinite precision arithmetic, which would slowly use up the available memory and finally bring the system down.

Yeah, no. Doubling the amount of bits to 64 while keeping the same precision gets you about 3 billion years worth of time, which is probably enough. And I'm going to leave calculating how much time it'd take to fill up any reasonable amount of memory with a single arbitrary-precision integer as an exercise to the reader.

View on HN

Even if you do use arbitrary precision arithmetic and count nanoseconds, the heat death of the universe is more likely to occur before your number takes 1KiB of RAM.

If my calculations are correct, 520 bits should be enough to count in units of Planck time until the heath death of the universe.

We should probably leave a bit of room in case any new physics is discovered prior to the heat death of the universe.

Make it 528 then. More than two orders of magnitude room ;)

Probably the deeper problem with using arbitrary precision arithmetic is that you end up with a variable-sized datatype, which I believe means at least a modicum of extra hassle & complexity for any language that the control software is likely to be written in. And less predictable timing, which might be a big no-no if this is something that needs to be used in timing-sensitive places.

I'd much rather take the 64-bit int, myself.

I was going to comment how you should probably still account for an overflow condition by warning at 70%, beeping at 80%, refusing to take off at 85%, etc., but it turns out that even with nanosecond precision timekeeping (1e-9), a signed 64 bit integer is enough for 292 years of not rebooting.

    (2^63)/1e9/3600/24/365 = ~292

Yeah, just go for that 64-bit int and call it a day.

If I recall correctly, at least some guidelines for avionics software (JSF, maybe?) forbid dynamic memory allocations, period.

JPL's does. See Rule 5, on page ten: https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

In addition to JPL's, the JSF's does too, after initialization. That is you can malloc at startup, but not past that.

That's a general thing for safety critical real-time systems, not just avionics.

Are you assuming an update to a number will use the same memory as the original number, and that the original memory will be released?

Always buy in to 64. What was our ancestors' problem?[0]

0: https://en.wikipedia.org/wiki/Year_2038_problem

Storage space was the problem, used to be expensive.

Specifically, 32 bits of PDP11 core memory cost on the order of $2, and that was per timestamp. Pretty obvious why you wouldn't go 64-bit unless you had to.

I don't think this cases needed to use 64bits for the clock. Because realistically I would hope that the plane would be serviced more than every 248 days. Therefore each service the computer could be reset or go into a self-check which would reset the computer and therefore prevent the overflow.

That's a silly attitude. You're right, the plane should be serviced regularly but that's no reason to build a time bomb in the code.

It's a pragmatic attitude, especially at a time when embedded devices were far more expensive and limited.

Granted the software could have been written to always take a delta and handle overflow of the variable gracefully rather than using the raw value.

The thing about the error is that it's very standard sort of error but an error which apparently formal methods didn't catch.

I've just been looking up TLA+ (model verification language) and I'm not sure how it would deal with avoiding overflow; it's approach is proving that a system will always be in a required state but avoiding overflow in most practical approaches involves effectively staying far enough away from the overflow condition that it never appears (as the other comments here go into). Done right, overflow will never be impossible, just unlikely.

https://en.wikipedia.org/wiki/TLA%2B

At 4 billion increments per second, it takes over 70 years to overflow a int64

64 bits is certainly the solution I would go for as well. Arbitrary precision numbers are going to involve heap allocation which is something I would normally like to avoid entirely in a system like this.

Reply on news.ycombinator.com