Bump torch from 1.13.1+cpu to 2.2.0 in /src/stirling/protocol_inference

[dependabot[bot]]

Bumps torch from 1.13.1+cpu to 2.2.0.

Release notes

Sourced from torch's releases.

PyTorch 2.2: FlashAttention-v2, AOTInductor

PyTorch 2.2 Release Notes

• Highlights
• Backwards Incompatible Changes
• Deprecations
• New Features
• Improvements
• Bug fixes
• Performance
• Documentation

Highlights

We are excited to announce the release of PyTorch® 2.2! PyTorch 2.2 offers ~2x performance improvements to scaled_dot_product_attention via FlashAttention-v2 integration, as well as AOTInductor, a new ahead-of-time compilation and deployment tool built for non-python server-side deployments.

This release also includes improved torch.compile support for Optimizers, a number of new inductor optimizations, and a new logging mechanism called TORCH_LOGS.

Please note that we are deprecating macOS x86 support, and PyTorch 2.2.x will be the last version that supports macOS x64.

Along with 2.2, we are also releasing a series of updates to the PyTorch domain libraries. More details can be found in the library updates blog.

This release is composed of 3,628 commits and 521 contributors since PyTorch 2.1. We want to sincerely thank our dedicated community for your contributions. As always, we encourage you to try these out and report any issues as we improve 2.2. More information about how to get started with the PyTorch 2-series can be found at our Getting Started page.

Summary:

• scaled_dot_product_attention (SDPA) now supports FlashAttention-2, yielding around 2x speedups compared to previous versions.
• PyTorch 2.2 introduces a new ahead-of-time extension of TorchInductor called AOTInductor, designed to compile and deploy PyTorch programs for non-python server-side.
• torch.distributed supports a new abstraction for initializing and representing ProcessGroups called device_mesh.
• PyTorch 2.2 ships a standardized, configurable logging mechanism called TORCH_LOGS.
• A number of torch.compile improvements are included in PyTorch 2.2, including improved support for compiling Optimizers and improved TorchInductor fusion and layout optimizations.
• Please note that we are deprecating macOS x86 support, and PyTorch 2.2.x will be the last version that supports macOS x64.
• torch.ao.quantization now offers a prototype torch.export based flow

... (truncated)

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the Security Alerts page.

[janezd]

Other visualizations include the name of the variable as a part of the plot, e.g. the name of the axis, never as a title. (If you find such case, tell me and I'll fix it. :) Hence I'd vote against putting the name at the top.

A solution consistent with other widgets would be to label the axis.

I prepared a PR (#6882), but I don't like it much because the user knows which attribute he is plotting - when using Orange. Preparing a plot for publication would, in my opinion, always require a touch of Inkscape, Illustrator or, if I may suggest, Affinity Designer.

You may argue that I could use the same argument against showing variable names in scatter plot, sieve and mosaic. Yes, but there it at least (re)shows what is shown horizontally and what is shown vertically (not to mention having four variables in mosaic), while here I think the ink-to-information ratio is low.

[markotoplak]

I think adding a feature name helps if you want to observe multiple widgets at the same time and thus, to save screen estate, you hide control panes. I often do this in workshops. Having no name there can be problematic.

What bothers me more is the positioning of the score. Even if we decide not to merge this PR, it should go away from the value axis, like to the top. Having it near the axis is confusing.

[janezd]

Left-align the ANOVA line.

[janezd]

OK?