Add Convenience Kernel Arithmetic by Scienfitz · Pull Request #763 · emdgroup/baybe

Scienfitz · 2026-03-12T15:46:34Z

Closes #760
DevPR, parent is #745

~~Rename AdditiveKernel to SumKernel + deprecation + deserialziation hook for compatibility~~
Adds mul, rmul, add, radd operators for BayBE kernels
Ensures flattening of add and mul operatrions, eg SumKernel([SumKernel([a, b]), c]) results in SumKernel([a,b,c])
Multiplication wth a constant will result in a ScaleKernel with the new attribute outputscale_trainable=False which results in it not being affected by training, ie it is constant

Resolve the naming inconsistency between AdditiveKernel and ProductKernel by renaming AdditiveKernel to SumKernel, forming a consistent SumKernel/ProductKernel pair. A deprecation shim is provided so that the old AdditiveKernel name still works but emits a DeprecationWarning.

Add a boolean flag to control whether the output scale parameter is trainable. When set to False, the raw_outputscale parameter is frozen (requires_grad=False) after GPyTorch kernel construction. This enables creating ScaleKernels with fixed output scales, which is needed for the upcoming constant * kernel operator.

Add __add__, __mul__, __radd__, and __rmul__ to the Kernel base class: - kernel + kernel creates a SumKernel - kernel * kernel creates a ProductKernel - kernel * constant / constant * kernel creates a ScaleKernel with a fixed (non-trainable) output scale

Nested sums and products are now flattened: (a + b) + c produces SumKernel([a, b, c]) instead of SumKernel([SumKernel([a, b]), c]), and likewise for ProductKernel. This can be reverted independently while preserving the core operator functionality.

Test suite covering: - Addition operator producing SumKernel with flattening - Multiplication operator producing ProductKernel with flattening - Constant multiplication producing ScaleKernel with frozen outputscale - TypeError for unsupported operand types - AdditiveKernel deprecation warning - Serialization roundtrips for operator-constructed kernels

Replace explicit SumKernel([...]) and ProductKernel([...]) construction in tests with the new + and * operators for more readable kernel composition.

Copilot

Pull request overview

This PR improves BayBE kernel ergonomics by adding operator overloading for kernel composition and aligning composite-kernel naming (AdditiveKernel → SumKernel) with a backwards-compatible deprecation path (including deserialization support).

Changes:

Renames AdditiveKernel to SumKernel, adds deprecation wrapper and a cattrs structure hook to deserialize legacy "type": "AdditiveKernel" configs.
Adds Kernel arithmetic via + and *, including flattening of nested SumKernel/ProductKernel compositions.
Adds constant scaling via constant * kernel / kernel * constant by producing a ScaleKernel with outputscale_trainable=False.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
`baybe/kernels/base.py`	Adds `__add__`/`__mul__` (flattening) and a deserialization hook for legacy `AdditiveKernel` configs; updates gpytorch attribute matching to tolerate `*_trainable`.
`baybe/kernels/composite.py`	Introduces `ScaleKernel.outputscale_trainable` and renames `AdditiveKernel` to `SumKernel`.
`baybe/kernels/deprecation.py`	Adds deprecated `AdditiveKernel` factory that warns and returns `SumKernel`.
`baybe/kernels/__init__.py`	Re-exports `SumKernel` and routes `AdditiveKernel` through the deprecation wrapper.
`tests/test_kernels.py`	Adds unit tests for operator behavior, flattening, and constant scaling; updates gpytorch-component validation to ignore `*_trainable`.
`tests/test_iterations.py`	Updates composite-kernel test inputs to use `+`/`*` composition instead of explicit composite kernel constructors.
`tests/test_gp.py`	Updates GP kernel fixture to use `MaternKernel() + RBFKernel()` composition.
`tests/test_deprecations.py`	Adds coverage for `AdditiveKernel` deprecation warning and legacy-name deserialization.
`tests/hypothesis_strategies/kernels.py`	Switches additive composite strategy to produce `SumKernel`.
`tests/validation/kernels/test_composite_kernel_validation.py`	Updates composite-kernel validation parametrization from `AdditiveKernel` to `SumKernel`.
`CHANGELOG.md`	Documents kernel operator support and the `AdditiveKernel` → `SumKernel` replacement.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

