Re: [julia-users] Parametric Type Question - updating type

[Tom Breloff]

Thanks for the link Mauro.

Christopher: I think it might make sense to break out TermStructure and
pass it into your methods as an independent object.   If you find yourself
"mixing and matching" pricing engines and term structures, then that sounds
to me like you should be making use of multiple dispatch.  If a bond always
has the same pricing engine and term structure, then a parametric type
might make more sense.  It really comes down to whether the internal types
will need to change.

On Tue, Feb 2, 2016 at 1:49 AM, Mauro  wrote:

> I haven't been following this thread closely, so I have no frame of
> reference here, I'm like a child who wanders into the middle of a
> julia-users thread...
>
> A few observations:
>
> - functions being called with composite types which have some
>   non-concrete fields suffer no performance penalty, as long as you
>   don't use those non-concrete fields
> - if using a non-concrete field, you can use kernel
>   functions  (aka barrier funciton):
>
> http://docs.julialang.org/en/release-0.4/manual/performance-tips/#separate-kernel-functions
>   The kernel fn could be what Tom suggested
>
> nvp(myBond) = isdefined(myBond, :nvp_val) ? myBond.nvp_val :_nvp!(myBond,
> myBond.pricingEngine)
>
> _nvp!(bond, pe:PricingEngine1) = ... # writes to nvp_val field and returns
> it
> _nvp!(bond, pe:PricingEngine2) = ...
>
> On Tue, 2016-02-02 at 00:41, Christopher Alexander 
> wrote:
> > I've been trying to think of a way to implement this, but I'm having some
> > trouble.  Perhaps this can be a discussion around organizing objects in
> > Julia to best exploit the benefits of multiple dispatch.  Let's say I
> have
> > a Bond type:
> >
> > type Bond{P <: PricingEngine}
> >  # some attributes here
> >  pricingEngine::P
> > end
> >
> >
> > Then the particular PricingEngine object for each instantiation of "Bond"
> > has its own term structure (perhaps this could be stored with the bond
> > itself?).  Each PricingEngine sub type (in my code PricingEngine is
> > actually an abstract type itself) has its own calculation method, where
> > various components of the bond are calculated (e.g. NPV, etc).  I suppose
> > this could be separated out, but I essentially want to provide to the end
> > user something like npv(myBond).  The bond knows whether it's been
> > calculated or not, and if it hasn't, it does so via its pricing engine.
> >  Otherwise, it returns a cached value of its NPV (already having been
> > calculated).  If I break all of these things out (bond/instrument, term
> > structure, and pricing engine), I would envision a method like this:
> > npv(bond, pricing_engine, term_structure)
> >
> > Is there a better/more "Julian" way to organize this?  Perhaps keeping
> the
> > TermStructure separate from everyone and passing it into methods where I
> > need it?
> >
> >
> > On Monday, February 1, 2016 at 5:05:21 PM UTC-5, Tom Breloff wrote:
> >>
> >> Just so you realize... in this example "pricingEngine" has an abstract
> >> type, and you've possibly lost whatever performance gain you were hoping
> >> for in your original question.  To solve you either need to take the
> same
> >> approach in defining and updating the Bond object, or maybe rethink how
> >> you're doing this.  You should consider utilizing multiple dispatch a
> >> little more keep your PricingEngine and TermStructure separate:
> >>
> >> do_something(engine::PricingEngine, term::TermStructure) = ...
> >>
> >>
> >>
> >> On Mon, Feb 1, 2016 at 2:07 PM, Christopher Alexander <
> uvap...@gmail.com
> >> > wrote:
> >>
> >>> This doesn't seem to work if your PricingEngine object is attached to
> >>> some other object.  Like, for example if you have:
> >>>
> >>> type Bond
> >>>  pricingEngine::PricingEngine
> >>> end
> >>>
> >>>
> >>> myPE = PricingEngine(4.5, 5.5, TermStructureA())
> >>>
> >>>
> >>> myBond = Bond(myPE)
> >>>
> >>>
> >>> myPE = update_ts(myPE, TermStructureB())
> >>>
> >>>
> >>> At that point, myBond's pricing engine still points to the older myPE
> >>> with TermStructureA.
> >>>
> >>> On Monday, February 1, 2016 at 1:58:54 PM UTC-5, Christopher Alexander
> >>> wrote:
> 
>  So something like:
> 
>  function update_ts(pe::PricingEngine, newTS::TermStructure)
>   newPE = PricingEngine(pe.varA, pe.varB, newTS)
>   return newPE
>  end
> 
> 
>  myPE = PricingEngine(4.5, 5.5, TermStructureA())
> 
> 
>  myPE = update_ts(myPE, TermStructureB())
> 
>  You probably wouldn't be able to update the "myPE" object in place
> right
>  (i.e. updating it in the actual update_ts method and then returning
> itself)?
> 
> 
>  On Monday, February 1, 2016 at 1:50:41 PM UTC-5, Tom Breloff wrote:
> >
> > You could just construct a new object with the new TermStructure,
> > instead of overwriting the old one.
> >
> > On Mon, Feb 1, 2016 at 1:27 PM, Christopher Alexander <
> > uvap...@gmail.com> 

