Imprecise probabilities

[andreaperin]

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

[FriesischScott]

@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.

[codecov[bot]]

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.

Files	Patch %	Lines
src/inputs/imprecise/p-box.jl	86.66%	4 Missing :warning:
src/reliability/probabilityoffailure_imprecise.jl	97.05%	2 Missing :warning:
src/simulations/importancesampling.jl	66.66%	2 Missing :warning:
src/simulations/montecarlo.jl	66.66%	1 Missing :warning:

Additional details and impacted files

```diff @@ 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.

[FriesischScott]

@AnderGray Thoughts on the second method with inner optimization?

[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.

[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.

[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.

[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