baybe/kernels/deprecation.py

tests/test_kernels.py

baybe/kernels/base.py

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

AdrianSosic

Very good PR, thanks for taking care 🥇 Only a few minor comments

CHANGELOG.md

baybe/kernels/composite.py

baybe/kernels/deprecation.py

AdrianSosic · 2026-03-28T09:23:36Z

baybe/kernels/base.py

+        if isinstance(other, Kernel):
+            return self.__add__(other)


Could it be that these two lines are essentially dead/unneeded code?

you know it could be, it could not be, but to determine that I would need your reasoning.

I have an idea now that you mentioned it here. But why guess if the original thinker could just post their reasoning?

Didn't want to post in order not to bias your thoughts but my reasoning is:

asking for isinstance(other, Kernel) does not make any sense because if other actually were a Kernel, then the __add__ method would have already be called, i.e. __radd__ is only ever called if __add__ yields NotImplemented. So I see no execution path that could ever lead here.

But this is a good example where people get confused quickly, so please let me know if this is wrong.

yes that was also what I was thinkinga bout after your comment so strictly these lines seem to be dead. I haven thought about subclasses, perhaps there is something in there to keep it?

on the other hand I would find it rather weird to have this function not implement the logic for kernels :/

well, it's not weird if you think of it it term of NotImplemented means I have no specialized handling for this case, so leave it for other functions to take over ... which is indeed what it means

https://docs.python.org/3/reference/datamodel.html#object.__radd__

These functions are only called if the operands are of different types, when the left operand does not support the corresponding operation [3], or the right operand’s class is derived from the left operand’s class.

Ok, but does this actually change anything? So if __radd__ is called first in this case and returns NotImplemented, then the regular __add__ is called next, which will take over the job. Thus, again, it would be sufficient to just say even though I'm asked first, I have no special handling, so let the regular process happen

fine for me to add that special treatment, but doenst hat make th special treamtent of 1 in rmul obsolete again?

Yes, it does, thus I removed the condition from __rmul__ now. But: could it be that you replied to the wrong thread? The special case handling was mentioned here. That said, the content of this thread still requires your approval

yes sorry, wrong thread

Re does this change anything: What do you want me to approve? This thread is a request by you.

AVHopp

Only real issue is that one test is missing, but I am sure you can add this :)

baybe/kernels/base.py

AVHopp · 2026-03-30T15:18:13Z

tests/test_kernels.py

    validate_gpytorch_kernel_components(kernel, k, **kwargs)
+
+
+def test_add_produces_sum_kernel():


If I understand it correctly, one of the function is added such that we can use the sum with kernels, correct? If so, then a dedicated test for this is missing as we only use + in all tests.

good suggestion I've added a test now

I have also added the rmul functionality which is required for prod([kernel1, kernel2]) which starts out as 1*kernel1 just like 0+kernel1 in sum([kernel1, kernel2]). This is also tested

This surfaces an incosnistency however: floats multiplied with kernels will wrap a scale kernel with frozen output scale. but this is skipped for the prod case (just doesnt make sense to me and would not be identical to the manual kernel multiplication). In general, we could argue that 0 and 1 should have special meanings in the mul and add which they currently dont (it would revert the need to treat 0 or 1 specially in rmul and radd)

@AdrianSosic should also sign off on this

Could we get around this by enabling the use of sum and prod only for sequences of Kernel objects? I guess that this is the main use case anyway, I do not think people want to have a sum([1, Kernel1, 23, 45, Kernel2]) or similar.

not sure what you mean, but when you write sum([k1, k2]) it will internally call 0 + k1 first

