New space and limit behavior #533
jonas-eschle
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Limits of spaces: too powerful, too unintuitive, too complicated
TL;DR: skip to the migration guide
The limits of spaces have been one of the most unintuitive things in zfit: they have a dimension more than naively expected.
This has history and complexity: spaces can not only be multidimensional, they can also have multiple, disconnected limits and are today sophisticade objects. That's why
Space.limit
,lower
andupper
attributes return an additional dimension: one for the observables, one for the "multiple limits". Too sophisticade for too little gain: The same can be achieved with a TruncatedPDF that solves all the (expected) use-cases.There is even the possibility to have arbitrary bounds, and specify them in a
limit_function
, a callable. To distinguish and make sure that it is called, therect_limits
were introduced.And this again can easily be achieved by zeroing a region in the PDF (custom pdfs are easy enough).
Too much sophistication, way too much.
New limits
The new limits will have one dimension less, making them more intuitive:
limits
will return a tuple of one dimensional arrays, each dimension corresponding to one observable.lower
andupper
will return a one dimensional array for each observable.Breaking changes
These changes will break code. Unfortunately, the names are good, the behavior isn't. To make the transition as smooth as possible, the following compatibility layer is available.
To stay compatible and not experience breaking changes, use
Space.v1.limits
,Space.v1.lower
andSpace.v1.upper
for the future behavior, or useSpace.v0.limits
,Space.v0.lower
andSpace.v0.upper
to keep the current behavior (discouraged).Once 1.0 is release, v0 will start to be deprecated, however, v0 and v1 will stay around for a long enough time to make sure that code is compatible in both the 0.x and 1.x version
MultiSpaces will be removed with 1.0 if all use-cases are satisfied.
Removing other limits
As the same behavior is true for the
rect_limits
,rect_lower
andrect_upper
, these are discouraged in favor of the normal ones, i.e.v1.limits
,v1.lower
,v1.upper
.limit1d
will not (yet) be deprecatedarea()
method becomesvolume
propertyThe method
area()
is deprecated and instead replaced by the property (no call with(...)
needed!)volume
.Labels
Many objects receive labels instead of names only. This has implications for the Space mostly: each space (one dim) carries a label that defaults to the
obs
. If a multidimensional Space is built, this has a label for each obs, i.e. n obs -> n labels. The labels are free strings that help the description of the object and can be used for plotting etc, whileobs
is the identification string and has logical meaning in the fitting workflow.Advanced, vectorized limits
Limits will be able to be vectorized. This is usually not needed to implement explicitly, but for generality, a vectorized version of
lower
,upper
,limits
andvolume
, that is values of shape (nevents, nobs) instead of (nobs), can be accessed via theSpace.vec.lower
etc. attributeMigration guide
In short: use
v0.
for full compatibility (but will be removed at some point), use v1 with new behavior for an easier usage of limits..area()
withvolume
(area
is, whithin zfit, unique)lower
,upper
(of spaces, not Parameters!) withv1.lower
, v1.upperif the following code simply removes the first dimension, i.e.
lower = space.lower[0]`v0.lower
, v0.upper` if it is more complicated (very rarely the case, should not be needed! only with MultiSpace).limits
: here, follow the same way withlower
andupper
but instead, if it looks likev1.limits
.v0.limits
Beta Was this translation helpful? Give feedback.
All reactions