Re: [julia-users] Parametric Type Question - updating type

[Christopher Alexander]

Hey guys, thanks a million for the feedback!  I actually really like the 
idea of just making the instruments (e.g. Bond) immutable, and then just 
creating new instances when I need to change something.  I could create 
copy methods that would make it easy to spin up a new instance with 
generally the same attribute values (obviously with those attributes 
changed that I want to change). 

Tom, I don't think I'm doing as much mixing and matching as to warrant a 
complete separation, but I think it might be good to provide a calculate 
method that accepts a pricing engine and an instrument for a quick override.

Mauro, thanks for the link as well!  I think I am doing something like that 
wrt kernel functions.  Basically, if you call NPV or some other calculation 
request, it hits a "super" method of calculate that is able to determine if 
the instrument has been calculated.  Then using multiple dispatch, it calls 
a perform_calculation method for the instrument passed in.  That 
perform_calculation method does some preparation / pre-processing stuff 
then it calls the pricing engine's _calculate method.  Is that basically 
the type of separation you are talking about?

Thanks again for the feedback, this place is extremely helpful.

Chris

On Tuesday, February 2, 2016 at 10:42:32 AM UTC-5, Mauro wrote:
>
> > Christopher: I think it might make sense to break out TermStructure and 
> > pass it into your methods as an independent object.   If you find 
> yourself 
> > "mixing and matching" pricing engines and term structures, then that 
> sounds 
> > to me like you should be making use of multiple dispatch.  If a bond 
> always 
> > has the same pricing engine and term structure, then a parametric type 
> > might make more sense.  It really comes down to whether the internal 
> types 
> > will need to change. 
>
> It also occured to me that changing the PricingEngine underneath a Bond 
> and invalidating all the cached fields, like nvp below, is very error 
> prone.  It is probably better to have it immutable to just make a new 
> instance once the PricingEngine changes. 
>
> > On Tue, Feb 2, 2016 at 1:49 AM, Mauro  
> wrote: 
> > 
> >> I haven't been following this thread closely, so I have no frame of 
> >> reference here, I'm like a child who wanders into the middle of a 
> >> julia-users thread... 
> >> 
> >> A few observations: 
> >> 
> >> - functions being called with composite types which have some 
> >>   non-concrete fields suffer no performance penalty, as long as you 
> >>   don't use those non-concrete fields 
> >> - if using a non-concrete field, you can use kernel 
> >>   functions  (aka barrier funciton): 
> >> 
> >> 
> http://docs.julialang.org/en/release-0.4/manual/performance-tips/#separate-kernel-functions
>  
> >>   The kernel fn could be what Tom suggested 
> >> 
> >> nvp(myBond) = isdefined(myBond, :nvp_val) ? myBond.nvp_val 
> :_nvp!(myBond, 
> >> myBond.pricingEngine) 
> >> 
> >> _nvp!(bond, pe:PricingEngine1) = ... # writes to nvp_val field and 
> returns 
> >> it 
> >> _nvp!(bond, pe:PricingEngine2) = ... 
> >> 
> >> On Tue, 2016-02-02 at 00:41, Christopher Alexander  > 
> >> wrote: 
> >> > I've been trying to think of a way to implement this, but I'm having 
> some 
> >> > trouble.  Perhaps this can be a discussion around organizing objects 
> in 
> >> > Julia to best exploit the benefits of multiple dispatch.  Let's say I 
> >> have 
> >> > a Bond type: 
> >> > 
> >> > type Bond{P <: PricingEngine} 
> >> >  # some attributes here 
> >> >  pricingEngine::P 
> >> > end 
> >> > 
> >> > 
> >> > Then the particular PricingEngine object for each instantiation of 
> "Bond" 
> >> > has its own term structure (perhaps this could be stored with the 
> bond 
> >> > itself?).  Each PricingEngine sub type (in my code PricingEngine is 
> >> > actually an abstract type itself) has its own calculation method, 
> where 
> >> > various components of the bond are calculated (e.g. NPV, etc).  I 
> suppose 
> >> > this could be separated out, but I essentially want to provide to the 
> end 
> >> > user something like npv(myBond).  The bond knows whether it's been 
> >> > calculated or not, and if it hasn't, it does so via its pricing 
> engine. 
> >> >  Otherwise, it returns a cached value of its NPV (already having been 
> >> > calculated).  If I break all of these things out (bond/instrument, 
> term 
> >> > structure, and pricing engine), I would envision a method like this: 
> >> > npv(bond, pricing_engine, term_structure) 
> >> > 
> >> > Is there a better/more "Julian" way to organize this?  Perhaps 
> keeping 
> >> the 
> >> > TermStructure separate from everyone and passing it into methods 
> where I 
> >> > need it? 
> >> > 
> >> > 
> >> > On Monday, February 1, 2016 at 5:05:21 PM UTC-5, Tom Breloff wrote: 
> >> >> 
> >> >> Just so you realize... in this example "pricingEngine" has an 
> abstract 
> >> >> type, and you've possibly lost whatever 

