Skip to content
This repository has been archived by the owner on Oct 11, 2021. It is now read-only.

Remove Type from FitParameters #397

Closed
spflueger opened this issue Nov 26, 2020 · 1 comment · Fixed by #430
Closed

Remove Type from FitParameters #397

spflueger opened this issue Nov 26, 2020 · 1 comment · Fixed by #430
Labels
🔨 Maintenance Refactoring that doesn't affect the interface ❔ Question Discuss this matter in the team

Comments

@spflueger
Copy link
Member

Currently there is a Type attribute attached to FitParameters in the AmplitudeModel. These are remnants of the old c++ code and it should verified if there is any merit in keeping them.

A type could be useful for definition of a complex valued Parameter: Magnitude + Phase or Real + Imaginary (see ComPWA/tensorwaves#161)

@spflueger spflueger added ❔ Question Discuss this matter in the team 🔨 Maintenance Refactoring that doesn't affect the interface labels Nov 26, 2020
redeboer added a commit that referenced this issue Jan 10, 2021
redeboer added a commit that referenced this issue Jan 10, 2021
@redeboer
Copy link
Member

A type could be useful for definition of a complex valued Parameter: Magnitude + Phase or Real + Imaginary (see ComPWA/tensorwaves#161)

This can be handled more easily when #384 is through. One can then start to define different types of FitParameter as attr.s classes with an inheritance hierarchy similar to the dynamics. With attr.asdict it's then easy to dump those FitParameter to a dict and add a "type": <class name>, just like is done for Dynamics classes.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
🔨 Maintenance Refactoring that doesn't affect the interface ❔ Question Discuss this matter in the team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants