Polyester.jl VS icontract-hypothesis

This is a new stiff ODE solver which uses multi-threading within the method to make the solve of single ODEs faster in cases where it's too small to benefit from implicit threading in BLAS. Uses Polyester mixed with a very specific adaptivity method to optimize the work calculation to hit this performance. And of note, it's the type of manual parallel algorithm that cannot use array-based parallelism offered by machine learning libraries, so it's an algorithm you kind of need to implement in C++ or... Julia! Was a fun multi-year project and am really glad to see it completed.

The Folds.jl [1] package mentioned in the article is very nicely written.

For another alternative to Julia's built-in `Threads.@threads` macro, folks may also be interested in checking out `@batch` from Polyester.jl [2] (formerly CheapThreads.jl), which features particularly low-overhead threading.

[1] https://github.com/JuliaFolds/Folds.jl

[2] https://github.com/JuliaSIMD/Polyester.jl

https://github.com/mristin/icontract-hypothesis

Nagini and deal-solver attempt to Formally Verify Python code with or without unit tests: https://news.ycombinator.com/item?id=39139198

Additional research:

"Fuzz target generation using LLMs" (2023)

https://icontract.readthedocs.io/en/latest/usage.html#invari...

For unit testing, there's icontract-hypothesis; with the Preconditions and Postconditions delineated by e.g. decorators, it's possible to generate many of the fuzz tests from the additional Design by Contract structure of the source.

From https://github.com/mristin/icontract-hypothesis :

> icontract-hypothesis combines design-by-contract with automatic testing.

> It is an integration between icontract library for design-by-contract and Hypothesis library for property-based testing.

> The result is a powerful combination that allows you to automatically test your code. Instead of writing manually the Hypothesis search strategies for a function, icontract-hypothesis infers them based on the function’s [sic] precondition

Just in case you are looking for an alternative approach: if you write contracts in your code, you might also consider crosshair [1] or icontract-hypothesis [2]. If your function/method does not need any pre-conditions then the the type annotations can be directly used.

(I'm one of the authors of icontract-hypothesis.)

[1] https://github.com/pschanely/CrossHair

[2] https://github.com/mristin/icontract-hypothesis