Re: [julia-users] Parametric Type Question - updating type

[Mauro]

> Christopher: I think it might make sense to break out TermStructure and
> pass it into your methods as an independent object.   If you find yourself
> "mixing and matching" pricing engines and term structures, then that sounds
> to me like you should be making use of multiple dispatch.  If a bond always
> has the same pricing engine and term structure, then a parametric type
> might make more sense.  It really comes down to whether the internal types
> will need to change.

It also occured to me that changing the PricingEngine underneath a Bond
and invalidating all the cached fields, like nvp below, is very error
prone.  It is probably better to have it immutable to just make a new
instance once the PricingEngine changes.

> On Tue, Feb 2, 2016 at 1:49 AM, Mauro  wrote:
>
>> I haven't been following this thread closely, so I have no frame of
>> reference here, I'm like a child who wanders into the middle of a
>> julia-users thread...
>>
>> A few observations:
>>
>> - functions being called with composite types which have some
>>   non-concrete fields suffer no performance penalty, as long as you
>>   don't use those non-concrete fields
>> - if using a non-concrete field, you can use kernel
>>   functions  (aka barrier funciton):
>>
>> http://docs.julialang.org/en/release-0.4/manual/performance-tips/#separate-kernel-functions
>>   The kernel fn could be what Tom suggested
>>
>> nvp(myBond) = isdefined(myBond, :nvp_val) ? myBond.nvp_val :_nvp!(myBond,
>> myBond.pricingEngine)
>>
>> _nvp!(bond, pe:PricingEngine1) = ... # writes to nvp_val field and returns
>> it
>> _nvp!(bond, pe:PricingEngine2) = ...
>>
>> On Tue, 2016-02-02 at 00:41, Christopher Alexander 
>> wrote:
>> > I've been trying to think of a way to implement this, but I'm having some
>> > trouble.  Perhaps this can be a discussion around organizing objects in
>> > Julia to best exploit the benefits of multiple dispatch.  Let's say I
>> have
>> > a Bond type:
>> >
>> > type Bond{P <: PricingEngine}
>> >  # some attributes here
>> >  pricingEngine::P
>> > end
>> >
>> >
>> > Then the particular PricingEngine object for each instantiation of "Bond"
>> > has its own term structure (perhaps this could be stored with the bond
>> > itself?).  Each PricingEngine sub type (in my code PricingEngine is
>> > actually an abstract type itself) has its own calculation method, where
>> > various components of the bond are calculated (e.g. NPV, etc).  I suppose
>> > this could be separated out, but I essentially want to provide to the end
>> > user something like npv(myBond).  The bond knows whether it's been
>> > calculated or not, and if it hasn't, it does so via its pricing engine.
>> >  Otherwise, it returns a cached value of its NPV (already having been
>> > calculated).  If I break all of these things out (bond/instrument, term
>> > structure, and pricing engine), I would envision a method like this:
>> > npv(bond, pricing_engine, term_structure)
>> >
>> > Is there a better/more "Julian" way to organize this?  Perhaps keeping
>> the
>> > TermStructure separate from everyone and passing it into methods where I
>> > need it?
>> >
>> >
>> > On Monday, February 1, 2016 at 5:05:21 PM UTC-5, Tom Breloff wrote:
>> >>
>> >> Just so you realize... in this example "pricingEngine" has an abstract
>> >> type, and you've possibly lost whatever performance gain you were hoping
>> >> for in your original question.  To solve you either need to take the
>> same
>> >> approach in defining and updating the Bond object, or maybe rethink how
>> >> you're doing this.  You should consider utilizing multiple dispatch a
>> >> little more keep your PricingEngine and TermStructure separate:
>> >>
>> >> do_something(engine::PricingEngine, term::TermStructure) = ...
>> >>
>> >>
>> >>
>> >> On Mon, Feb 1, 2016 at 2:07 PM, Christopher Alexander <
>> uvap...@gmail.com
>> >> > wrote:
>> >>
>> >>> This doesn't seem to work if your PricingEngine object is attached to
>> >>> some other object.  Like, for example if you have:
>> >>>
>> >>> type Bond
>> >>>  pricingEngine::PricingEngine
>> >>> end
>> >>>
>> >>>
>> >>> myPE = PricingEngine(4.5, 5.5, TermStructureA())
>> >>>
>> >>>
>> >>> myBond = Bond(myPE)
>> >>>
>> >>>
>> >>> myPE = update_ts(myPE, TermStructureB())
>> >>>
>> >>>
>> >>> At that point, myBond's pricing engine still points to the older myPE
>> >>> with TermStructureA.
>> >>>
>> >>> On Monday, February 1, 2016 at 1:58:54 PM UTC-5, Christopher Alexander
>> >>> wrote:
>> 
>>  So something like:
>> 
>>  function update_ts(pe::PricingEngine, newTS::TermStructure)
>>   newPE = PricingEngine(pe.varA, pe.varB, newTS)
>>   return newPE
>>  end
>> 
>> 
>>  myPE = PricingEngine(4.5, 5.5, TermStructureA())
>> 
>> 
>>  myPE = update_ts(myPE, TermStructureB())
>> 
>>  You probably wouldn't be able to update the "myPE" object in place
>> right
>>  (i.e. updating it in the actual update_ts 

Re: [julia-users] Parametric Type Question - updating type

[Christopher Alexander]

This doesn't seem to work if your PricingEngine object is attached to some 
other object.  Like, for example if you have:

type Bond
 pricingEngine::PricingEngine
end


myPE = PricingEngine(4.5, 5.5, TermStructureA())


myBond = Bond(myPE)


myPE = update_ts(myPE, TermStructureB())


At that point, myBond's pricing engine still points to the older myPE with 
TermStructureA.

On Monday, February 1, 2016 at 1:58:54 PM UTC-5, Christopher Alexander 
wrote:
>
> So something like:
>
> function update_ts(pe::PricingEngine, newTS::TermStructure)
>  newPE = PricingEngine(pe.varA, pe.varB, newTS)
>  return newPE
> end
>
>
> myPE = PricingEngine(4.5, 5.5, TermStructureA())
>
>
> myPE = update_ts(myPE, TermStructureB())
>
> You probably wouldn't be able to update the "myPE" object in place right 
> (i.e. updating it in the actual update_ts method and then returning itself)?
>
>
> On Monday, February 1, 2016 at 1:50:41 PM UTC-5, Tom Breloff wrote:
>>
>> You could just construct a new object with the new TermStructure, instead 
>> of overwriting the old one.
>>
>> On Mon, Feb 1, 2016 at 1:27 PM, Christopher Alexander  
>> wrote:
>>
>>> Hello all, I have a question about the usage of parametric types.  I 
>>> know these bring about a performance boost (at least that was my 
>>> understanding), but I have a situation where I have a parametric type 
>>> defined as such:
>>>
>>> type PricingEngine{T <: TermStructure}
>>>  varA::Float64
>>>  varB::Float64
>>>  ts::T
>>> end
>>>
>>>
>>> But then I need to actually swap the existing term structure with 
>>> another subtype of TermStructure further down the road. Using parametric 
>>> types, it complains because I guess it's locked in to using whatever 
>>> TermStructure sub type is initially there when I instantiate the 
>>> PricingEngine type.  Is there anyway to do such an update while still using 
>>> a type parameter, or am I stuck just with a definition that uses the 
>>> broader abstract type?
>>>
>>> Thanks!
>>>
>>> Chris
>>>
>>
>>

Re: [julia-users] Parametric Type Question - updating type

[Tom Breloff]

You could just construct a new object with the new TermStructure, instead
of overwriting the old one.

On Mon, Feb 1, 2016 at 1:27 PM, Christopher Alexander 
wrote:

> Hello all, I have a question about the usage of parametric types.  I know
> these bring about a performance boost (at least that was my understanding),
> but I have a situation where I have a parametric type defined as such:
>
> type PricingEngine{T <: TermStructure}
>  varA::Float64
>  varB::Float64
>  ts::T
> end
>
>
> But then I need to actually swap the existing term structure with another
> subtype of TermStructure further down the road. Using parametric types, it
> complains because I guess it's locked in to using whatever TermStructure
> sub type is initially there when I instantiate the PricingEngine type.  Is
> there anyway to do such an update while still using a type parameter, or am
> I stuck just with a definition that uses the broader abstract type?
>
> Thanks!
>
> Chris
>

Re: [julia-users] Parametric Type Question - updating type

[Christopher Alexander]

So something like:

function update_ts(pe::PricingEngine, newTS::TermStructure)
 newPE = PricingEngine(pe.varA, pe.varB, newTS)
 return newPE
end


myPE = PricingEngine(4.5, 5.5, TermStructureA())


myPE = update_ts(myPE, TermStructureB())

You probably wouldn't be able to update the "myPE" object in place right 
(i.e. updating it in the actual update_ts method and then returning itself)?


On Monday, February 1, 2016 at 1:50:41 PM UTC-5, Tom Breloff wrote:
>
> You could just construct a new object with the new TermStructure, instead 
> of overwriting the old one.
>
> On Mon, Feb 1, 2016 at 1:27 PM, Christopher Alexander  > wrote:
>
>> Hello all, I have a question about the usage of parametric types.  I know 
>> these bring about a performance boost (at least that was my understanding), 
>> but I have a situation where I have a parametric type defined as such:
>>
>> type PricingEngine{T <: TermStructure}
>>  varA::Float64
>>  varB::Float64
>>  ts::T
>> end
>>
>>
>> But then I need to actually swap the existing term structure with another 
>> subtype of TermStructure further down the road. Using parametric types, it 
>> complains because I guess it's locked in to using whatever TermStructure 
>> sub type is initially there when I instantiate the PricingEngine type.  Is 
>> there anyway to do such an update while still using a type parameter, or am 
>> I stuck just with a definition that uses the broader abstract type?
>>
>> Thanks!
>>
>> Chris
>>
>
>

Re: [julia-users] Parametric Type Question - updating type

[Tom Breloff]

Just so you realize... in this example "pricingEngine" has an abstract
type, and you've possibly lost whatever performance gain you were hoping
for in your original question.  To solve you either need to take the same
approach in defining and updating the Bond object, or maybe rethink how
you're doing this.  You should consider utilizing multiple dispatch a
little more keep your PricingEngine and TermStructure separate:

do_something(engine::PricingEngine, term::TermStructure) = ...



On Mon, Feb 1, 2016 at 2:07 PM, Christopher Alexander 
wrote:

> This doesn't seem to work if your PricingEngine object is attached to some
> other object.  Like, for example if you have:
>
> type Bond
>  pricingEngine::PricingEngine
> end
>
>
> myPE = PricingEngine(4.5, 5.5, TermStructureA())
>
>
> myBond = Bond(myPE)
>
>
> myPE = update_ts(myPE, TermStructureB())
>
>
> At that point, myBond's pricing engine still points to the older myPE with
> TermStructureA.
>
> On Monday, February 1, 2016 at 1:58:54 PM UTC-5, Christopher Alexander
> wrote:
>>
>> So something like:
>>
>> function update_ts(pe::PricingEngine, newTS::TermStructure)
>>  newPE = PricingEngine(pe.varA, pe.varB, newTS)
>>  return newPE
>> end
>>
>>
>> myPE = PricingEngine(4.5, 5.5, TermStructureA())
>>
>>
>> myPE = update_ts(myPE, TermStructureB())
>>
>> You probably wouldn't be able to update the "myPE" object in place right
>> (i.e. updating it in the actual update_ts method and then returning itself)?
>>
>>
>> On Monday, February 1, 2016 at 1:50:41 PM UTC-5, Tom Breloff wrote:
>>>
>>> You could just construct a new object with the new TermStructure,
>>> instead of overwriting the old one.
>>>
>>> On Mon, Feb 1, 2016 at 1:27 PM, Christopher Alexander >> > wrote:
>>>
 Hello all, I have a question about the usage of parametric types.  I
 know these bring about a performance boost (at least that was my
 understanding), but I have a situation where I have a parametric type
 defined as such:

 type PricingEngine{T <: TermStructure}
  varA::Float64
  varB::Float64
  ts::T
 end


 But then I need to actually swap the existing term structure with
 another subtype of TermStructure further down the road. Using parametric
 types, it complains because I guess it's locked in to using whatever
 TermStructure sub type is initially there when I instantiate the
 PricingEngine type.  Is there anyway to do such an update while still using
 a type parameter, or am I stuck just with a definition that uses the
 broader abstract type?

 Thanks!

 Chris

>>>
>>>

Re: [julia-users] Parametric Type Question - updating type

[Christopher Alexander]

I've been trying to think of a way to implement this, but I'm having some 
trouble.  Perhaps this can be a discussion around organizing objects in 
Julia to best exploit the benefits of multiple dispatch.  Let's say I have 
a Bond type:

type Bond{P <: PricingEngine}
 # some attributes here
 pricingEngine::P
end


Then the particular PricingEngine object for each instantiation of "Bond" 
has its own term structure (perhaps this could be stored with the bond 
itself?).  Each PricingEngine sub type (in my code PricingEngine is 
actually an abstract type itself) has its own calculation method, where 
various components of the bond are calculated (e.g. NPV, etc).  I suppose 
this could be separated out, but I essentially want to provide to the end 
user something like npv(myBond).  The bond knows whether it's been 
calculated or not, and if it hasn't, it does so via its pricing engine. 
 Otherwise, it returns a cached value of its NPV (already having been 
calculated).  If I break all of these things out (bond/instrument, term 
structure, and pricing engine), I would envision a method like this:
npv(bond, pricing_engine, term_structure)

Is there a better/more "Julian" way to organize this?  Perhaps keeping the 
TermStructure separate from everyone and passing it into methods where I 
need it?


On Monday, February 1, 2016 at 5:05:21 PM UTC-5, Tom Breloff wrote:
>
> Just so you realize... in this example "pricingEngine" has an abstract 
> type, and you've possibly lost whatever performance gain you were hoping 
> for in your original question.  To solve you either need to take the same 
> approach in defining and updating the Bond object, or maybe rethink how 
> you're doing this.  You should consider utilizing multiple dispatch a 
> little more keep your PricingEngine and TermStructure separate:
>
> do_something(engine::PricingEngine, term::TermStructure) = ...
>
>
>
> On Mon, Feb 1, 2016 at 2:07 PM, Christopher Alexander  > wrote:
>
>> This doesn't seem to work if your PricingEngine object is attached to 
>> some other object.  Like, for example if you have:
>>
>> type Bond
>>  pricingEngine::PricingEngine
>> end
>>
>>
>> myPE = PricingEngine(4.5, 5.5, TermStructureA())
>>
>>
>> myBond = Bond(myPE)
>>
>>
>> myPE = update_ts(myPE, TermStructureB())
>>
>>
>> At that point, myBond's pricing engine still points to the older myPE 
>> with TermStructureA.
>>
>> On Monday, February 1, 2016 at 1:58:54 PM UTC-5, Christopher Alexander 
>> wrote:
>>>
>>> So something like:
>>>
>>> function update_ts(pe::PricingEngine, newTS::TermStructure)
>>>  newPE = PricingEngine(pe.varA, pe.varB, newTS)
>>>  return newPE
>>> end
>>>
>>>
>>> myPE = PricingEngine(4.5, 5.5, TermStructureA())
>>>
>>>
>>> myPE = update_ts(myPE, TermStructureB())
>>>
>>> You probably wouldn't be able to update the "myPE" object in place right 
>>> (i.e. updating it in the actual update_ts method and then returning itself)?
>>>
>>>
>>> On Monday, February 1, 2016 at 1:50:41 PM UTC-5, Tom Breloff wrote:

 You could just construct a new object with the new TermStructure, 
 instead of overwriting the old one.

 On Mon, Feb 1, 2016 at 1:27 PM, Christopher Alexander <
 uvap...@gmail.com> wrote:

> Hello all, I have a question about the usage of parametric types.  I 
> know these bring about a performance boost (at least that was my 
> understanding), but I have a situation where I have a parametric type 
> defined as such:
>
> type PricingEngine{T <: TermStructure}
>  varA::Float64
>  varB::Float64
>  ts::T
> end
>
>
> But then I need to actually swap the existing term structure with 
> another subtype of TermStructure further down the road. Using parametric 
> types, it complains because I guess it's locked in to using whatever 
> TermStructure sub type is initially there when I instantiate the 
> PricingEngine type.  Is there anyway to do such an update while still 
> using 
> a type parameter, or am I stuck just with a definition that uses the 
> broader abstract type?
>
> Thanks!
>
> Chris
>


>

Re: [julia-users] Parametric Type Question - updating type

[Mauro]

I haven't been following this thread closely, so I have no frame of
reference here, I'm like a child who wanders into the middle of a
julia-users thread...

A few observations:

- functions being called with composite types which have some
  non-concrete fields suffer no performance penalty, as long as you
  don't use those non-concrete fields
- if using a non-concrete field, you can use kernel
  functions  (aka barrier funciton):
  
http://docs.julialang.org/en/release-0.4/manual/performance-tips/#separate-kernel-functions
  The kernel fn could be what Tom suggested

nvp(myBond) = isdefined(myBond, :nvp_val) ? myBond.nvp_val :_nvp!(myBond, 
myBond.pricingEngine)

_nvp!(bond, pe:PricingEngine1) = ... # writes to nvp_val field and returns it
_nvp!(bond, pe:PricingEngine2) = ...

On Tue, 2016-02-02 at 00:41, Christopher Alexander  wrote:
> I've been trying to think of a way to implement this, but I'm having some
> trouble.  Perhaps this can be a discussion around organizing objects in
> Julia to best exploit the benefits of multiple dispatch.  Let's say I have
> a Bond type:
>
> type Bond{P <: PricingEngine}
>  # some attributes here
>  pricingEngine::P
> end
>
>
> Then the particular PricingEngine object for each instantiation of "Bond"
> has its own term structure (perhaps this could be stored with the bond
> itself?).  Each PricingEngine sub type (in my code PricingEngine is
> actually an abstract type itself) has its own calculation method, where
> various components of the bond are calculated (e.g. NPV, etc).  I suppose
> this could be separated out, but I essentially want to provide to the end
> user something like npv(myBond).  The bond knows whether it's been
> calculated or not, and if it hasn't, it does so via its pricing engine.
>  Otherwise, it returns a cached value of its NPV (already having been
> calculated).  If I break all of these things out (bond/instrument, term
> structure, and pricing engine), I would envision a method like this:
> npv(bond, pricing_engine, term_structure)
>
> Is there a better/more "Julian" way to organize this?  Perhaps keeping the
> TermStructure separate from everyone and passing it into methods where I
> need it?
>
>
> On Monday, February 1, 2016 at 5:05:21 PM UTC-5, Tom Breloff wrote:
>>
>> Just so you realize... in this example "pricingEngine" has an abstract
>> type, and you've possibly lost whatever performance gain you were hoping
>> for in your original question.  To solve you either need to take the same
>> approach in defining and updating the Bond object, or maybe rethink how
>> you're doing this.  You should consider utilizing multiple dispatch a
>> little more keep your PricingEngine and TermStructure separate:
>>
>> do_something(engine::PricingEngine, term::TermStructure) = ...
>>
>>
>>
>> On Mon, Feb 1, 2016 at 2:07 PM, Christopher Alexander > > wrote:
>>
>>> This doesn't seem to work if your PricingEngine object is attached to
>>> some other object.  Like, for example if you have:
>>>
>>> type Bond
>>>  pricingEngine::PricingEngine
>>> end
>>>
>>>
>>> myPE = PricingEngine(4.5, 5.5, TermStructureA())
>>>
>>>
>>> myBond = Bond(myPE)
>>>
>>>
>>> myPE = update_ts(myPE, TermStructureB())
>>>
>>>
>>> At that point, myBond's pricing engine still points to the older myPE
>>> with TermStructureA.
>>>
>>> On Monday, February 1, 2016 at 1:58:54 PM UTC-5, Christopher Alexander
>>> wrote:

 So something like:

 function update_ts(pe::PricingEngine, newTS::TermStructure)
  newPE = PricingEngine(pe.varA, pe.varB, newTS)
  return newPE
 end


 myPE = PricingEngine(4.5, 5.5, TermStructureA())


 myPE = update_ts(myPE, TermStructureB())

 You probably wouldn't be able to update the "myPE" object in place right
 (i.e. updating it in the actual update_ts method and then returning 
 itself)?


 On Monday, February 1, 2016 at 1:50:41 PM UTC-5, Tom Breloff wrote:
>
> You could just construct a new object with the new TermStructure,
> instead of overwriting the old one.
>
> On Mon, Feb 1, 2016 at 1:27 PM, Christopher Alexander <
> uvap...@gmail.com> wrote:
>
>> Hello all, I have a question about the usage of parametric types.  I
>> know these bring about a performance boost (at least that was my
>> understanding), but I have a situation where I have a parametric type
>> defined as such:
>>
>> type PricingEngine{T <: TermStructure}
>>  varA::Float64
>>  varB::Float64
>>  ts::T
>> end
>>
>>
>> But then I need to actually swap the existing term structure with
>> another subtype of TermStructure further down the road. Using parametric
>> types, it complains because I guess it's locked in to using whatever
>> TermStructure sub type is initially there when I instantiate the
>> PricingEngine type.  Is there anyway to do such an update while still 
>> using
>> 

[julia-users] Parametric Type Question - updating type

[Christopher Alexander]

Hello all, I have a question about the usage of parametric types.  I know 
these bring about a performance boost (at least that was my understanding), 
but I have a situation where I have a parametric type defined as such:

type PricingEngine{T <: TermStructure}
 varA::Float64
 varB::Float64
 ts::T
end


But then I need to actually swap the existing term structure with another 
subtype of TermStructure further down the road. Using parametric types, it 
complains because I guess it's locked in to using whatever TermStructure 
sub type is initially there when I instantiate the PricingEngine type.  Is 
there anyway to do such an update while still using a type parameter, or am 
I stuck just with a definition that uses the broader abstract type?

Thanks!

Chris