6 ms·

An example, I'm unable to resolve so far: ISO 26262 includes the requirement to prevent “implausible values, execution errors, division by zero, and errors in

by qznc 6y ago

An example, I'm unable to resolve so far: ISO 26262 includes the requirement to prevent “implausible values, execution errors, division by zero, and errors in data flow and control flow” (8.4.4). I'm confident the division by zero aims at integer division because the result is undefined. For floating point, division-by-zero is perfectly fine and well defined by IEEE 754. Nevertheless, our safety folks require us to enable the traps and shut down the device in case a floating division by zero occurs. This is stupid because a division by a very small number has the same effect as division by zero. However, since it is explicitly mentioned in ISO 26262 nobody has the balls to allow it officially. I don't even want to estimate how many man-months have been burned to fix such "defects".

aliswe 6y ago
Mandatory additional detailed info: Division by zero in floating point equals to Infinity because in a floating point data structure there is space to represent such a value. For integers, there is no such information and therefore an exception should be thrown. For a 32-bit float, the following are true: Positive infinity: 011111111(and then 23 zeroes) Negative infinity: 111111111(and then 23 zeroes) NaN: x11111111(and then anything except all zeroes) ... x being either 0 or 1. Source: https://en.wikipedia.org/wiki/IEEE_754-1985#Positive_and_negative_infinity https://en.wikipedia.org/wiki/IEEE_754-1985#Positive_and_neg...
- AnIdiotOnTheNet 6y ago
  Mathematically speaking though, infinity is not the correct answer to x/0 anyway. It's just a usefully incorrect result in a lot of situations.
  - colejohnson66 6y ago
    Well, it’s incorrect when dividing by 0, yes. But when you do the limit as the bottom factor approaches 0, it makes sense. So, below, the first one is defined, while the second one isn’t. lim_{x->0+} 1/x == +Infinity 1/0 != (anything)
    - corty 6y ago
      Yes, but thats only a small part of the story, your limit only works if the numerator is constant, positive and > 0. Actually, the correct answer for lim{x->0} a/x is really "anything" and "strongly depends on a and da/dx"... So in general, assuming anything like \infty for a division by zero is wrong wrong wrong.
      - BeetleB 6y ago
        IEEE 754 handles all the cases you mentioned - it doesn't always prescribe Inf.
      - colejohnson66 6y ago
        Sorry if I wasn’t clear. I was not implying that any a/b where b approaches 0 is always +infinity. I was simply saying that a/0 isn’t defined, but that in the case of 1/x (positive 0), it is somewhat defined as positive infinity.
    - nybble41 6y ago
      That depends on the numerator: lim_{x->1+} (x^2-1)/(x-1) == 2 Of course ideally evaluating this particular formula for x == 0 would give 0/0 which IEEE FP defines as NaN, but you could also get a non-zero finite number divided by zero due to rounding for x ≅ 1 and then the default result of +Infinity would be very far from the correct answer. Any situation where you might come close to a 0/0 or ∞/∞ term requires very careful consideration since there is very little separation between a NaN result and ±Infinity.
  - renewiltord 6y ago
    That's true for a lot of IEEE-754. 1/0 is defined in it in a useful way. Just as 1/3 is defined in a useful way that is not equivalent to its mathematical property.
  - rcoveson 6y ago
    It's not the correct answer for division of the reals. For division of IEEE 754 floats, it is the correct answer, because division in that context is defined that way.
tonyarkles 6y ago
Somewhat recent experience doing robotics work really highlighted the dangers of dividing by small numbers. As a robot arm approaches a singular configuration, the matrix used to calculate motor torques starts to get very bad and, left unaddressed, will likely result in some pretty wild behaviour. I would argue that dividing by very tiny numbers is also something that you should probably be catching, since the output very large numbers are likely not going to do what you’re expecting...
- sixstringtheory 6y ago
  Keywords to google for those interested: well-conditioned [matrix or function], gimbal lock, wrist flip. There are some cool videos of wrist flips online, and I’ve heard of a pickup truck being thrown by an articulated arm on a factory floor due to it. Sounds worth the precaution, given the right context!
