oorb VS Tidier.jl

Imagine my surprise to see OpenOrb, the standard open source software package for orbit determination and minor planet propagation, on the front page of HackerNews. Its interesting software with a beautiful theoretical basis in Bayesian statistics, and a gnarly Fortran codebase - I can’t wait to see the discussion!

Oh.

It’s one thing to land near a name in use. It is quite another to take it directly!

https://github.com/oorb/oorb

Mostly Python and Fortran. See for example https://github.com/oorb/oorb.

The hardest problems are always the social ones. How do you get uptake of a new method, how do you get funding, how do you politely tell a collaboration they are doing the wrong thing, etc.

But if you mean pure technical stuff - the hardest problem I had to solve was rethinking some of the inner loops of the THOR algorithm. The problem was essentially to speed up a Hough transform in 6D space. Lots of time spent profiling CPU cache timings to get that fast.

btw, there has been a pretty nice effort of reimplementing the tidyverse in julia with https://github.com/TidierOrg/Tidier.jl and it seems to be quite nice to work with, if you were missing that from R at least

Indeed DataFrames.jl isn't and won't be the fastest way to do many things. It makes a lot of trade offs in performance for flexibility. The columns of the dataframe can be any indexable array, so while most examples use 64-bit floating point numbers, strings, and categorical arrays, the nice thing about DataFrames.jl is that using arbitrary precision floats, pointers to binaries, etc. are all fine inside of a DataFrame without any modification. This is compared to things like the Pandas allowed datatypes (https://pbpython.com/pandas_dtypes.html). I'm quite impressed by the DataFrames.jl developers given how they've kept it dynamic yet seem to have achieved pretty good performance. Most of it is smart use of function barriers to avoid the dynamism in the core algorithms. But from that knowledge it's very clear that systems should be able to exist that outperform it even with the same algorithms, in some cases just by tens of nanoseconds but in theory that bump is always there.

In the Julia world the one which optimizes to be fully non-dynamic is TypedTables (https://github.com/JuliaData/TypedTables.jl) where all column types are known at compile time, removing the dynamic dispatch overhead. But in Julia the minor performance gain of using TypedTables vs the major flexibility loss is the reason why you pretty much never hear about it. Probably not even worth mentioning but it's a fun tidbit.

> For what it's worth, data.table is my favourite to use and I believe it has the nicest ergonomics of the three I spoke about.

I would be interested to hear what about the ergonomics of data.table you find useful. if there are some ideas that would be helpful for DataFrames.jl to learn from data.table directly I'd be happy to share it with the devs. Generally when I hear about R people talk about tidyverse. Tidier (https://github.com/TidierOrg/Tidier.jl) is making some big strides in bringing a tidy syntax to Julia and I hear that it has had some rapid adoption and happy users, so there are some ongoing efforts to use the learnings of R API's but I'm not sure if someone is looking directly at the data.table parts.

“Tidier.jl is a 100% Julia implementation of the R tidyverse mini-language in Julia.”

https://github.com/TidierOrg/Tidier.jl

A recent package, Tidier.jl, is coming from a R package developer: https://github.com/kdpsingh/Tidier.jl