5 ms·
> 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 us
by marijn 8y ago
> 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.
- ainar-g 8y agoEven 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.
- gvx 8y agoIf my calculations are correct, 520 bits should be enough to count in units of Planck time until the heath death of the universe.
- bunderbunder 8y agoProbably 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.
- lucb1e 8y agoI 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.
- deleted 8y ago[deleted]
- AnimalMuppet 8y agoIf I recall correctly, at least some guidelines for avionics software (JSF, maybe?) forbid dynamic memory allocations, period.
- bunderbunder 8y agoJPL's does. See Rule 5, on page ten: https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
- monocasa 8y agoIn addition to JPL's, the JSF's does too, after initialization. That is you can malloc at startup, but not past that.
- berti 8y agoThat's a general thing for safety critical real-time systems, not just avionics.
- manicdee 8y agoAre you assuming an update to a number will use the same memory as the original number, and that the original memory will be released?
- shrimp_emoji 8y agoAlways buy in to 64. What was our ancestors' problem?[0] 0: https://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem
- codeulike 8y agoStorage space was the problem, used to be expensive.
- wnissen 8y agoSpecifically, 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.
- daemin 8y agoI 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.
- __david__ 8y agoThat'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.
- daemin 8y agoIt'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.
- beached_whale 8y agoAt 4 billion increments per second, it takes over 70 years to overflow a int64
- Symmetry 8y ago64 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.
- joe_the_user 8y agoThe 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 https://en.wikipedia.org/wiki/TLA%2B