globular-toast 6y ago
Just because division by zero produces a value doesn't mean the value means anything or should ever have been obtained. Division by a very small number and division by zero should NOT have the same effect. That is the error which you're supposed to catch by not dividing by zero in the first place.
BeetleB 6y ago
I worked briefly in the ISO 26262 space. While I don't have a copy of it in front of me, my understanding was not so much that you must prevent division by zero, as much as it is that you handle division by zero appropriately. Appropriately means that you can show that if you get a divide by zero, safety is not compromised. If I get an Inf or a NaN in a calculation involving cruise control, and I do nothing to handle it, do you think it will be OK? More formally, if you have a potential division by zero and get an Inf (or NaN in case it's 0/0), you have to show what impact this will have. Can it result in a safety violation? If yes, what ASIL level would this result in? Based on this, you define your mitigation. It seems the safety folks have defined the mitigation to be "shut down the device". If you can show that there is a simpler mitigation, or that a mitigation is not needed (i.e. has no safety impact), then they should back off. This mitigation does need to be noted and documented, though. Of course, this could be an organizational issue: Perhaps the safety folks are being the safety gatekeepers as a small portion of their job, so they are not willing to spend time to deal with nuances. I was the guy responsible for safety for my team, and it sucked - but I was doing it full time so I could analyze scenarios. The challenge was that the developers were not well versed with the ISO standard (had never read it), and it was a small portion of their job, and so they kept arguing. > This is stupid because a division by a very small number has the same effect as division by zero. As others have pointed out, this is not true. There is a big difference between a very large result and Inf. And of course, if a very large result could lead to a safety violation, then you need to handle it. > For floating point, division-by-zero is perfectly fine and well defined by IEEE 754. Keep in mind that conformance to the IEEE 754 standard is often not complete. Don't assume your language (or your libraries) are fully conformant, unless they are advertised as such. Even if the ISO 26262 standard seems to have definitive language, I seem to recall there is a portion of the standard that allows you to waive requirements if the requirement makes no sense in your use case. There is a procedure to do it (documenting, etc). FWIW, we did not handle Inf or NaN or divide by zero anywhere. We were writing a general purpose library for auto manufacturers, and it was up to them to decide where/how it would be used (called "Safety Element Out of Context" in the standard). Since we did not know the context, we argued that we can't assess if a division by zero would be hazardous, and merely noted in the documentation where it could occur. It's up to the folks who buy our libraries to then do that analysis. We only took care of things like showing there were no known crashes or hangs.
bonzini 6y ago
> This is stupid because a division by a very small number has the same effect as division by zero. It doesn't, it cannot ever return NaN.

by qznc 6y ago

aliswe 6y ago

Mandatory additional detailed info: Division by zero in floating point equals to Infinity because in a floating point data structure there is space to represent such a value. For integers, there is no such information and therefore an exception should be thrown. For a 32-bit float, the following are true: Positive infinity: 011111111(and then 23 zeroes) Negative infinity: 111111111(and then 23 zeroes) NaN: x11111111(and then anything except all zeroes) ... x being either 0 or 1. Source: https://en.wikipedia.org/wiki/IEEE_754-1985#Positive_and_negative_infinity https://en.wikipedia.org/wiki/IEEE_754-1985#Positive_and_neg...

AnIdiotOnTheNet 6y ago
Mathematically speaking though, infinity is not the correct answer to x/0 anyway. It's just a usefully incorrect result in a lot of situations.
- colejohnson66 6y ago
  Well, it’s incorrect when dividing by 0, yes. But when you do the limit as the bottom factor approaches 0, it makes sense. So, below, the first one is defined, while the second one isn’t. lim_{x->0+} 1/x == +Infinity 1/0 != (anything)
  - corty 6y ago
    Yes, but thats only a small part of the story, your limit only works if the numerator is constant, positive and > 0. Actually, the correct answer for lim{x->0} a/x is really "anything" and "strongly depends on a and da/dx"... So in general, assuming anything like \infty for a division by zero is wrong wrong wrong.
    - BeetleB 6y ago
      IEEE 754 handles all the cases you mentioned - it doesn't always prescribe Inf.
    - colejohnson66 6y ago
      Sorry if I wasn’t clear. I was not implying that any a/b where b approaches 0 is always +infinity. I was simply saying that a/0 isn’t defined, but that in the case of 1/x (positive 0), it is somewhat defined as positive infinity.
  - nybble41 6y ago
    That depends on the numerator: lim_{x->1+} (x^2-1)/(x-1) == 2 Of course ideally evaluating this particular formula for x == 0 would give 0/0 which IEEE FP defines as NaN, but you could also get a non-zero finite number divided by zero due to rounding for x ≅ 1 and then the default result of +Infinity would be very far from the correct answer. Any situation where you might come close to a 0/0 or ∞/∞ term requires very careful consideration since there is very little separation between a NaN result and ±Infinity.
