Closed FriesischScott closed 4 years ago
On the points:
-RandomVariable
: Entirely agree, we should just use the objects from Distributions.jl
. It's very extensive, and if we find that there are any distributions that we need, we can just create a new class of type Sampleable{Univariate}
-Parameter
: I think this depends. If we want to give a name
or a description
property to the Parameter
, this should be done. However, this could also be done when the parameter is given to the Input
as an argument in the constructor. I think I prefer option 2, as it means that native Julia variables can be given to the input object before making a parameter object. Maybe we can allow for both.
-Function
: I'm not exactly sure that we should make a Function
class. Julia natively allows for functions to be passed as arguments to other functions, and we should make use of this if we can.
I think creating a common subtype is quite difficult, since only abstract types can be inherited. So we'd have to say that both RandomVariableSet
and Parameter
are subtypes of whatever the abstract supertype of the univariate distributions are.
I think a good alternative however is that we restrict the arguments to Input
to be Union{<:RandomVariableSet, <:Sampleable{Univariate}, <:Parameter}
The only benefit of the Function
would be the same as for the Parameter
regarding description etc.
Then we would end up with
Union{<:RandomVariableSet, <:Sampleable{Univariate}, <:Number, <:Function}
for now?
Agreed. Maybe <:Real
instead of <:Number
since I don't think we should allow for complex numbers.
Yes, didn't even think about that.
Apart from
RandomVariableSet
what other inputs do we need?RandomVariable
: No need to wrap the objects fromDistributions.jl
.Parameter
: This could potentially just be any subtype ofNumber
and just be filled into theDataFrame
Function
: If we do this, it should probably just take a simplelambda
function that evaluates one variable and adds it to theDataFrame
. Alternatively this could be omitted and people would need to just include it in their model/solver. Might be nice though for intermediate values or something you might want in your end results.Should we have a common
type
for everything that can be an input? This type could be sub-typed together with what we need fromDistributions.jl
.