NLL Terms #8
NLL Terms #8
Conversation
Also changes the K-matrix benchmark to collect more samples
This allows `Evaluator` and `NLL` to be safely cloned without duplicating precomputed data, which is just really nice in general but also lets us copy them around as likelihood terms. The way it's currently implement doesn't seem to change performance.
7000 evals takes too long, let's just shoot for 30 seconds
`LikelihoodTerm`s can be registered in a `LikelihoodManager` just like `Amplitude`s get registered in `Manager`s. The registration returns a `LikelihoodID`, which behaves the same way as an `AmplitudeID` and can be added or multiplied with other `LiklihoodExpression`s. These `LikelihoodExpression`s can then be loaded by the `LikelihoodManager` to create a `LikelihoodEvaluator` which can be minimized in the same way as an `NLL`. Since this is an extended implementation, we also keep the minimization method for `NLL`, since not all `LikelihoodTerm`s *should* be minimized.
I honestly don't think the measurement time does anything, maybe it takes the maximum of either of these settings?
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #8 +/- ##
==========================================
- Coverage 12.69% 10.36% -2.33%
==========================================
Files 14 15 +1
Lines 3213 3935 +722
Branches 3213 3935 +722
==========================================
Hits 408 408
- Misses 2805 3527 +722 ☔ View full report in Codecov by Sentry. |
Benchmark for 545d5f8Click to view benchmark
|
Benchmark for 1fce241Click to view benchmark
|
Benchmark for 5370a2cClick to view benchmark
|
Benchmark for 6d37313Click to view benchmark
|
|
This is a huge step forward in terms of efficiency. Since gradient-requiring methods like the L-BFGS-B optimizer spend a lot of time calculating gradients, any improvement in the speed of this calculation is greatly beneficial. The gradient commit (6af103d) does this in a very easy-to-use way for end users. First, However, we can be a bit clever here. Since there are only a few ways we allow users to operate on In summary, if you don't implement a gradient for an In my own tests, this speeds up the |
…m_amptools` method in the main python package Now users can either convert files via the command line `amptools-to-laddu` script installed automatically with `laddu` or via the function `laddu.convert_from_amptools` directly in their Python code. This greatly simplifies the pipeline for using `AmpTools`-formated data in `laddu` without much additional effort for users (and hopefully aids in adoption)
Benchmark for 092c0eaClick to view benchmark
|
…thon API for `NLL` and add method to turn an `NLL` into a `LikelihoodTerm`
…e the same length Previously, if two `LikelihoodTerm`s had a different number or layout of parameters, the gradients wouldn't be compatible. This should fix that by using the parameter layouts to move values from the local gradient for each term to the global gradient for the `LikelihoodExpression`.
…ihoodTerm`s by a scalar-valued parameter
Benchmark for 1690076Click to view benchmark
|
Benchmark for 8a8f70dClick to view benchmark
|
Benchmark for 83543b7Click to view benchmark
|
Floating point addition is not associative, and the standard parallel summation was causing non-deterministic results. This should be fixed with the inclusion of the `accurate` crate in this commit, although I've included a temporary hack for the gradients since you cannot sum `DVector`s using `accurate`. This should eventually be fixed, since I think it might cause a slight unneeded bump in memory (although maybe the compiler optimizes this out?).
…om MC AmpTools doesn't scale the MC term by the size of the "data" dataset, so I've chosen not to either. This seems to give better results and was probably the correct way to do it in the first place.
This is a simple, self-contained example script that should "just work". The data and MC have been generated with [`gen_amp`](https://github.com/JeffersonLab/halld_sim/tree/962c1fffc29eb4801b146d0a7f1e9aecb417374a/src/programs/Simulation/gen_amp) with the same amplitudes as in the example. Note that the overall scaling of parameters seems to be different. The generated S-wave had magnitude `100+0i` and the D-wave had `50+50i`, but the fit values from `laddu` aren't near those. However, the S/D ratio and phase are very close to correct, so this can probably be chalked up to some overall difference in how amplitudes are scaled in the two architectures.
Benchmark for 4a8984fClick to view benchmark
|
Benchmark for 0c1cc69Click to view benchmark
|
Benchmark for 6b7faf9Click to view benchmark
|
Adds a feature which allows NLL-like terms to be added and multiplied together. This can effectively be used to fit the same model over multiple datasets or fit multiple models over multiple datasets simultaneously. This adds an interface very similar to the one which allows
Amplitudes to be registered and formed intoExpressions. This should also allow users to introduce their own likelihood terms, like a LASSO term for example.Todos:
LikelihoodTerms.LikelihoodExpressions (this should be easy)