and prod([k1,k2]) will start out as 1*k1

so theres no way to avoid it

Hey @Scienfitz, pls correct me if I'm wrong, but I think this has now become obsolete since adding special treatment is exactly what happened lately, right?

? the test is probably not obsolete

tests/test_kernels.py

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Co-authored-by: AdrianSosic <adrian.sosic@merckgroup.com>

Scienfitz · 2026-03-30T17:46:50Z

@AdrianSosic just in case you've not seen this: this branch was based off of the gp refactor and merges back into it
since this is basically your area perhaps you should merge the PR when you see fit?

CHANGELOG.md

Case is handled when falling back to __mul__

Scienfitz self-assigned this Mar 12, 2026

Scienfitz added the enhancement Expand / change existing functionality label Mar 12, 2026

Scienfitz added 10 commits March 12, 2026 17:39

Rewrite test kernel compositions using arithmetic operators

f74e79a

Replace explicit SumKernel([...]) and ProductKernel([...]) construction in tests with the new + and * operators for more readable kernel composition.

Fix deprecation serialization

b28e256

Update CHANGELOG

305cb04

Simplify test

4766696

Add test to assure frozen output scale is not trained

7bcc328

Scienfitz force-pushed the feature/convenience_kernel_arithmetic branch from f75ad4d to 7bcc328 Compare March 12, 2026 16:44

Scienfitz marked this pull request as ready for review March 12, 2026 16:47

Scienfitz requested review from AVHopp and AdrianSosic as code owners March 12, 2026 16:47

Copilot AI review requested due to automatic review settings March 12, 2026 16:47

Copilot started reviewing on behalf of Scienfitz March 12, 2026 16:47 View session

Copilot AI reviewed Mar 12, 2026

View reviewed changes

baybe/kernels/deprecation.py Outdated Show resolved Hide resolved

tests/test_kernels.py Outdated Show resolved Hide resolved

baybe/kernels/base.py Outdated Show resolved Hide resolved

Update tests/test_kernels.py

d18d87c

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Scienfitz linked an issue Mar 18, 2026 that may be closed by this pull request

Kernel operators and naming #760

Open

Enable builtin sum with kernels

cfd4362

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

AdrianSosic requested changes Mar 28, 2026

View reviewed changes

AVHopp approved these changes Mar 30, 2026

View reviewed changes

Scienfitz and others added 2 commits March 30, 2026 19:18

Make docstring more precise

082f0c3

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Improve docstring

18c07b0

Co-authored-by: AdrianSosic <adrian.sosic@merckgroup.com>

AVHopp reviewed Mar 31, 2026

View reviewed changes

CHANGELOG.md Outdated Show resolved Hide resolved

Scienfitz added 2 commits March 31, 2026 16:51

Revert SumKernel rename

65c7d75

Enable builtin math.prod() with kernels

7907ca8

Scienfitz and others added 3 commits March 31, 2026 16:51

Expand kernel operator tests with sum/prod checks

808a14e

Remove unimportant tests

8947afc

Avoid ScaleKernel wrapping for multiplication with 1

92d53c6

Scienfitz force-pushed the feature/convenience_kernel_arithmetic branch from a8ab4b7 to 92d53c6 Compare March 31, 2026 14:52

Drop unnecessary condition in __rmul__

a769a97

Case is handled when falling back to __mul__

AdrianSosic mentioned this pull request Apr 2, 2026

Beef up GaussianProcessSurrogate #745

Draft

20 tasks

		validate_gpytorch_kernel_components(kernel, k, **kwargs)


		def test_add_produces_sum_kernel():

Conversation

Scienfitz commented Mar 12, 2026 • edited by AdrianSosic Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

AdrianSosic left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AVHopp left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Scienfitz commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Scienfitz commented Mar 12, 2026 •

edited by AdrianSosic

Loading

Scienfitz commented Mar 30, 2026 •

edited

Loading