&Nidhicodes [ENH] Add support for nn losses to ptf-v2

[Faakhir30]

Reference Issues/PRs

Fixes #1970

What does this implement/fix? Explain your changes.

Followups and stacks on existing PR #2073 by @Nidhicodes

By @Nidhicodes:

• Introduces NNLossAdapter, a lightweight wrapper that adapts nn.Module losses to the ptf-v2 loss/metric API.
• Enables users to pass native PyTorch losses directly to models (e.g. DLinear(loss=nn.MSELoss())) without manual wrapping.
• Ensures compatibility with BaseModel.predict() by implementing to_prediction and to_quantiles.

The adapter:

• Handles (target, weight) inputs by applying weights internally while respecting the loss’s original reduction.
• Supports multi-target predictions by splitting [B, T, N] tensors and summing losses across targets.
• Enforces point-prediction-only usage (H=1) for losses that are not horizon-aware, with clear error messages otherwise.

Further updates:

• store in self._loss instead of self.loss
• merge main
• integration tests with models
• fix for tide and other models where needed
• add support for non-point losses

What should a reviewer concentrate their feedback on?

Did you add any tests for the change?

Any other comments?

PR checklist

• The PR title starts with either [ENH], [MNT], [DOC], or [BUG]. [BUG] - bugfix, [MNT] - CI, test framework, [ENH] - adding or improving code, [DOC] - writing or improving documentation or docstrings.
• Added/modified tests
• Used pre-commit hooks when committing to ensure that code is compliant with hooks. Install hooks with pre-commit install.
  To run hooks independent of commit, execute pre-commit run --all-files

[codecov]

Codecov Report

❌ Patch coverage is 96.58703% with 10 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (main@033169a). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
pytorch_forecasting/metrics/nn_loss_adapter.py	91.39%	8 Missing ⚠️
pytorch_forecasting/tests/test_nn_loss_adapter.py	98.91%	2 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2331   +/-   ##
=======================================
  Coverage        ?   87.71%           
=======================================
  Files           ?      177           
  Lines           ?    10450           
  Branches        ?        0           
=======================================
  Hits            ?     9166           
  Misses          ?     1284           
  Partials        ?        0           

Flag	Coverage Δ
cpu	87.71% <96.58%> (?)
pytest	87.71% <96.58%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[phoeenniixx]

Can we try this adpater with some already implemented methods (optimally all of them, but that is hard, ig we need to update our test framework so that it loops over the losses like we do for v1)

[Faakhir30]

Can we try this adpater with some already implemented methods (optimally all of them

I think you are referring to get_test_train_params?

, but that is hard, ig we need to update our test framework so that it loops over the losses like we do for v1

v1 has info:pred_type tag that lets us get right metric/loss objects and them loop over them, I see that most v2 model pkgs are not specifying this tag (though the extension template suggests to add), looks intentional?

Even if I add that tag, are you suggesting to maintain all set of nn.losses like we had sets of metrics at _loss_mapping and fetch compatible ones, and loop over them for each model?
That would mean: num_of_nn_losses x len(get_test_train_params()) fixtures for each model_pkg.

I think it'll be better to just add a few nn losses to each get_test_train_params.

[phoeenniixx]

Sorry I meant models, not methods

[phoeenniixx]

Can you please add docstrings in the adapter - without it, it is hard to review!
Also, what if a user uses this: loss = Multiloss([MAPE,nn.MSELoss])?
Should we add some way so that if we are even using a ptf loss with nn loss, this should work

[Faakhir30]

Also, what if a user uses this: loss = Multiloss([MAPE,nn.MSELoss])?
Should we add some way so that if we are even using a ptf loss with nn loss, this should work

Ahh, I did think about this at start,
above call of Multiloss([MAPE,nn.MSELoss]) suggests that multiloss should internally pass nn loss via adapter.

I was thinking if instead of taking this adapter's base from nn.Module and handling in metrics then, we base it from MultiHorizonMetric.
I do somewhat foresee the challanges it'll create, wrapping a stateless thing in a statefull metric API might be tough.

But that design automatically makes a nn loss interchangeable with any Metric losses without much friction.
User should be able to call Metric.from_nn_loss(nn.MSELoss) at anywhere a Metric is supported.

I should have shared this intuition in PR description as alternative before ;) I did not point out initially, because on @Nidhicodes PR, I dont see any maintainers comment pointing above problem. Is there something I'm missing? is there some major issue with Metric approach?

[phoeenniixx]

sorry, I dont exactly understand what your question is here, can you please rephrase it?

[Faakhir30]

sorry, I dont exactly understand what your question is here, can you please rephrase it?

I was suggesting an alternative design.

Design alternative I'm inclined towards: instead of class NNLossAdapter(nn.Module), make it a real ptf metric, e.g. class NNLossAdapter(MultiHorizonMetric)

Question:
is there a strong reason to keep the adapter as a plain nn.Module, or treating nn losses as a first-class Metric route also viable?

I have pushed this newer design in a single commit for review, we can revert back to keeping adapter a nn.Module if needed.

[phoeenniixx]

Added some comments

• Please use if-else rather than multiple if statements if possible. This is not only useful to prevent looking at unnecessary if statements but also makes it clear for the reader that the statement below is related to the above if and not a totally different condition. In short, makes it easier to understand code