proposal for user choice of packages

Follow on from #106

After discussing with @gbaydin today my proposal is that we remove the DiffSharp pacakge and have these three “top-level-entry-point” packages:

• package DiffSharp-torch-cpu (references DiffSharp.Core, DiffSharp.Backends.Torch, libtorch-cpu)

• package DiffSharp-torch-cuda-10.2-win-x64 (references DiffSharp.Core, DiffSharp.Backends.Torch, libtorch-cuda-10.2 for windows)

• package DiffSharp-torch-cuda-10.2-linux-x64 (references DiffSharp.Core, DiffSharp.Backends.Torch, libtorch-cuda-10.2 for linux)

If we have other backends that are high quality and fully feature-complete and tested we can add those too.

With this, the user on a Jupyter notebook simply references one of these and a version number, e.g.

#r "nuget: DiffSharp-torch-cpu, 1.0.3"

That’s a nice and simple choice isn’t it?

Note we really have to split windows/linux Cuda packages here because the downloads are v. large.

Note I haven’t listed an accumulation package for the reference backend. I think people wanting to use the reference backend are likely to be building new DiffSharp library components (e.g. derived algorithms) or extensions (new backends etc.) and should reference the individual packages they need. For example they reference DiffSharp.Core in their library project and DIffSharp.Backend.Reference in their test project (and a few more packages if they want to test on Torch). That actually gives a really nice, light experience for creating a library project that adds some stuff to DiffSharp - no need to download anything Torch related if you’re happy to trust the reference backend for testing.

Aside : With this, the user gets whatever is the latest version of Torch the TorchSharp we depend on happens to work on. In some far future I could see people wanting to vary the Torch between two or three recent versions, so you can imagine this

• package DiffSharp-torch-1.5-cpu
• package DiffSharp-torch-1.6-cpu
• package DiffSharp-torch-1.5-cuda-10.2-linux-x64
• package DiffSharp-torch-1.6-cuda-10.3-linux-x64

etc. It’s an interesting question which of these the user is most likely to want to vary on. (and will they want to use nightly or modified or patched versions of Torch? That would be hard…)

[dsyme]

Perhaps one solution is: if we commit to the choice of libtorch raw tensors as the main backend…

This would likely be fine for now, though I’m aware an ONNX Runtime backed is of real interest. I guess that could add the name ‘-onnx-’. It would be nice not to bake this in any further than the surface user experience in application scripts.

Separately, there is also the question of what the default backend is once packages are referenced. Today the default backend is always Reference. It obviously sucks to always do

dsharp.zeros(backend=Torch)

I suppose option A might allow us to set the default backend automagically on package reference (I’m not sure how, but I guess it could happen - it would have to be setting a global or adjusting the default backend detection logic). Alternatively the programmer needs one of these:

1. require

   let dsharp = DiffSharp.Configure(backend=Torch)
   

2. set a global

   DiffSharp.Configure(backend=Torch)
   

I guess in practice we’ll just set a global and adjust the default logic to “do the right thing”, and report it to the user.

[dsyme]

Closing as this has been implemented