Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

proposal for user choice of packages

See original GitHub issue

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…)

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:10 (5 by maintainers)

github_iconTop GitHub Comments

dsymecommented, May 23, 2020

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


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


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.

dsymecommented, Jun 4, 2020

Closing as this has been implemented

Read more comments on GitHub >

github_iconTop Results From Across the Web

Give your clients greater choice with proposal options
Building a proposal with various pricing options is super quick - just give your proposal option a name and description, duplicate it and ......
Read more >
How Many Options To Include In Your Consulting Proposal?
Limiting your options is the key, and developing packages based on outcomes and value is what you should strive for. What's the right...
Read more >
29 Sample Proposal Templates and Design Tips
Here's a short selection of 8 easy-to-edit Proposal templates you can edit, share and download with Visme. View more below:.
Read more >
The Price Proposal That Won't Scare Customers Away ...
This proposal does a great job conveying your value, expertise, and competency, which is far more appealing than a spreadsheet of numbers. 3....
Read more >
Require a package on a proposal
How to Require a Package on a Proposal. Choose the proposal to edit under Templates >> Forms. Click on the specific package that...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found