DearPy3D VS awkward

Dear PyGui is awesome and supports creating node editors. 3D is not really supported yet (although matrix functions are), but future versions will support 3D. The core developers are very much interested in 3D rendering. As a little test, Hoffstadt created DearPy3D. He is currently working on Pilotlight, which is still early stages and eventually will be the core of Dear PyGui version 3.

Just a quick update since then is that Dear PyGui has reached version 1.0 and the API is now stable with a proper deprecation policy. Additional features include support for extremely dynamic tables, became faster still, introduction of the first steps into 3D and drawing transformations, support for multiple fonts, node editor and many small improvements and bug fixes. There are still many ideas for future development, including more 3D.

With regard to 3D, are you aware of DearPy3D by the same developers (still under development, also available under the MIT license)?

hoffstadt/Marvel: Dear PyGui 3D Engine (early development) (github.com)

there's a whole ecosystem in Python originally developed for high energy physics data processing: https://github.com/scikit-hep/awkward all because Numpy demands square N-dimensional array

Same technique used everywhere, here's a simple Julia pkg for the same thing: https://github.com/JuliaArrays/ArraysOfArrays.jl/blob/3a6f5b...

But Julia at least has the decency to just support ragged Vector{Vector} out of the box, and it's not that slow

Awkward Array.

Numba's @vectorize decorator (https://numba.pydata.org/numba-doc/latest/user/vectorize.htm...) makes a ufunc, and Awkward Array knows how to implicitly map ufuncs. (It is necessary to specify the signature in the @vectorize argument; otherwise, it won't be a true ufunc and Awkward won't recognize it.)

When Numba's JIT encounters a ctypes function, it goes to the ABI source and inserts a function pointer in the LLVM IR that it's generating. Unfortunately, that means that there is function-pointer indirection on each call, and whether that matters depends on how long-running the function is. If you mean that your assembly function is 0.1 ns per call or something, then yes, that function-pointer indirection is going to be the bottleneck. If you mean that your assembly function is 1 μs per call and that's fast, given what it does, then I think it would be alright.

If you need to remove the function-pointer indirection and still run on Awkward Arrays, there are other things we can do, but they're more involved. Ping me in a GitHub Issue or Discussion on https://github.com/scikit-hep/awkward-1.0