3 ms·

given fn x -> int if (randf32() < P) { panic } return x x is buggy for all values of P except P=0 if you want to assume P=0 when P<n then OK b

given fn x -> int if (randf32() < P) { panic } return x x is buggy for all values of P except P=0 if you want to assume P=0 when P<n then OK but you have to prove that's safe in your use case, it's not something that can be assumed as true in general, no matter how small P gets

Dylan16807 3y ago
All software is buggy on real hardware. You said in another comment "i can control what my application uses as IDs" but no not really. You can control what it does the vast vast majority of the time, but it will sometimes go wrong. The user doesn't care if it's a logic error that would also happen on impossibly perfect hardware or if it's a logic error caused by trusting your hardware. There's an implicit "hope not to hit the ultra rare bad luck" on each line of code. And when the probabilities are low enough it's hard to even say which version is safer sometimes.
- preseinger 3y ago
  > All software is buggy on real hardware. definitely not "buggy" is a logical property of the program as expressed, not a physical property of the program as executed a solar ray flipping a memory bit on the hardware executing an otherwise correct program does not make that program buggy > There's an implicit "hope not to hit the ultra rare bad luck" on each line of code. there definitely is not, at least in the context of the program as expressed such a case of "bad luck" would violate the assumptions of the language model, and/or execution model, and/or hardware model, and/or etc., of the running program, in a way that would be likely undetectable and definitely un-fixable it would be an invariant violation of the hardware/os/language model -- but a bug is a logic error it is so important that programmers understand this distinction fn f1(x int) -> int { return x } fn f2(x int) -> int { if x==2 { panic } else { return x } } fn f3(x int) -> int { if rand() < 1e-10 { panic } else { return x } } f1 is correct, f2 is buggy, and f3 is buggy -- no matter if 1e-10 is 1e-10 or 1e-20 or 1e-30
  - Dylan16807 3y ago
    > such a case of "bad luck" would violate the assumptions of the language model, and/or execution model, and/or hardware model, and/or etc., of the running program, in a way that would be likely undetectable and definitely un-fixable Yes, assumptions. Everyone can only assume the bad luck won't happen despite it being a nonzero chance. Even if you want to play in the land of pure math, where software does as it's told, every mainstream compiler has bugs. Sometimes assuming things that aren't strictly true is the best path forward. That's why my first post started with "You can and should assume sufficiently likely things. It's a waste of time to worry about probabilities with enough zeroes." > it is so important that programmers understand this distinction Why is it important? Though I do understand the difference, while at the same time describing circumstances where it doesn't matter. And the breadth of those circumstances depends on the probability.
    - preseinger 3y ago
      you would therefore not object to a PR which added if randf32() < P { panic } to the beginning of every function in your code base, if P was sufficiently small?
      - Dylan16807 3y ago
        For f32, there is no sufficiently small P. If it was a random 1/2^200 chance, I would not object to it for the random chance. But it would have to actually improve the program execution in a significant way before I accept it. I wouldn't accept "if rand() < P { NOP }" being stuck into every function without a tangible benefit either, despite how safe it is. I didn't notice https://news.ycombinator.com/item?id=36330673 https://news.ycombinator.com/item?id=36330673 until just now but the first half sounds like you're agreeing with me. You can't remove the risk of solar rays, so you just have to live with it. 0% risk is an unreasonable standard. Certain things have to be outside your execution model, even though they're technically possible. Small small chances of logic errors don't have to be outside your execution model, obviously. But if they're a lot rarer than the errors you have to ignore, then you get no benefit from including them in your execution model. > if you want to make the assumption that secure_rand_u128 will never return 0, then you have to justify that assumption in the context of your specific use case -- it absolutely cannot be assumed in the general case I can agree with this... but my use case is 99.9% of all computing in the year 2023. Normal computers are not reliable enough to measure the difference in error rate of an occasional 1/2^128 chance.

Dylan16807 3y ago

All software is buggy on real hardware. You said in another comment "i can control what my application uses as IDs" but no not really. You can control what it does the vast vast majority of the time, but it will sometimes go wrong. The user doesn't care if it's a logic error that would also happen on impossibly perfect hardware or if it's a logic error caused by trusting your hardware. There's an implicit "hope not to hit the ultra rare bad luck" on each line of code. And when the probabilities are low enough it's hard to even say which version is safer sometimes.

preseinger 3y ago
> All software is buggy on real hardware. definitely not "buggy" is a logical property of the program as expressed, not a physical property of the program as executed a solar ray flipping a memory bit on the hardware executing an otherwise correct program does not make that program buggy > There's an implicit "hope not to hit the ultra rare bad luck" on each line of code. there definitely is not, at least in the context of the program as expressed such a case of "bad luck" would violate the assumptions of the language model, and/or execution model, and/or hardware model, and/or etc., of the running program, in a way that would be likely undetectable and definitely un-fixable it would be an invariant violation of the hardware/os/language model -- but a bug is a logic error it is so important that programmers understand this distinction fn f1(x int) -> int { return x } fn f2(x int) -> int { if x==2 { panic } else { return x } } fn f3(x int) -> int { if rand() < 1e-10 { panic } else { return x } } f1 is correct, f2 is buggy, and f3 is buggy -- no matter if 1e-10 is 1e-10 or 1e-20 or 1e-30
- Dylan16807 3y ago
  > such a case of "bad luck" would violate the assumptions of the language model, and/or execution model, and/or hardware model, and/or etc., of the running program, in a way that would be likely undetectable and definitely un-fixable Yes, assumptions. Everyone can only assume the bad luck won't happen despite it being a nonzero chance. Even if you want to play in the land of pure math, where software does as it's told, every mainstream compiler has bugs. Sometimes assuming things that aren't strictly true is the best path forward. That's why my first post started with "You can and should assume sufficiently likely things. It's a waste of time to worry about probabilities with enough zeroes." > it is so important that programmers understand this distinction Why is it important? Though I do understand the difference, while at the same time describing circumstances where it doesn't matter. And the breadth of those circumstances depends on the probability.
  - preseinger 3y ago
    you would therefore not object to a PR which added if randf32() < P { panic } to the beginning of every function in your code base, if P was sufficiently small?
    - Dylan16807 3y ago
      For f32, there is no sufficiently small P. If it was a random 1/2^200 chance, I would not object to it for the random chance. But it would have to actually improve the program execution in a significant way before I accept it. I wouldn't accept "if rand() < P { NOP }" being stuck into every function without a tangible benefit either, despite how safe it is. I didn't notice https://news.ycombinator.com/item?id=36330673 https://news.ycombinator.com/item?id=36330673 until just now but the first half sounds like you're agreeing with me. You can't remove the risk of solar rays, so you just have to live with it. 0% risk is an unreasonable standard. Certain things have to be outside your execution model, even though they're technically possible. Small small chances of logic errors don't have to be outside your execution model, obviously. But if they're a lot rarer than the errors you have to ignore, then you get no benefit from including them in your execution model. > if you want to make the assumption that secure_rand_u128 will never return 0, then you have to justify that assumption in the context of your specific use case -- it absolutely cannot be assumed in the general case I can agree with this... but my use case is 99.9% of all computing in the year 2023. Normal computers are not reliable enough to measure the difference in error rate of an occasional 1/2^128 chance.