Suggestion: Add DLL for windows compiling

[Jerry-Master]

To simplify your installation process you could just add a DLL to the build directory and change the 10th line of your files to pluginpath = os.path.join(parent, "../build/Release/fusedFourierKAN.dll") I have done that with visual studio 2019 and nvcc version 11.2 and it all runs fine when using the cuda version 11.8 installation of pytorch 2.

[unrealwill]

@Jerry-Master thanks for getting it to work on windows, I don't own any windows license so I am not able to test.

I'll add your suggestion to the readme.txt so that it may help other windows user.

I'm not quite sure how to make a truly cross-platform solution to load the proper library. In particular the "Release" in the path, is probably compiler dependent, so a simple is_windows() and selecting the appropriate pluginpath, may work for visual studio users, but not g++ users on windows.

The official pytorch tutorial I followed https://pytorch.org/tutorials/advanced/torch_script_custom_ops.html is linux only.

I'll give it a think.

[Jerry-Master]

This is the official tutorial that appeared to me when googling. You can check my repo if you want for comparison. Now to compile you can just do pip install .. I think that is much simpler, since you only need a working nvcc version and nothing else. Also, from the official tutorial I mentioned, using PackedAccessors facilitate the reading of the code, since the indices are just like in python, with no performance overhead. However, the CPU version does seem to have a lot of overhead when using accessors. If I gather more info I may submit an issue to pytorch.

[unrealwill]

@Jerry-Master Thanks ! Great code, I'm learning a few things :)

Here's my rationale for my convoluted structure :

• Uncoupling pytorch : Using a separate inner library that doesn't use pytorch allows to port easily to multiple platform like web and embedded ; it's along the wave of all these ".c/.cpp" projects ; I've been burned previously writing tensorflow customops, pytorch is pushing their triton language, ML frameworks of the day updates and API changes every 6 months or so
• Faster compilation time during development : because there is no dependency of pytorch, it allows to compile very fast not interrupting the flow of development.
• Stride loops : I like their symmetric structure. Compare to the PackedAccessors, the advantage is that I can reorder the loops and data layout much more easily : Just change the strides at the one place in code where it has been defined. Whereas PackedAccessors have to manually reorder the indices everywhere they are accessed which is very error-prone. In particular, it allows for easier search for optimal loop order, to optimize for things like coalesced memory access.
• loops optimizations : stride loops can be manually optimized to be iterated with pointer arithmetic using almost only additions.
• Using raw pointers instead of PackedAccessors allows to easily access subtensors of tensors. (But doing so make data layout reordering harder).
• Automatic differentiation : with barebones ops, you can use autodiff frameworks to check your adjoint code.