UncertaintyQuantification.jl

UncertaintyQuantification.jl copied to clipboard

Implementation of imprecise probabilities with external double loop by mean of:

1. Interval struc
2. ProbabilityBox struc (no distribution-free)
3. new method for probability_of_failure function

Dec 11 '23 10:12 andreaperin

@AnderGray This is still very much in progress, but if you have time and want to provide some feedback please go ahead.

I think the base idea is sound and works quite well.

Dec 21 '23 16:12 FriesischScott

Codecov Report

Attention: Patch coverage is 93.18182% with 9 lines in your changes missing coverage. Please review.

Project coverage is 97.58%. Comparing base (d12e8e3) to head (9b3cc37). Report is 1 commits behind head on master.

:exclamation: Current head 9b3cc37 differs from pull request most recent head 6d3b506

Please upload reports for the commit 6d3b506 to get more accurate results.

@@            Coverage Diff             @@
##           master     #146      +/-   ##
==========================================
+ Coverage   90.14%   97.58%   +7.44%     
==========================================
  Files          29       31       +2     
  Lines        1248     1244       -4     
==========================================
+ Hits         1125     1214      +89     
+ Misses        123       30      -93     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Jan 19 '24 15:01 codecov[bot]

@AnderGray Thoughts on the second method with inner optimization?

Jan 19 '24 15:01 FriesischScott

I think we should implement proper types to dispatch on instead of dispatching on the inputs vector like

• DoubleLoop(MonteCarlo(10000))
• IntervalMonteCarlo(1000)

Each method should than check, that at least one imprecise input is passed and error otherwise.

Jul 01 '24 08:07 FriesischScott

On that note, we might also define the input types with the proper terminology:

• DeterministicUQInput
• AleatoryUQInput
• EpistemicUQInput
• HybridUQInput

Is this too complex? The user will usually not have to interact with these types at all. They just create their Parameter, RandomVariable, Interval or ProbabilityBox and move on. But for anyone already familiar with the terms it could be nice.

Jul 01 '24 08:07 FriesischScott

On that note, we might also define the input types with the proper terminology:

* `DeterministicUQInput`

* `AleatoryUQInput`

* `EpistemicUQInput`

* `HybridUQInput`

Is this too complex? The user will usually not have to interact with these types at all. They just create their Parameter, RandomVariable, Interval or ProbabilityBox and move on. But for anyone already familiar with the terms it could be nice.

Yeah, this is too much and unnecessary. if we dispatch on the simulation all we need is a precise and imprecise type like we have now.

Jul 01 '24 16:07 FriesischScott

On that note, we might also define the input types with the proper terminology:

* `DeterministicUQInput`

* `AleatoryUQInput`

* `EpistemicUQInput`

* `HybridUQInput`

Is this too complex? The user will usually not have to interact with these types at all. They just create their Parameter, RandomVariable, Interval or ProbabilityBox and move on. But for anyone already familiar with the terms it could be nice.

Yeah, this is too much and unnecessary. if we dispatch on the simulation all we need is a precise and imprecise type like we have now.

@AnderGray and I decided to just keep UQInput and ImpreciseUQInput we can filter for the precise inputs using !isa

Jul 01 '24 16:07 FriesischScott