3 ms·

i'm not sure what to say to this -- my question was rhetorical your position is incompatible with deterministic program execution -- it's unsound (shrug)

Dylan16807 3y ago
It reads as rhetorical. But it was also a bit of a strawman. Sometimes dismantling a rhetorical question makes sense to do. The answer to your rhetorical question was an obvious no, but it also wasn't relevant to my argument because you used such a high probability. Deterministic program execution is an assumption we make even though it's not 100% true. Soundness, when it comes to computer programs, isn't real.
- preseinger 3y ago
  the specific probability was irrelevant
  - xigoi 3y ago
    The specific probability is relevant. 2^-256 is practically impossible, 10^-4 is not.
    - preseinger 3y ago
      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

It reads as rhetorical. But it was also a bit of a strawman. Sometimes dismantling a rhetorical question makes sense to do. The answer to your rhetorical question was an obvious no, but it also wasn't relevant to my argument because you used such a high probability. Deterministic program execution is an assumption we make even though it's not 100% true. Soundness, when it comes to computer programs, isn't real.

preseinger 3y ago
the specific probability was irrelevant
- xigoi 3y ago
  The specific probability is relevant. 2^-256 is practically impossible, 10^-4 is not.
  - preseinger 3y ago
    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?