From "Building cython extensions using only pyproject.toml (no setup.py)" https://github.com/pypa/setuptools/discussions/4154#discussi... :
[build-system]
requires = ["setuptools", "cython"]
[tool.setuptools]
ext-modules = [
{name = "example", sources = ["example.pyx"]} # You can also specify all the usual options like language or include_dirs
]Nothing wrong with that as a starting point of course, but it's easier just to compile it as a dependency and look at the core documentation if you're familiar with C++; you'll need to be reading the C++ examples anyway to write Rust code with it.
So if you wanted to write a Python Physics library that included, say, time integration with an implicit solver like those SUNDIALS provides (and SUNDIALS is like the gold standard in this area), you have less well used options for the time integration part if you write the extension in Rust as if you do in C/C++. Or you're using the same library anyway.
> Narwhals: https://narwhals-dev.github.io/narwhals/ :
>> Extremely lightweight compatibility layer between [pandas, Polars, cuDF, Modin]
> Lancedb/lance works with [Pandas, DuckDB, Polars, Pyarrow,]; https://github.com/lancedb/lance
SymPy has Solvers for ODEs and PDEs and other libraries do convex optimization. SymPy also has lambdify to compile from a relatively slow symbolic expression tree to faster 'vectorized' functions
From https://news.ycombinator.com/item?id=40683777 re: warp :
> sympy.utilities.lambdify.lambdify() https://github.com/sympy/sympy/blob/master/sympy/utilities/l... :
>>> """Convert a SymPy expression into a function that allows for fast numeric evaluation""" [with e.g. the CPython math module, mpmath, NumPy, SciPy, CuPy, JAX, TensorFlow, PyTorch (*), SymPy, numexpr, but not yet cmath]
scikits.odes supports CVODE: scikits.odes.sundials.cvode: https://bmcage.github.io/odes/master/api/compat.html#module-....
sckits.odes docs > Choosing a Solver: https://scikits-odes.readthedocs.io/en/latest/solvers.html
scipy.integrate.solve_ivp has Radau, BDF, and LSODA for stiff ODEs, in Python: https://docs.scipy.org/doc/scipy/reference/generated/scipy.i...
If you add Arrow RecordBatch or Table output to CVODE with arrow-cpp, e.g. Dask can zero-copy buffers to Python (pyarrow, pandas.DataFrame(dtype_backend=arrow), or narwhals) when it needs to gather / fan in at a computational barrier in a process-parallel workflow.
Is sklearn-deap useful with scikits.odes and sundials (and dask or not)?
We are heavily leaning on Julia, and to my mind Mojo is a major threat to the long term development of the Julia community. If people dissatisfied with Python+C(++)-Silos end up writing Mojo instead of Julia it will become even harder to grow the ecosystem and community.
That said, for now Julia has a number of big strengths for scientific work that don't seem to be in the focus of the Mojo devs...
Mojo has 3 disadvantages compared to Julia:
1) The core team is focused on the Linux+servers+AI combination, because that's where the money is.
2) Less composability due to the lack of multiple dispatch.
3) The license.
I like the language, but as I do ML, Python is really the only game in town, and Mojo is looking promising.
lolwut
py2many --mojo=1 dbscan_inner.py
If it's something you need to put in production soon, C++/pybind might be the way to go, but if it's just a side-project, Mojo could work.
Only if you want to lose access to Windows users, as it is a low priority for Mojo development.
We spent decades getting out of the clutches of Mathworks, Microsoft, etc. Why are people eager to go back that way?
The licence is a bit weird to me though. I do get it for their main product, Max, but it is a bit of a weird one for a language.
Firefox on Android with NoScript.
I just use Quarto to create a static site, but I am also very clueless about web stuff.