To clarify that last part: if you try to call `process(m.Sol)` with a model
object that has a `NoResults` value for `Sol`, that should throw a
MethodError. If I got this right, that is...
// Tomas
On Sunday, April 20, 2014 3:13:55 AM UTC+2, Tomas Lycken wrote:
>
> 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?
>>
>