- renewiltord 6y ago
  That's true for a lot of IEEE-754. 1/0 is defined in it in a useful way. Just as 1/3 is defined in a useful way that is not equivalent to its mathematical property.
- rcoveson 6y ago
  It's not the correct answer for division of the reals. For division of IEEE 754 floats, it is the correct answer, because division in that context is defined that way.

tonyarkles 6y ago

Somewhat recent experience doing robotics work really highlighted the dangers of dividing by small numbers. As a robot arm approaches a singular configuration, the matrix used to calculate motor torques starts to get very bad and, left unaddressed, will likely result in some pretty wild behaviour. I would argue that dividing by very tiny numbers is also something that you should probably be catching, since the output very large numbers are likely not going to do what you’re expecting...

sixstringtheory 6y ago
Keywords to google for those interested: well-conditioned [matrix or function], gimbal lock, wrist flip. There are some cool videos of wrist flips online, and I’ve heard of a pickup truck being thrown by an articulated arm on a factory floor due to it. Sounds worth the precaution, given the right context!

globular-toast 6y ago

Just because division by zero produces a value doesn't mean the value means anything or should ever have been obtained. Division by a very small number and division by zero should NOT have the same effect. That is the error which you're supposed to catch by not dividing by zero in the first place.

BeetleB 6y ago

I worked briefly in the ISO 26262 space. While I don't have a copy of it in front of me, my understanding was not so much that you must prevent division by zero, as much as it is that you handle division by zero appropriately. Appropriately means that you can show that if you get a divide by zero, safety is not compromised. If I get an Inf or a NaN in a calculation involving cruise control, and I do nothing to handle it, do you think it will be OK? More formally, if you have a potential division by zero and get an Inf (or NaN in case it's 0/0), you have to show what impact this will have. Can it result in a safety violation? If yes, what ASIL level would this result in? Based on this, you define your mitigation. It seems the safety folks have defined the mitigation to be "shut down the device". If you can show that there is a simpler mitigation, or that a mitigation is not needed (i.e. has no safety impact), then they should back off. This mitigation does need to be noted and documented, though. Of course, this could be an organizational issue: Perhaps the safety folks are being the safety gatekeepers as a small portion of their job, so they are not willing to spend time to deal with nuances. I was the guy responsible for safety for my team, and it sucked - but I was doing it full time so I could analyze scenarios. The challenge was that the developers were not well versed with the ISO standard (had never read it), and it was a small portion of their job, and so they kept arguing. > This is stupid because a division by a very small number has the same effect as division by zero. As others have pointed out, this is not true. There is a big difference between a very large result and Inf. And of course, if a very large result could lead to a safety violation, then you need to handle it. > For floating point, division-by-zero is perfectly fine and well defined by IEEE 754. Keep in mind that conformance to the IEEE 754 standard is often not complete. Don't assume your language (or your libraries) are fully conformant, unless they are advertised as such. Even if the ISO 26262 standard seems to have definitive language, I seem to recall there is a portion of the standard that allows you to waive requirements if the requirement makes no sense in your use case. There is a procedure to do it (documenting, etc). FWIW, we did not handle Inf or NaN or divide by zero anywhere. We were writing a general purpose library for auto manufacturers, and it was up to them to decide where/how it would be used (called "Safety Element Out of Context" in the standard). Since we did not know the context, we argued that we can't assess if a division by zero would be hazardous, and merely noted in the documentation where it could occur. It's up to the folks who buy our libraries to then do that analysis. We only took care of things like showing there were no known crashes or hangs.

bonzini 6y ago

> This is stupid because a division by a very small number has the same effect as division by zero. It doesn't, it cannot ever return NaN.