I can think of one easy (or not, depending on the details of your problem)
way to design around this: introduce an abstract results type, a "solution
not ready" type and let both the "solution not ready" type and your current
results type inherit from the abstract type. Then let your model's Sol
field be of the abstract type instead, so that you can give it a value
later:
abstract Model
abstract AbstracResults
type Results <: AbstractResults
# Details not shown here
end
type NoResults <: AbstractResults
type IFP{T <: FloatingPoint} <: Model
# Model parameters...
# Grid parameters for a...
# Parameters for y...
Sol::AbstractResults
end
When you initialize the Model object, give Sol a value of type NoResults.
*Note: *depending on how you use this, it might incur *severe performance
loss*, since you'll throw type inference for the solution object out the
window. It might be possible to mitigate this by writing methods that
process the results that take a Results object rather than an
AbstractResults, but I'm not sure enough on how type inference in Julia
works to know for sure. I'd try doing something like
function process(R::Results)
# R is now strictly typed to Results, so no type inference problems here
end
m = getModelWithResults() # however you want to initialize it, calculate
results etc
process(m.Sol)
I *think* this should solve the performance problem, but I'm *not sure*. *Use
with care*. =)
// Tomas
On Sunday, April 20, 2014 2:50:05 AM UTC+2, Spencer Lyon wrote:
>
> Say I have a type that defines a model. Something like this:
>
> abstract Model
>
> type Results
> # Details not shown here
> end
>
> type IFP{T <: FloatingPoint} <: Model
> # Model parameters
> rho::T
> beta::T
> r::T
> R::T
> gamma::T
>
> # Grid parameters for a
> n_a::Integer
> a_max::T
> a::Vector{T}
>
> # Parameters for y
> n_y::Integer
> y::Vector{T}
> P::Matrix{T}
>
> Sol::Results
>
> end
>
> I would like to be able to initialize an object of type IFP, work with it
> for a while, pass it to a solution routine, and then fill in the Solfield at
> a later time.
>
> Is there a way to leave Sol as an uninitialized field and then fill it in
> after the solution has been determined (which will be after constructing
> the IFP object and playing around with it for a while)? I suppose one way
> would be to have the inner constructor directly call the solution routine
> to get the Sol object. However, I want to avoid that because I may want
> to manipulate IFP between its construction and actually solving the model
> it describes.
> ------------------------------
>
> One more note. In this specific use case Sol could effectively be
> replaced by two other fields:
>
> c::Matrix{T}
> ap::Matrix{T}
>
> Would that be an easier way to work with them as uninitialized fields? If
> so, why?
>
