3 ms·

> For scientific simulations, I almost always want invalid state to immediately result in a program crash. If you have actually made invalid states unrepresent

> For scientific simulations, I almost always want invalid state to immediately result in a program crash. If you have actually made invalid states unrepresentable, then it is _impossible_ for your program to transition into an invalid state at runtime. Otherwise, you're just talking about failing fast

cherryteastain 1y ago
> _impossible_ for your program to transition into an invalid state at runtime Not the case for scientific computing/HPC. Often HPC codebases will use numerical schemes which are mathematically proven to 'blow up' (produce infs/nans) under certain conditions even with a perfect implementation - see for instance the CFL condition [1]. The solution to that is typically changing to a numerical scheme more suited for your problem or tweaking the current scheme's parameters (temporal step size, mesh, formula coefficients...). It is not trivial to find what the correct settings will be before starting. Encountering situations like a job which runs fine for 2 days and then suddenly blows up is not particularly rare. [1] https://en.m.wikipedia.org/wiki/Courant%E2%80%93Friedrichs%E2%80%93Lewy_condition https://en.m.wikipedia.org/wiki/Courant%E2%80%93Friedrichs%E...
- ux266478 1y ago
  In those situations, the functions that contain a singularity should return an Either monad, and in order to bring the resulting data back into the bloodstream of the program, you have to deal with that potential singularity. Unfortunately, scientific computing seems like it's stuck in the age of the dinosaurs with tooling choices and much of the advancements in type systems of the last 40 years are nowhere to be seen. I always found that curious, given its adjacency to academia.
  - bccdee 1y ago
    Why? You're just going to unwrap that monad and promptly crash. It's unrecoverable; it doesn't need to go back into "the bloodstream of the program." No amount of static typing will turn this runtime error into a compile-time error, so it doesn't really matter how you express it with types.
    - ux266478 1y ago
      > You're just going to unwrap that monad and promptly crash. It's unrecoverable You handle the error gracefully. It's not "unrecoverable" in the sense of an incorrect memory read that arises from a logic error in the program. It's an anticipatable behavior in a well-defined system of computations that should be treated as such. Simply crashing is extremely sloppy programming in this case, it's not a formal equivalent to discarding an unusable input. > No amount of static typing will turn this runtime error into a compile-time error On the contrary. Anything capable of statically checking dependent types can turn any runtime issue into a compile-time issue. Up to and including requiring proof that a function's domain is respected according to all paths that call it as a facet of the type system, and this domain can be inferred by the operations within the function itself.
      - bccdee 1y ago
        > Up to and including requiring proof that a function's domain is respected Does such a proof exist in this context? Or are we writing fanfiction about the problem domain now? > It's not "unrecoverable" Yes it is. The correct behaviour in that context is to terminate the program, which makes it unrecoverable.
        ux266478 1y ago
        > Does such a proof exist in this context? Or are we writing fanfiction about the problem domain now? "Often HPC codebases will use numerical schemes which are mathematically proven to 'blow up' (produce infs/nans) under certain conditions even with a perfect implementation" Yes? Function domains are trivially enforceable through the type system when you have dependent types. Even the n-dimensional case of the CFL condition is a simple constraint you can express over a type. Have you ever actually done any work with dependent types? I'm not sure why you would think something so basic as enforcing a function domain (which isn't the same thing as a problem domain, by the way) would be "fanfiction" otherwise. I highly recommend spending a few months actually working with them, there are plenty of good languages floating around these days. > The correct behaviour in that context is to terminate the program At worst it's to leave the thread of execution, which is distinct from crashing, as you asserted above and as my core point revolves around.

cherryteastain 1y ago

> _impossible_ for your program to transition into an invalid state at runtime Not the case for scientific computing/HPC. Often HPC codebases will use numerical schemes which are mathematically proven to 'blow up' (produce infs/nans) under certain conditions even with a perfect implementation - see for instance the CFL condition [1]. The solution to that is typically changing to a numerical scheme more suited for your problem or tweaking the current scheme's parameters (temporal step size, mesh, formula coefficients...). It is not trivial to find what the correct settings will be before starting. Encountering situations like a job which runs fine for 2 days and then suddenly blows up is not particularly rare. [1] https://en.m.wikipedia.org/wiki/Courant%E2%80%93Friedrichs%E2%80%93Lewy_condition https://en.m.wikipedia.org/wiki/Courant%E2%80%93Friedrichs%E...

ux266478 1y ago
In those situations, the functions that contain a singularity should return an Either monad, and in order to bring the resulting data back into the bloodstream of the program, you have to deal with that potential singularity. Unfortunately, scientific computing seems like it's stuck in the age of the dinosaurs with tooling choices and much of the advancements in type systems of the last 40 years are nowhere to be seen. I always found that curious, given its adjacency to academia.
- bccdee 1y ago
  Why? You're just going to unwrap that monad and promptly crash. It's unrecoverable; it doesn't need to go back into "the bloodstream of the program." No amount of static typing will turn this runtime error into a compile-time error, so it doesn't really matter how you express it with types.
  - ux266478 1y ago
    > You're just going to unwrap that monad and promptly crash. It's unrecoverable You handle the error gracefully. It's not "unrecoverable" in the sense of an incorrect memory read that arises from a logic error in the program. It's an anticipatable behavior in a well-defined system of computations that should be treated as such. Simply crashing is extremely sloppy programming in this case, it's not a formal equivalent to discarding an unusable input. > No amount of static typing will turn this runtime error into a compile-time error On the contrary. Anything capable of statically checking dependent types can turn any runtime issue into a compile-time issue. Up to and including requiring proof that a function's domain is respected according to all paths that call it as a facet of the type system, and this domain can be inferred by the operations within the function itself.
    - bccdee 1y ago
      > Up to and including requiring proof that a function's domain is respected Does such a proof exist in this context? Or are we writing fanfiction about the problem domain now? > It's not "unrecoverable" Yes it is. The correct behaviour in that context is to terminate the program, which makes it unrecoverable.
      - ux266478 1y ago
        > Does such a proof exist in this context? Or are we writing fanfiction about the problem domain now? "Often HPC codebases will use numerical schemes which are mathematically proven to 'blow up' (produce infs/nans) under certain conditions even with a perfect implementation" Yes? Function domains are trivially enforceable through the type system when you have dependent types. Even the n-dimensional case of the CFL condition is a simple constraint you can express over a type. Have you ever actually done any work with dependent types? I'm not sure why you would think something so basic as enforcing a function domain (which isn't the same thing as a problem domain, by the way) would be "fanfiction" otherwise. I highly recommend spending a few months actually working with them, there are plenty of good languages floating around these days. > The correct behaviour in that context is to terminate the program At worst it's to leave the thread of execution, which is distinct from crashing, as you asserted above and as my core point revolves around.