[julia-users] Re: Any serious quant finance package for Julia?

[Christopher Alexander]

. solvers. The same should be done with 
>>>>> the other parts of Quantlib like optimization, and you'll easily get a 
>>>>> vast 
>>>>> library routines specifically tailored to mathematical finance problem 
>>>>> which will outperform what is given by Quantlib.
>>>>>
>>>>> As to esproff's suggestion, Plots.jl should be targeted instead of 
>>>>> Gadfly for a few reasons. For one, plot recipes are a powerful way to 
>>>>> link 
>>>>> a package to plotting ability that would make most of the plotting work 
>>>>> trivial. Secondly, recipes would add plotting capabilities without having 
>>>>> a 
>>>>> large dependency like Gadfly. Thirdly, it would let you choose whatever 
>>>>> your favorite plotting backend is. Fourthly, Gadfly doesn't support 3D 
>>>>> plots which are one standard way of showing things like FDM results. 
>>>>> There's no need to unnecessarily limit our plotting abilities. Lastly, 
>>>>> the 
>>>>> developer of Plots.jl is a financial guy himself who has already 
>>>>> commented 
>>>>> on this thread (Tom Breloff), which always a bonus.
>>>>>
>>>>> As for targeting Convex.jl to put optimization routines over, I am not 
>>>>> sure. I would keep up with the developments of JuliaOpt and JuliaML to 
>>>>> see 
>>>>> what packages seem to be growing into the "go-to which offers the 
>>>>> functionality" (currently Optim.jl is the most, the metapackge Learn.jl 
>>>>> may 
>>>>> be an interesting target in the future). The "obvious" choice in some 
>>>>> cases 
>>>>> may be to target JuMP, but experiences from LightGraphs.jl seem to show 
>>>>> that it doesn't play nicely with other packages as a conditional 
>>>>> dependency 
>>>>> (i.e. if you want to use it, you might have to force everyone to have it 
>>>>> and it's a big install.) This is actually what has stalled a package for 
>>>>> parameter inference for ODEs/SDEs/PDEs: it's not clear to me what to 
>>>>> target 
>>>>> right now if I want as much functionality as possible but want to 
>>>>> minimize 
>>>>> the amount of re-writing in the future (once this is together though, you 
>>>>> could stick a front-end on this as well to do parameter inference for 
>>>>> financial equations).
>>>>>
>>>>> On Monday, September 19, 2016 at 11:26:12 AM UTC-7, Christopher 
>>>>> Alexander wrote:
>>>>>>
>>>>>> I had started the QuantLib.jl package, but the goal was basically a 
>>>>>> rewrite of the C++ package in Julia.  I haven't given it much love 
>>>>>> lately, 
>>>>>> but I hope to pick it back up sometime soon.  Anyone who wants to join 
>>>>>> in 
>>>>>> is definitely welcome!
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>> On Saturday, September 17, 2016 at 11:28:36 AM UTC-4, Chris 
>>>>>> Rackauckas wrote:
>>>>>>>
>>>>>>> Thanks Femto Trader for bumping this. I took a quick look at 
>>>>>>> Quantlib (and Ito) and I have to say, their numerical methods are very 
>>>>>>> rudimentary (in fact, one of their methods for stochastic processes, 
>>>>>>> EndPointEuler, doesn't have finite moments for its error due to KPS 
>>>>>>> 1994...). For anything that isn't a Jump Process you can currently use 
>>>>>>> DifferentialEquations.jl which has higher Strong order methods for 
>>>>>>> solving 
>>>>>>> the SDEs (with efficient adaptivity coming whenever my paper gets past 
>>>>>>> peer 
>>>>>>> review... short summary: mathematicians don't like computer science 
>>>>>>> tools 
>>>>>>> to show up in their math papers even if it makes it faster...). That's 
>>>>>>> the 
>>>>>>> thing though, you have to know the stochastic differential equation for 
>>>>>>> the 
>>>>>>> process.
>>>>>>>
>>>>>>> That said, it would pretty trivial to use dispatch so that way you 
>>>>>>> define a "GeneralizedBlac

[julia-users] Re: Any serious quant finance package for Julia?

[Christopher Alexander]

I had started the QuantLib.jl package, but the goal was basically a rewrite 
of the C++ package in Julia.  I haven't given it much love lately, but I 
hope to pick it back up sometime soon.  Anyone who wants to join in is 
definitely welcome!

Chris

On Saturday, September 17, 2016 at 11:28:36 AM UTC-4, Chris Rackauckas 
wrote:
>
> Thanks Femto Trader for bumping this. I took a quick look at Quantlib (and 
> Ito) and I have to say, their numerical methods are very rudimentary (in 
> fact, one of their methods for stochastic processes, EndPointEuler, doesn't 
> have finite moments for its error due to KPS 1994...). For anything that 
> isn't a Jump Process you can currently use DifferentialEquations.jl which 
> has higher Strong order methods for solving the SDEs (with efficient 
> adaptivity coming whenever my paper gets past peer review... short summary: 
> mathematicians don't like computer science tools to show up in their math 
> papers even if it makes it faster...). That's the thing though, you have to 
> know the stochastic differential equation for the process.
>
> That said, it would pretty trivial to use dispatch so that way you define 
> a "GeneralizedBlackScholes" equation, when then uses dispatch to construct 
> an SDE and apply an optimized SDE method to it. Since you can already do 
> this manually, it would just take setting up an object and a dispatch for 
> each process. Would this kind of ease-of-use layer for quants be something 
> anyone is interested in?
>
> The other thing is the Forward Kolmogorov PDEs associated to the SDEs. 
> Currently I have FEM methods for Poisson and Semilinear Heat Equations 
> which, as with the SDEs, can define any of the processes. This has a few 
> more fast methods than Quantlib, but it doesn't have TRBDF2 (but that would 
> be pretty trivial to implement. If you want it let me know, it should take 
> less than hour to modify what I have for the trapezoid rule since it's just 
> about defining the implicit function, NLsolve handles the solving).
>
> However, for most PDEs in finance you likely don't need the general 
> boundaries that FEM provides and so FDM (finite difference methods) can 
> probably be used. I haven't coded it up yet because I was looking for the 
> right implementation. I am honing in on it: ImageFiltering.jl gives a good 
> n-dimensional LaPlacian operator (and if I can convince Tim Holy it's 
> worthwhile, parallel/multithreaded), and I will be building up Grids.jl 
> <https://github.com/JuliaMath/Grids.jl/issues/3> memory-efficient 
> iterators for storing the space. This should lead to blazing fast FDM 
> implementations where the only actual array are the independent variable 
> (the option price) itself, so it should also be pretty memory efficient. 
> I'll be pairing this with the standard methods but also some very recent 
> Implicit Integrating Factor Methods (IIF) which should give a pretty large 
> speedup over anything in Quantlib for stiff equations. Would anyone be 
> interested in a quant ease-of-use interface over this as well? (If you'd 
> like to help speed this up, the way to do that is to help get Grids.jl 
> implemented. The ideas are coming together, but someone needs to throw 
> together some prototype (which shouldn't be too difficult))
>
> Note that Jump Processes can easily be done by using callback functions 
> (independent jumps can be computed in advance and then use an appropriate 
> tspan, adding the jump between the intervals. Dependent jumps just need to 
> use a callback within to add a jump in the appropriate intervals and maybe 
> interpolate back a bit, likely better with adaptive timestepping), and I'll 
> probably make an API to make this easier.
>
> Let me know what you guys would like to see on the differential equation / 
> stochastic processes side and I'll make it happen. I'm doing most of this 
> stuff for SPDEs in stochastic systems biology, but the equations are 
> literally the same (general SDEs and semilinear Heat equations) so I'm 
> plowing through whatever I can.
>
> On Thursday, October 1, 2015 at 7:34:32 PM UTC-7, Christopher Alexander 
> wrote:
>>
>> I think the Ito package is a great start, and I've forked it to work on 
>> adding to it other features of Quantlib (as best as I can!).  I'm glad 
>> someone mentioned the InterestRates package too as I hadn't seen that.  I 
>> work at major bank in risk, and my goal is to at some point sell them on 
>> the power of Julia (we are currently a Python/C++ shop).
>>
>> - Chris
>>
>> On Friday, September 11, 2015 at 2:05:39 AM UTC-4, Ferenc Szalma wrote:
>>>
>>> Are there any quant finance packages for Julia? I see some rudimentary 
>>> calendar and day-counting in Ito.js for example but not much for even a 
>>> simple yield2price or price2yield or any bond objects in Julia packages on 
>>> GitHub. What is the best approach, using C++ function/object from Quantlib, 
>>> to finance in Julia?
>>>
>>

[julia-users] Re: Anonymous Functions in 0.5 - Performance

[Christopher Alexander]

Yup, that did it.  And wow is it fast.

*function testing(k::Vector)*

  *return map((x::Float64) -> x^2, k)*


*end*

*@time testing(k)*0.07 seconds (7 allocations: 8.125 KB)



On Monday, August 1, 2016 at 12:25:59 PM UTC-4, David P. Sanders wrote:
>
> Don't do benchmarks in global scope. Wrap everything in a function. 

[julia-users] Anonymous Functions in 0.5 - Performance

[Christopher Alexander]

Hi all!  I am wondering if perhaps I am getting the syntax wrong with 
respect to the proper way to do anonymous functions in 0.5.  I am not 
seeing any performance increase when using them as I expected.

For example:


*k = rand(1000)*

*@time map((x::Float64) -> x^2, k)*0.025886 seconds (12.55 k allocations: 
567.842 KB)



*squareit(x::Float64) = x^2*

*@time map(squareit, k)*

0.000103 seconds (7 allocations: 8.125 KB)

Or are you not going to get a speed increase using "map"?

Thanks!

Chris

[julia-users] Re: QuantLib in Julia: JQuantLib (very very alpha stage at this point!)

[Christopher Alexander]

Hello all,

I just wanted to provide an update on this package.  I haven't officially 
registered it yet (I still have more work I want to do, and I need to add 
more tests), but there have been significant updates in the past month. 
 I've added QuantLib's Monte Carlo simulation features, as well some of its 
market model platform.  There are examples which show how these are 
implemented and also an example which calculates CVA (credit valuation 
adjustment) based off of an example 
here: 
http://nbviewer.jupyter.org/github/mgroncki/IPythonScripts/blob/master/CVA_calculation_I.ipynb
 
 I've also added some documentation 
(http://quantlibjl.readthedocs.org/en/latest/) and some tests, but again, 
this is still very much a work in progress!  Let me know if anyone runs 
into any issues!

Thanks!

Chris

On Tuesday, March 1, 2016 at 7:14:12 PM UTC-5, Christopher Alexander wrote:
>
> OK, I have renamed the package to QuantLib.jl.  The package is located 
> here:  https://github.com/pazzo83/QuantLib.jl
>
> Thanks again for all the feedback!
>
> - Chris
>
> On Tuesday, March 1, 2016 at 8:50:24 AM UTC-5, Jeffrey Sarnoff wrote:
>>
>> As Eric suggests, naming it QuantLib.jl works best with the package 
>> ecosystem and it is not in use elsewhere.
>>
>> On Tuesday, March 1, 2016 at 8:40:32 AM UTC-5, Luigi Ballabio wrote:
>>>
>>> Very interesting--drop me a line if you want me to add a link to your 
>>> project on the QuantLib site.  One thing though: the name JQuantLib has 
>>> been taken for a while by another project (with which I'm not involved) 
>>> that's writing a Java port of QuantLib; see <
>>> http://www.jquantlib.org/en/latest/>.  You might want to come up with a 
>>> new name to avoid confusion.
>>>
>>> Now I just have to learn Julia to have a look at your code :)
>>>
>>> Luigi
>>>
>>>
>>> On Tuesday, March 1, 2016 at 7:56:45 AM UTC+1, Christopher Alexander 
>>> wrote:
>>>>
>>>> Thanks guys!  I still have a lot of work to do regarding writing tests 
>>>> and all, but one awesome thing is that for the most part, I am matching or 
>>>> beating the C++ timings for the examples I've created so far.
>>>>
>>>> On Monday, February 29, 2016 at 11:24:09 PM UTC-5, Viral Shah wrote:
>>>>>
>>>>> You've already got a nice body of code there!
>>>>>
>>>>> -viral
>>>>>
>>>>> On Monday, February 29, 2016 at 10:02:16 PM UTC+5:30, Christopher 
>>>>> Alexander wrote:
>>>>>>
>>>>>> Hello all, I'd like to point people in the direction of a package 
>>>>>> I've been working on: JQuantLib, to get some feedback.  Basically, I am 
>>>>>> trying to write a version of the very popular open-source quantitative 
>>>>>> finance library QuantLib in pure Julia.  The library itself is written 
>>>>>> in 
>>>>>> C++, but it is commonly used in Python (via SWIG).  I thought this would 
>>>>>> be 
>>>>>> a first attempt at trying to solve a common problem in many financial 
>>>>>> firms 
>>>>>> where you have basically two different dev environments: a 
>>>>>> calculation-heavy one (where speed is important) in C++, C, etc and one 
>>>>>> that is increasingly in Python to provide an abstraction to that lower 
>>>>>> level.  Julia seems to be a perfect fit for eliminating the myriad 
>>>>>> issues 
>>>>>> one can encounter with this bifurcated dev setup.
>>>>>>
>>>>>> The package itself is located here: 
>>>>>> https://github.com/pazzo83/JQuantLib
>>>>>>
>>>>>> There is a bond pricing (NPV) example in the readme itself, and 
>>>>>> further examples in the examples folder (these are under development 
>>>>>> still).  I am continuing to work on this and add to it, but I'd love 
>>>>>> some 
>>>>>> feedback!  I'm still relatively new to Julia, but working on this has 
>>>>>> definitely improved my fluency of the language.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>

[julia-users] Re: calling files in Julia

[Christopher Alexander]

No, you can call files using "include", but you are only going to 
import essentially the functions, types, and global variables defined in 
those files (you should not include a file inside of a function).  You do 
see though how your variable "c" in "test" would not be accessible anywhere 
else, right?

Chris

On Wednesday, March 23, 2016 at 3:39:10 PM UTC-4, new to Julia wrote:
>
> Thanks for your reply. Does it mean that calling files in Julia is 
> impossible？ 
>
> On Wednesday, March 23, 2016 at 1:57:16 PM UTC-5, Christopher Alexander 
> wrote:
>>
>> How is test2 supposed to know what "c" is?  It is only defined inside the 
>> scope of the function "test", so it won't be accessible anywhere else.
>>
>> Chris
>>
>> On Wednesday, March 23, 2016 at 2:41:29 PM UTC-4, new to Julia wrote:
>>>
>>> I have a question for calling files in Julia:
>>>
>>> I have two jl files. And I can call one file from the other file. 
>>> However, the variable or constant defined in that file cannot be used in 
>>> the other file. I am wondering that how to fix this? The following is a 
>>> simple example. 
>>>
>>> function test(x)
>>>   c=2;
>>>   y1=6*x;
>>>   y2=x/5;
>>>   y1,y2
>>> end
>>> pwd()
>>>
>>>
>>> ## test and test2 are used for calling functions in Julia
>>> function test2(x)
>>>   include("test.jl")
>>>   yold,ynew=test(x/c);
>>>   y3=yold+10;
>>>   y4=ynew-10;
>>>   yold2,ynew2=test(x)
>>>   y5=yold2+20;
>>>   y6=ynew2-20;
>>>   y3,y4,y5,y6
>>> end
>>> y3,y4,y5,y6=test2(100)
>>>
>>>
>>> However, when I run this test2, there is a error comes out: saying that 
>>> c is not defined.
>>>
>>> Thank you very much.
>>>
>>>

[julia-users] Re: calling files in Julia

[Christopher Alexander]

How is test2 supposed to know what "c" is?  It is only defined inside the 
scope of the function "test", so it won't be accessible anywhere else.

Chris

On Wednesday, March 23, 2016 at 2:41:29 PM UTC-4, new to Julia wrote:
>
> I have a question for calling files in Julia:
>
> I have two jl files. And I can call one file from the other file. However, 
> the variable or constant defined in that file cannot be used in the other 
> file. I am wondering that how to fix this? The following is a simple 
> example. 
>
> function test(x)
>   c=2;
>   y1=6*x;
>   y2=x/5;
>   y1,y2
> end
> pwd()
>
>
> ## test and test2 are used for calling functions in Julia
> function test2(x)
>   include("test.jl")
>   yold,ynew=test(x/c);
>   y3=yold+10;
>   y4=ynew-10;
>   yold2,ynew2=test(x)
>   y5=yold2+20;
>   y6=ynew2-20;
>   y3,y4,y5,y6
> end
> y3,y4,y5,y6=test2(100)
>
>
> However, when I run this test2, there is a error comes out: saying that c 
> is not defined.
>
> Thank you very much.
>
>

Re: [julia-users] Data Structure / Pair question

[Christopher Alexander]

In case anyone is interested, I actually just decided to use a Matrix, and 
when I needed it I would call sortrows and take each column and put them in 
a values vector and weights vector (for further calculations) respectively. 
 I thought this was easier, and I noticed sortrows keeps the two columns 
"together" (in the sense that, upon sorting, the values in cols A & B are 
kept together).

You can see the result 
here: https://github.com/pazzo83/QuantLib.jl/blob/master/src/math/statistics.jl

If anyone has a possibly more efficient way of doing this, please share!

- Chris

On Monday, March 7, 2016 at 7:39:45 PM UTC-5, Christopher Alexander wrote:
>
> Many thanks, these are very helpful!  Yes, the two vectors are going to be 
> of the same type.  The StructsOfArrays package is interesting too, as let's 
> say you have a construction like this:
>
> *arr = StructOfArrays(Pair{Float64, Float64}, 100)*
>
> You can go ahead, and populate this as you need.  If you need all the 
> firsts or seconds of the pairs, you can access the object's array param 
> (arr.arrays), and all the firsts are in the first array, and all the 
> seconds are in the second array.  I noticed that at a certain size, the 
> sort algo must change, and I needed to override the resize! method for the 
> StructOfArrays type.  I will compare the speed vs some of these other 
> options.
>
> Thanks!!
>
> On Monday, March 7, 2016 at 6:13:22 PM UTC-5, tshort wrote:
>>
>> There are several options to "keep things together", particularly with 
>> vectors of the same type:
>>
>> - DataFrame columns -- watch how you use columns to keep type stability
>>
>> - Nx2 Array
>>
>> - Nx2 NamedArray:
>> https://github.com/davidavdav/NamedArrays.jl
>>
>> - AxisArrays:
>> https://github.com/mbauman/AxisArrays.jl
>>
>>
>> On Mon, Mar 7, 2016 at 5:11 PM, Christopher Alexander <uvap...@gmail.com> 
>> wrote:
>>
>>> Yea, I was thinking about two different vectors, but then if I did any 
>>> sorting, the value vector and weight vector would be out-of-sync.  I'll 
>>> check out this StructsOfArrays package
>>>
>>> Thanks!
>>>
>>> Chris
>>>
>>> On Monday, March 7, 2016 at 5:03:14 PM UTC-5, tshort wrote:
>>>>
>>>> It depends on what "various weighted statistical calculations" 
>>>> involves. I'd start with two vectors, `x` and `w`. If you really need them 
>>>> to be coupled tightly, you could define an immutable type to hold the 
>>>> value 
>>>> and the weight, but the two separate vectors can be faster for some 
>>>> operations. Also, see:
>>>>
>>>> https://github.com/simonster/StructsOfArrays.jl
>>>>
>>>> On Mon, Mar 7, 2016 at 4:50 PM, Christopher Alexander <
>>>> uvap...@gmail.com> wrote:
>>>>
>>>>> Hello all, I need to create a structure where I keep track of pairs of 
>>>>> value => weight so that I can do various weighted statistical 
>>>>> calculations.
>>>>>
>>>>> I know that StatsBase has a weights vector, which I plan on using, but 
>>>>> the way that is set up is that it is disassociated from each of the 
>>>>> values 
>>>>> to which the weights are to be applied.
>>>>>
>>>>> I need the mapping that "Pair" provides, but I've noticed that there 
>>>>> is no easy way, if I have an array of pairs, to grab all the first values 
>>>>> or all the second values (like you can do with a dict in grabbing keys or 
>>>>> values).
>>>>>
>>>>> I've tried to do something like map(first, my_array_of_pairs), but 
>>>>> this is about 10x slower than if you have a dictionary of value => weight 
>>>>> and just asked for the keys.  I actually tried to use a dict at first, 
>>>>> but 
>>>>> ran into issues with duplicate values (they were overwriting each other 
>>>>> because the value was the key).
>>>>>
>>>>> Any suggestions, or any better way to manipulate an array of Pairs?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Chris
>>>>>
>>>>
>>>>
>>

Re: [julia-users] Data Structure / Pair question

[Christopher Alexander]

Many thanks, these are very helpful!  Yes, the two vectors are going to be 
of the same type.  The StructsOfArrays package is interesting too, as let's 
say you have a construction like this:

*arr = StructOfArrays(Pair{Float64, Float64}, 100)*

You can go ahead, and populate this as you need.  If you need all the 
firsts or seconds of the pairs, you can access the object's array param 
(arr.arrays), and all the firsts are in the first array, and all the 
seconds are in the second array.  I noticed that at a certain size, the 
sort algo must change, and I needed to override the resize! method for the 
StructOfArrays type.  I will compare the speed vs some of these other 
options.

Thanks!!

On Monday, March 7, 2016 at 6:13:22 PM UTC-5, tshort wrote:
>
> There are several options to "keep things together", particularly with 
> vectors of the same type:
>
> - DataFrame columns -- watch how you use columns to keep type stability
>
> - Nx2 Array
>
> - Nx2 NamedArray:
> https://github.com/davidavdav/NamedArrays.jl
>
> - AxisArrays:
> https://github.com/mbauman/AxisArrays.jl
>
>
> On Mon, Mar 7, 2016 at 5:11 PM, Christopher Alexander <uvap...@gmail.com 
> > wrote:
>
>> Yea, I was thinking about two different vectors, but then if I did any 
>> sorting, the value vector and weight vector would be out-of-sync.  I'll 
>> check out this StructsOfArrays package
>>
>> Thanks!
>>
>> Chris
>>
>> On Monday, March 7, 2016 at 5:03:14 PM UTC-5, tshort wrote:
>>>
>>> It depends on what "various weighted statistical calculations" involves. 
>>> I'd start with two vectors, `x` and `w`. If you really need them to be 
>>> coupled tightly, you could define an immutable type to hold the value and 
>>> the weight, but the two separate vectors can be faster for some operations. 
>>> Also, see:
>>>
>>> https://github.com/simonster/StructsOfArrays.jl
>>>
>>> On Mon, Mar 7, 2016 at 4:50 PM, Christopher Alexander <uvap...@gmail.com
>>> > wrote:
>>>
>>>> Hello all, I need to create a structure where I keep track of pairs of 
>>>> value => weight so that I can do various weighted statistical calculations.
>>>>
>>>> I know that StatsBase has a weights vector, which I plan on using, but 
>>>> the way that is set up is that it is disassociated from each of the values 
>>>> to which the weights are to be applied.
>>>>
>>>> I need the mapping that "Pair" provides, but I've noticed that there is 
>>>> no easy way, if I have an array of pairs, to grab all the first values or 
>>>> all the second values (like you can do with a dict in grabbing keys or 
>>>> values).
>>>>
>>>> I've tried to do something like map(first, my_array_of_pairs), but this 
>>>> is about 10x slower than if you have a dictionary of value => weight and 
>>>> just asked for the keys.  I actually tried to use a dict at first, but ran 
>>>> into issues with duplicate values (they were overwriting each other 
>>>> because 
>>>> the value was the key).
>>>>
>>>> Any suggestions, or any better way to manipulate an array of Pairs?
>>>>
>>>> Thanks!
>>>>
>>>> Chris
>>>>
>>>
>>>
>

Re: [julia-users] Data Structure / Pair question

[Christopher Alexander]

Yea, I was thinking about two different vectors, but then if I did any 
sorting, the value vector and weight vector would be out-of-sync.  I'll 
check out this StructsOfArrays package

Thanks!

Chris

On Monday, March 7, 2016 at 5:03:14 PM UTC-5, tshort wrote:
>
> It depends on what "various weighted statistical calculations" involves. 
> I'd start with two vectors, `x` and `w`. If you really need them to be 
> coupled tightly, you could define an immutable type to hold the value and 
> the weight, but the two separate vectors can be faster for some operations. 
> Also, see:
>
> https://github.com/simonster/StructsOfArrays.jl
>
> On Mon, Mar 7, 2016 at 4:50 PM, Christopher Alexander <uvap...@gmail.com 
> > wrote:
>
>> Hello all, I need to create a structure where I keep track of pairs of 
>> value => weight so that I can do various weighted statistical calculations.
>>
>> I know that StatsBase has a weights vector, which I plan on using, but 
>> the way that is set up is that it is disassociated from each of the values 
>> to which the weights are to be applied.
>>
>> I need the mapping that "Pair" provides, but I've noticed that there is 
>> no easy way, if I have an array of pairs, to grab all the first values or 
>> all the second values (like you can do with a dict in grabbing keys or 
>> values).
>>
>> I've tried to do something like map(first, my_array_of_pairs), but this 
>> is about 10x slower than if you have a dictionary of value => weight and 
>> just asked for the keys.  I actually tried to use a dict at first, but ran 
>> into issues with duplicate values (they were overwriting each other because 
>> the value was the key).
>>
>> Any suggestions, or any better way to manipulate an array of Pairs?
>>
>> Thanks!
>>
>> Chris
>>
>
>

[julia-users] Re: Incomplete parametric types

[Christopher Alexander]

Ah, yep.  I figured I might have to at least know the type ahead of time. 
 This should work though, thanks!!

Chris

On Friday, March 4, 2016 at 12:26:49 PM UTC-5, John Myles White wrote:
>
> Is this what you want?
>
>
> julia> abstract ABC
>
>
> julia> type A <: ABC end
>
>
> julia> type B <: ABC end
>
>
> julia> 
>
>
> julia> type TestType{T <:ABC}
>
>a::Float64
>
>b::T
>
>
>
>TestType(a::Float64) = new(a)
>
>end
>
>
> julia> myT = TestType{A}(4.0)
>
> TestType{A}(4.0,#undef)
>
>
> julia> myT.b = A()
>
> A()
>
>
> julia> myT
>
> TestType{A}(4.0,A())
>
> On Friday, March 4, 2016 at 9:19:42 AM UTC-8, Christopher Alexander wrote:
>>
>> Hi all,
>>
>> Is there anyway to do something like the following?
>>
>> abstract ABC
>>
>> type A <: ABC end
>>
>> type B <: ABC end
>>
>> type TestType{T <:ABC}
>> a::Float64
>> b::T
>> 
>> TestType(a::Float64) = new(a)
>> end
>>
>> myT = TestType(4.0)
>> myT.b = A()
>>
>> I am wondering if you can incompletely initialize a parametric type, and 
>> then set the actual value needed later.  The above code doesn't work, but 
>> that is what I'm trying to do.  The alternative is I guess to have some 
>> default Null Type, but then to get the performance gains I have to copy the 
>> object when I want to actually set it with the value that I want.
>>
>> Thanks!
>>
>> Chris
>>
>

[julia-users] Incomplete parametric types

[Christopher Alexander]

Hi all,

Is there anyway to do something like the following?

abstract ABC

type A <: ABC end

type B <: ABC end

type TestType{T <:ABC}
a::Float64
b::T

TestType(a::Float64) = new(a)
end

myT = TestType(4.0)
myT.b = A()

I am wondering if you can incompletely initialize a parametric type, and 
then set the actual value needed later.  The above code doesn't work, but 
that is what I'm trying to do.  The alternative is I guess to have some 
default Null Type, but then to get the performance gains I have to copy the 
object when I want to actually set it with the value that I want.

Thanks!

Chris

[julia-users] Re: QuantLib in Julia: JQuantLib (very very alpha stage at this point!)

[Christopher Alexander]

OK, I have renamed the package to QuantLib.jl.  The package is located 
here:  https://github.com/pazzo83/QuantLib.jl

Thanks again for all the feedback!

- Chris

On Tuesday, March 1, 2016 at 8:50:24 AM UTC-5, Jeffrey Sarnoff wrote:
>
> As Eric suggests, naming it QuantLib.jl works best with the package 
> ecosystem and it is not in use elsewhere.
>
> On Tuesday, March 1, 2016 at 8:40:32 AM UTC-5, Luigi Ballabio wrote:
>>
>> Very interesting--drop me a line if you want me to add a link to your 
>> project on the QuantLib site.  One thing though: the name JQuantLib has 
>> been taken for a while by another project (with which I'm not involved) 
>> that's writing a Java port of QuantLib; see <
>> http://www.jquantlib.org/en/latest/>.  You might want to come up with a 
>> new name to avoid confusion.
>>
>> Now I just have to learn Julia to have a look at your code :)
>>
>> Luigi
>>
>>
>> On Tuesday, March 1, 2016 at 7:56:45 AM UTC+1, Christopher Alexander 
>> wrote:
>>>
>>> Thanks guys!  I still have a lot of work to do regarding writing tests 
>>> and all, but one awesome thing is that for the most part, I am matching or 
>>> beating the C++ timings for the examples I've created so far.
>>>
>>> On Monday, February 29, 2016 at 11:24:09 PM UTC-5, Viral Shah wrote:
>>>>
>>>> You've already got a nice body of code there!
>>>>
>>>> -viral
>>>>
>>>> On Monday, February 29, 2016 at 10:02:16 PM UTC+5:30, Christopher 
>>>> Alexander wrote:
>>>>>
>>>>> Hello all, I'd like to point people in the direction of a package I've 
>>>>> been working on: JQuantLib, to get some feedback.  Basically, I am trying 
>>>>> to write a version of the very popular open-source quantitative finance 
>>>>> library QuantLib in pure Julia.  The library itself is written in C++, 
>>>>> but 
>>>>> it is commonly used in Python (via SWIG).  I thought this would be a 
>>>>> first 
>>>>> attempt at trying to solve a common problem in many financial firms where 
>>>>> you have basically two different dev environments: a calculation-heavy 
>>>>> one 
>>>>> (where speed is important) in C++, C, etc and one that is increasingly in 
>>>>> Python to provide an abstraction to that lower level.  Julia seems to be 
>>>>> a 
>>>>> perfect fit for eliminating the myriad issues one can encounter with this 
>>>>> bifurcated dev setup.
>>>>>
>>>>> The package itself is located here: 
>>>>> https://github.com/pazzo83/JQuantLib
>>>>>
>>>>> There is a bond pricing (NPV) example in the readme itself, and 
>>>>> further examples in the examples folder (these are under development 
>>>>> still).  I am continuing to work on this and add to it, but I'd love some 
>>>>> feedback!  I'm still relatively new to Julia, but working on this has 
>>>>> definitely improved my fluency of the language.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Chris
>>>>>
>>>>

[julia-users] Re: QuantLib in Julia: JQuantLib (very very alpha stage at this point!)

[Christopher Alexander]

Yes, I am going to reach out to them shortly.  Thanks!

On Tuesday, March 1, 2016 at 2:18:36 PM UTC-5, cdm wrote:
>
>
> are the devs/users on
>
>https://github.com/JuliaQuant
>
>
> looped in to this effort ?
>
>
> good show.
>
> ~ cdm
>
>
>
> On Tuesday, March 1, 2016 at 8:07:53 AM UTC-8, Christopher Alexander wrote:
>>
>> Thanks for the feedback all!  I of course welcome any contributions and 
>> collaboration to/with this package!  Luigi, I'd be honored to have a link 
>> to this package on the QuantLib site.  I am first going to change the name 
>> of the package to QuantLib.jl, then I will post an updated link here.  In 
>> terms of learning Julia, the resources both here and at 
>> http://julialang.org/ are indispensable.
>>
>> Thanks!
>>
>> Chris
>>
>> On Tuesday, March 1, 2016 at 8:50:24 AM UTC-5, Jeffrey Sarnoff wrote:
>>>
>>> As Eric suggests, naming it QuantLib.jl works best with the package 
>>> ecosystem and it is not in use elsewhere.
>>>
>>> On Tuesday, March 1, 2016 at 8:40:32 AM UTC-5, Luigi Ballabio wrote:
>>>>
>>>> Very interesting--drop me a line if you want me to add a link to your 
>>>> project on the QuantLib site.  One thing though: the name JQuantLib has 
>>>> been taken for a while by another project (with which I'm not involved) 
>>>> that's writing a Java port of QuantLib; see <
>>>> http://www.jquantlib.org/en/latest/>.  You might want to come up with 
>>>> a new name to avoid confusion.
>>>>
>>>> Now I just have to learn Julia to have a look at your code :)
>>>>
>>>> Luigi
>>>>
>>>>
>>>> On Tuesday, March 1, 2016 at 7:56:45 AM UTC+1, Christopher Alexander 
>>>> wrote:
>>>>>
>>>>> Thanks guys!  I still have a lot of work to do regarding writing tests 
>>>>> and all, but one awesome thing is that for the most part, I am matching 
>>>>> or 
>>>>> beating the C++ timings for the examples I've created so far.
>>>>>
>>>>> On Monday, February 29, 2016 at 11:24:09 PM UTC-5, Viral Shah wrote:
>>>>>>
>>>>>> You've already got a nice body of code there!
>>>>>>
>>>>>> -viral
>>>>>>
>>>>>> On Monday, February 29, 2016 at 10:02:16 PM UTC+5:30, Christopher 
>>>>>> Alexander wrote:
>>>>>>>
>>>>>>> Hello all, I'd like to point people in the direction of a package 
>>>>>>> I've been working on: JQuantLib, to get some feedback.  Basically, I am 
>>>>>>> trying to write a version of the very popular open-source quantitative 
>>>>>>> finance library QuantLib in pure Julia.  The library itself is written 
>>>>>>> in 
>>>>>>> C++, but it is commonly used in Python (via SWIG).  I thought this 
>>>>>>> would be 
>>>>>>> a first attempt at trying to solve a common problem in many financial 
>>>>>>> firms 
>>>>>>> where you have basically two different dev environments: a 
>>>>>>> calculation-heavy one (where speed is important) in C++, C, etc and one 
>>>>>>> that is increasingly in Python to provide an abstraction to that lower 
>>>>>>> level.  Julia seems to be a perfect fit for eliminating the myriad 
>>>>>>> issues 
>>>>>>> one can encounter with this bifurcated dev setup.
>>>>>>>
>>>>>>> The package itself is located here: 
>>>>>>> https://github.com/pazzo83/JQuantLib
>>>>>>>
>>>>>>> There is a bond pricing (NPV) example in the readme itself, and 
>>>>>>> further examples in the examples folder (these are under development 
>>>>>>> still).  I am continuing to work on this and add to it, but I'd love 
>>>>>>> some 
>>>>>>> feedback!  I'm still relatively new to Julia, but working on this has 
>>>>>>> definitely improved my fluency of the language.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>

[julia-users] Re: QuantLib in Julia: JQuantLib (very very alpha stage at this point!)

[Christopher Alexander]

Thanks guys!  I still have a lot of work to do regarding writing tests and 
all, but one awesome thing is that for the most part, I am matching or 
beating the C++ timings for the examples I've created so far.

On Monday, February 29, 2016 at 11:24:09 PM UTC-5, Viral Shah wrote:
>
> You've already got a nice body of code there!
>
> -viral
>
> On Monday, February 29, 2016 at 10:02:16 PM UTC+5:30, Christopher 
> Alexander wrote:
>>
>> Hello all, I'd like to point people in the direction of a package I've 
>> been working on: JQuantLib, to get some feedback.  Basically, I am trying 
>> to write a version of the very popular open-source quantitative finance 
>> library QuantLib in pure Julia.  The library itself is written in C++, but 
>> it is commonly used in Python (via SWIG).  I thought this would be a first 
>> attempt at trying to solve a common problem in many financial firms where 
>> you have basically two different dev environments: a calculation-heavy one 
>> (where speed is important) in C++, C, etc and one that is increasingly in 
>> Python to provide an abstraction to that lower level.  Julia seems to be a 
>> perfect fit for eliminating the myriad issues one can encounter with this 
>> bifurcated dev setup.
>>
>> The package itself is located here: https://github.com/pazzo83/JQuantLib
>>
>> There is a bond pricing (NPV) example in the readme itself, and further 
>> examples in the examples folder (these are under development still).  I am 
>> continuing to work on this and add to it, but I'd love some feedback!  I'm 
>> still relatively new to Julia, but working on this has definitely improved 
>> my fluency of the language.
>>
>> Thanks!
>>
>> Chris
>>
>

[julia-users] QuantLib in Julia: JQuantLib (very very alpha stage at this point!)

[Christopher Alexander]

Hello all, I'd like to point people in the direction of a package I've been 
working on: JQuantLib, to get some feedback.  Basically, I am trying to 
write a version of the very popular open-source quantitative finance 
library QuantLib in pure Julia.  The library itself is written in C++, but 
it is commonly used in Python (via SWIG).  I thought this would be a first 
attempt at trying to solve a common problem in many financial firms where 
you have basically two different dev environments: a calculation-heavy one 
(where speed is important) in C++, C, etc and one that is increasingly in 
Python to provide an abstraction to that lower level.  Julia seems to be a 
perfect fit for eliminating the myriad issues one can encounter with this 
bifurcated dev setup.

The package itself is located here: https://github.com/pazzo83/JQuantLib

There is a bond pricing (NPV) example in the readme itself, and further 
examples in the examples folder (these are under development still).  I am 
continuing to work on this and add to it, but I'd love some feedback!  I'm 
still relatively new to Julia, but working on this has definitely improved 
my fluency of the language.

Thanks!

Chris

Re: [julia-users] Using operator 'for' in loops with removing elements.

[Christopher Alexander]

Sorry a bit off topic, but when you say anon functions are "fixed" in 0.5, 
does that mean they have the same performance as defined functions (like if 
you passed some defined function to filter for example)?

On Tuesday, February 9, 2016 at 11:37:36 AM UTC-5, Milan Bouchet-Valat 
wrote:
>
> Le mardi 09 février 2016 à 08:04 -0800, Aleksandr Mikheev a écrit : 
> > Hi everyone.  
> > 
> > Suppose I have the array called a. And I need to check all of its 
> > ellements on the some condition. Further, I need to remove those 
> > ellements which satisfy the condition. I know I can do this using 
> > operator 'while'. Something like this: 
> > 
> > i = 0 
> > while (i < length(a)) 
> > i = i + 1 
> > if (condition on a[i]) 
> > splice!(a, i) 
> > i = i - 1 
> > end 
> > end 
> > 
> > But I've heard that using operator 'while' is quite slower than using 
> > 'for'-loop. So is there any better way to do what I need to do? 
> I don't know where you've heard that, but that's wrong in general. In 
> the present case, what's likely going to be slow is removing elements 
> one-by-one, which involves moving all following elements repeatedly. A 
> faster strategy would be to copy elements to retain, which is what 
> filter!() does in Base: 
> https://github.com/JuliaLang/julia/blob/4895ef64fb1a3c2f0ac3e073b2f236f 
> 5e603d536/base/array.jl#L870 
> 
>  
>
> You can use filter!() instead of writing the loop yourself. For 
> example, if the condition is > 1, do: 
> a = [1, 2, 3] 
> filter!(x->x > 1, a) 
>
> But anonymous functions are slow in 0.4 (fixed in 0.5), so you would need 
> to do: 
> f(x) = x > 1 
> filter!(f, a) 
>
>
> You can also use indexing if you don't mind taking a copy: 
> cond = Bool[x > 1 for x in a] 
> a[cond] 
>
> Finally, if the condition only involves arithmetic operators with 
> element-wise versions, you can also write: 
> a[a .> 1] 
>
>
>
> Regards 
>

Re: [julia-users] Re: Nullable{Date}

[Christopher Alexander]

Why couldn't you do something like this?  It is type stable:

using Base.Dates
leapDay = isleapyear(yr) ? Date(yr, 2, 29) : Date()

if leapDay != Date()
   doy = dayofyear( leapDay )
end

Again, Date() returns this: *0001-01-01*

It works nicely as a "null" date.

Chris

On Tuesday, February 9, 2016 at 11:28:51 PM UTC-5, Michael Landis wrote:
>
> missed a paren above (for the people that are going to past the code into 
> a shell and try it out) - something that I am not doing.  Still, this is 
> closer:
>
> # wishful thinking...
> using Dates;
> leapDay = isleapyear(yr) ? Date(yr,2,29) : nothing
> if ! leapDay
>   doy = dayofyear( leapDay )
>   ...   clean and concise (thought that was the point), but we get
>
> leapDay = isleapyear (yr)?  Nullable {Date} (Date (yr, 2:29)): Nullable 
> {Date} ()
> if ! isnull( leapDay )
>   doy = dayofyear( get(leapDay) )
>
> On Tue, Feb 9, 2016 at 8:22 PM, Michael Landis  > wrote:
>
>> # wishful thinking...
>> using Dates;
>> leapDay = isleapyear(yr) ? Date(yr,2,29) : nothing
>> if ! leapDay
>>   dow = dayofyear( leapDay )
>>   ...   clean and concise (thought that was the point), but we get
>>
>> leapDay = isleapyear(yr) ? Nullable{Date}( Date(yr,2,29) : 
>> Nullable{Date}()
>> if ! isnull( leapDay )
>>   dow = dayofyear( get(leapDay) )
>>   ...
>>
>> If I am dumb enough to forget to check for a null date, I deserve the 
>> exception - the code would be wrong.  Making me type two or three times as 
>> many characters, obscuring what is actually going on, ... all to eliminate 
>> NullPointerExceptions?  I have to write exception free code anyway, so all 
>> I have 'gained' is a lot of superfluous verbosity.  I'm going to side with 
>> salience over verbosity every time.  The type safe argument just doesn't 
>> sell me, sorry.
>>
>
>

[julia-users] Re: Nullable{Date}

[Christopher Alexander]

I really like that construction!

On Monday, February 8, 2016 at 10:49:41 PM UTC-5, Greg Plowman wrote:
>
> If only Nullables can be null, could we formally define this?
>
> isnull(x::Nullable) = x.isnull # already defined in nullable.jl
> isnull(x) = false  # extra definition for everything else
>
>
>
>> isnull( lp15 ) --> true
>> isnull( lp16 ) -->  MethodError: `isnull` has no method matching isnull( 
>> ::Date )
>>
>
>

[julia-users] Re: Nullable{Date}

[Christopher Alexander]

For a null date, I usually just use Date() (Dates.Date()), which returns 
Jan 1, 0001.  Also, you know that there is already a method to check 
whether or not a year is a leap year right? 

Dates.isleapyear(y), returns a Bool. 
 http://docs.julialang.org/en/release-0.4/manual/dates/

On Monday, February 8, 2016 at 10:08:25 PM UTC-5, Michael Landis wrote:
>
> I'm so confused
>
> I thought this would be cool:
> isLeapYr(yr::Int64) = yr % 400 == 0  ||  (yr % 4 == 0  &&  yr % 100 != 0)
> LeapDay(yr) = isLeapYr(yr) ? Date(yr,2,29) : Nullable{Date}()
>
> lp15 = LeapDay(2015) --> Nullable{Date}()
> lp16 = LeapDay(2016) --> 2016-02-29
>
> no surprises there, but when I test the return values ...
>
> isnull( lp15 ) --> true
> isnull( lp16 ) -->  MethodError: `isnull` has no method matching isnull( 
> ::Date )
>
> What IS the secret Nullable{Date} formulation?
>

[julia-users] Re: associating outer constructors with different names with a type

[Christopher Alexander]

Instead of having the name be ASCIIString, you could have that be another 
type like SomeTypeName, (which then has the string "A" or "B" as an 
attribute).  Then you could do a type alias to map TypeA to 
SomeType{SomeTypeA} and TypeB to SomeType{SomeTypeB} assuming SomeTypeA and 
SomeTypeB are types that extend an abstract type SomeTypeName.

For example, I have something like this in one of my projects:

abstract ModelType
abstract Model

# model types
type AffineModelType <: ModelType end
type TermStructureConsistentModelType <: ModelType end

# type aliases
typealias AffineModel Model{AffineModelType}
typealias TermStructureConsistentModel 
Model{TermStructureConsistentModelType}

Someone else feel free to chime in if this isn't really the best way, as 
I'm still learning too!

Chris

On Friday, February 5, 2016 at 4:16:24 PM UTC-5, Uri Patish wrote:
>
> Hi,
>
> I was wondering what is the best way going about the following issue. 
> Suppose I have a type with few outer constructors which I name differently, 
> and I want Julia to recognize these functions as constructors of that type. 
> For example
>
> type SomeType <: SomeAbstract
>   name::ASCIIString
>   value::Int
> end
>
> TypeA(value::Int) = SomeType("A", value)
> TypeB(value::Int) = SomeType("B", value)
>
> In this case, I have two pseudo-types, TypeA and TypeB, which have the 
> same structure and are only different by their state. The problem with this 
> approach is that now TypeA and TypeB are functions and not datatypes, thus, 
> I cannot use operations defined on datetypes like checking for subtyping 
> (TypeA 
> <: SomeAbstract), or overloading type construction using call. 
>
> Clearly, I could have defined two types which have exactly the same 
> structure but this seems wrong to me as it involes code replication. 
> Another possible solution is to define a macro which defines the type and 
> its outer constructor, and I would call the macro to define TypeA and 
> TypeB. Nonetheless, I was wondering if there was a way to tell Julia that 
> the functions TypeA and TypeB are in fact constructors of SomeType. I'd be 
> glag to hear about other solutions as well. 
>
> Uri
>
>
>

[julia-users] Parametric Types with Incomplete Initialization

[Christopher Alexander]

Let's say I have the following types:

abstract ABC

type A <: ABC
a::Float64
end

type B{T <: ABC}
a::T
end

In some cases, I need for type "B" to be incompletely initialized so that I 
can define its parameter "a" later.  I've found out that you can do 
something like this:

type B{T <: ABC}
a::T

call(::Type{B}) = new{ABC}()
end

which then allows this:

julia> myB = B()
B{ABC}(#undef)

My question is, I'm assuming you lose any of the performance gain by using 
the parametric type in this case because you are still using the abstract 
type "ABC" for the parameter "a" (even if you define it later with a 
concrete "A").   Is there a better way to do this?

Thanks!

Chris

Re: [julia-users] Parametric Types with Incomplete Initialization

[Christopher Alexander]

Oh cool!  I was worried, since my call method was passing in the abstract 
type if none was specified (ie I wasn't setting a value for the param "a"), 
that it would just be the same as if I hadn't used a parametric type at all 
and just set the type of "a" to the abstract type.

Thanks!

Chris

On Thursday, February 4, 2016 at 11:50:07 AM UTC-5, Kevin Squire wrote:
>
> No, `a` is the (concrete) type `T`, which is a subtype of `ABC` (and a new 
> type `B{T}` is created for each `T`).  So you shouldn't lose performance 
> because of this.
>
> Cheers,
>Kevin
>
> On Thu, Feb 4, 2016 at 8:10 AM, Christopher Alexander <uvap...@gmail.com 
> > wrote:
>
>> Let's say I have the following types:
>>
>> abstract ABC
>>
>> type A <: ABC
>> a::Float64
>> end
>>
>> type B{T <: ABC}
>> a::T
>> end
>>
>> In some cases, I need for type "B" to be incompletely initialized so that 
>> I can define its parameter "a" later.  I've found out that you can do 
>> something like this:
>>
>> type B{T <: ABC}
>> a::T
>> 
>> call(::Type{B}) = new{ABC}()
>> end
>>
>> which then allows this:
>>
>> julia> myB = B()
>> B{ABC}(#undef)
>>
>> My question is, I'm assuming you lose any of the performance gain by 
>> using the parametric type in this case because you are still using the 
>> abstract type "ABC" for the parameter "a" (even if you define it later with 
>> a concrete "A").   Is there a better way to do this?
>>
>> Thanks!
>>
>> Chris
>>
>
>

Re: [julia-users] Parametric Types with Incomplete Initialization

[Christopher Alexander]

That's interesting, I can reproduce that exactly.  However, when I set the 
"a" attribute for A as being Float64, they are both size 8:

abstract ABC

immutable A2 <: ABC
a::Float64
end

julia> bA2, bABC2 = B{A2}(A2(1)), B{ABC}(A2(2))
(B{A2}(A2(1.0)),B{ABC}(A2(2.0)))

julia> sizeof(bA2), sizeof(bABC2)
(8,8)





On Thursday, February 4, 2016 at 2:56:46 PM UTC-5, Josh Langsfeld wrote:
>
> I may be mistaken, but I think setting the type parameter to be abstract 
> is indeed the same as setting the field itself to be abstract. This snippet 
> is my evidence:
>
> julia> abstract ABC
>
> julia> immutable A <: ABC
>  a::Float32
>end
>
> julia> type B{T<:ABC}
>  a::T
>end
>
> julia> bA, bABC = B{A}(A(1)), B{ABC}(A(2))
> (B{A}(A(1.0f0)),B{ABC}(A(2.0f0)))
>
> julia> sizeof(bA), sizeof(bABC)
> (4,8)
>
> Even though both 'B' objects contain an 'A' immutable, bABC keeps it as a 
> pointer (size 8) whereas bA can directly unpack it into the definition.
>
>
> On Thursday, February 4, 2016 at 1:59:17 PM UTC-5, Christopher Alexander 
> wrote:
>>
>> Oh cool!  I was worried, since my call method was passing in the abstract 
>> type if none was specified (ie I wasn't setting a value for the param "a"), 
>> that it would just be the same as if I hadn't used a parametric type at all 
>> and just set the type of "a" to the abstract type.
>>
>> Thanks!
>>
>> Chris
>>
>> On Thursday, February 4, 2016 at 11:50:07 AM UTC-5, Kevin Squire wrote:
>>>
>>> No, `a` is the (concrete) type `T`, which is a subtype of `ABC` (and a 
>>> new type `B{T}` is created for each `T`).  So you shouldn't lose 
>>> performance because of this.
>>>
>>> Cheers,
>>>Kevin
>>>
>>> On Thu, Feb 4, 2016 at 8:10 AM, Christopher Alexander <uvap...@gmail.com
>>> > wrote:
>>>
>>>> Let's say I have the following types:
>>>>
>>>> abstract ABC
>>>>
>>>> type A <: ABC
>>>> a::Float64
>>>> end
>>>>
>>>> type B{T <: ABC}
>>>> a::T
>>>> end
>>>>
>>>> In some cases, I need for type "B" to be incompletely initialized so 
>>>> that I can define its parameter "a" later.  I've found out that you can do 
>>>> something like this:
>>>>
>>>> type B{T <: ABC}
>>>> a::T
>>>> 
>>>> call(::Type{B}) = new{ABC}()
>>>> end
>>>>
>>>> which then allows this:
>>>>
>>>> julia> myB = B()
>>>> B{ABC}(#undef)
>>>>
>>>> My question is, I'm assuming you lose any of the performance gain by 
>>>> using the parametric type in this case because you are still using the 
>>>> abstract type "ABC" for the parameter "a" (even if you define it later 
>>>> with 
>>>> a concrete "A").   Is there a better way to do this?
>>>>
>>>> Thanks!
>>>>
>>>> Chris
>>>>
>>>
>>>

[julia-users] Re: Elapsed CPU time in Julia?

[Christopher Alexander]

Try doing something like:

tic()
# my code
toc()

On Wednesday, February 3, 2016 at 3:28:28 PM UTC-5, Lytu wrote:
>
> Hello Julia users,
>
> Can someone tell me what's the equivalent of matlab elapsed cputime in 
> Julia
>
> For example i Matlab, we can do this:
>
>t = cputime;
>x=4;
>
>iter = 1; 
>
>z = ones(1,4);
>
>y=x*2*z;
>
> e = cputime-t
>
>
> But in Julia i don't seem to find how to do this. I thought i can use 
>
>t=time()
>
>x=4;
>
>iter = 1; 
>
>z = ones(1,4);
>
>y=x*2*z;
>
>e=time()-t
>
>
> But time() in Julia is not the elapsed CPU time, it's a wall clock time.
>
>
> Can someone help me?
>
>
> Thank you
>
>

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 <maur...@runbox.com > 
> 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 <uvap...@gmail.com 
> > 
> >> 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 
>

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

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

[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 <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> 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] am i prepared for the arraypocalypse?

[Christopher Alexander]

What is the arraypocalypse?

On Tuesday, February 2, 2016 at 1:28:26 AM UTC-5, Mauro wrote:
>
> > my tests run smoothly in the current build of julia 0.5 beta. Is 
> everything 
> > good or are there breaking changes to come? 
>
> There are always breaking changes to come on Master... that's the point 
> of Master.   Expect more to come, as the arraypocalypse has not happened 
> yet (nor it is quite clear how it will happen). 
>

[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

[julia-users] Re: Optimizing Function Injection in Julia

[Christopher Alexander]

Yea, can someone explain the proper syntax here?  What would be the case if 
I wanted to build a callable type?  What if I want to do something like 
this?

call{T <: MyAbstractType)(t::T, a::Int) = t.a + a

Thanks!

Chris

On Sunday, January 31, 2016 at 4:27:00 AM UTC-5, Bryan Rivera wrote:
>
> I just realized #13412  has 
> been merged.
>
> What should this look like now that `Base.call(...)` is deprecated?
>
> Thinking something like:
>
> (_::SomeCallBack)(c) = _.z + c
>
>
> On Sunday, January 31, 2016 at 3:47:03 AM UTC-5, Bryan Rivera wrote:
>>
>> Cedric, I refactored the problem and this works well.
>>
>> What do you mean "I would favor using a regular function call with a 
>> descriptive name"?
>>
>> I was thinking replace `Base.call` with a function name.  But that does 
>> not work if the function is in the top-level scope in another file.
>>
>> On Thursday, January 21, 2016 at 9:56:51 PM UTC-5, Cedric St-Jean wrote:
>>>
>>> Something like this?
>>>
>>> function function1(a, b, f) # Variable needed in callback fun injected.
>>> if(a > b)
>>>   c = a + b
>>>   res = f(c) # Callback function has been injected.
>>>   return res + 1
>>> else
>>>   # do anything
>>>   # but return nothing
>>> end
>>> end
>>>
>>> type SomeCallBack
>>> z::Int
>>> end
>>> Base.call(callback::SomeCallBack, c) = c + callback.z
>>>
>>> function1(2, 1, SomeCallBack(10))
>>>
>>> Because of JIT, this is 100% equivalent to your "callback function has 
>>> been injected" example, performance-wise. My feeling is that .call 
>>> overloading is not to be abused in Julia, so I would favor using a regular 
>>> function call with a descriptive name instead of call overloading, but the 
>>> same performance guarantees apply. Does that answer your question?
>>>
>>> On Thursday, January 21, 2016 at 9:02:50 PM UTC-5, Bryan Rivera wrote:

 I think what I wrote above might be too complicated, as it is an 
 attempt to solve this problem.

 In essence this is what I want: 



 function function1(a, b, onGreaterThanCallback)
   if(a > b)
 c = a + b
 res = onGreaterThanCallback(c, z)
 return res + 1
   else
 # do anything
 # but return nothing
   end
 end


 global onGreaterThanCallback = (c) -> c + z

 function1(a, b, onGreaterThanCallback)


 Problems:

 The global variable.

 The anonymous function which has performance impact (vs other 
 approaches).  We could use Tim Holy's @anon, but then the value of `z` is 
 fixed at function definition, which we don't always want.

 I think that the ideal optimization would look like this:

   function function1(a, b, z) # Variable needed in callback fun 
 injected.
 if(a > b)
   c = a + b
   res = c + z # Callback function has been injected.
   return res + 1
 else
   # do anything
   # but return nothing
 end
   end


   function1(a, b, z)

 In OO languages we would be using an abstract class or its equivalent. 
  But I've thought about it, and read the discussions on interfaces, and 
 don't see those solutions optimizing the code out like I did above.

 Any ideas?

>>>

[julia-users] Re: SharedArray / parallel question

[Christopher Alexander]

Is this something that would really only be solved by proper 
multi-threading?

On Saturday, January 30, 2016 at 12:49:50 PM UTC-5, Christopher Alexander 
wrote:
>
> I can confirm that I do not see the seg fault issue in 0.5 (the latest 
> master), but I am getting fundamentally different results when using the 
> @sync @parallel construction.  In essence, @sync @parallel is causing 
> arrays of different values (compared to using a non-parallelized 
> construction) to be built, which is causing an issue further along in my 
> program.  It is also much slower, so I am wondering if I my syntax is 
> incorrect.
>
> Any input would be appreciated.  You can see what is supposed to be 
> generated by loading this script (
> https://github.com/pazzo83/QuantJulia.jl/blob/master/swaption_test_code.jl) 
> and calling main().
>
> Thanks!
>
> On Saturday, January 30, 2016 at 4:48:51 AM UTC-5, Lutfullah Tomak wrote:
>>
>> There is this issue on on github 
>> https://github.com/JuliaLang/julia/issues/14764 . I am no expert about 
>> parallel computing but may be related.
>>
>> Regards
>>
>

Re: [julia-users] Embarrassingly parallel workload

[Christopher Alexander]

I have tried the construction below with no success.  In v0.4.3, I end up 
getting a segmentation fault.  In the latest v.0.5.0, the run time is 3-4x 
as long as the non-parallelized version and the array constructed is vastly 
different than the one that is constructed using the non-parallelized code. 
 Below is the C++ code that I am essentially trying to emulate:

void TreeLattice::stepback(Size i, const Array& values,

 Array& newValues) const {

#pragma omp parallel for

for (Size j=0; jimpl().size(i); j++) {

Real value = 0.0;

for (Size l=0; limpl().probability(i,j,l) *

 values[this->impl().descendant(i,j,l)];

}

value *= this->impl().discount(i,j);

newValues[j] = value;

}

}

The calls to probability, descendant, and discount all end up accessing 
data in other objects, so I tried to prepend those function and type 
definitions with @everywhere.  However, that started me on a long chain of 
having to eventually wrap each file in my module in @everywhere, and there 
were still errors complaining about things not being defined.  At this 
point I am really confused as to how to construct what would appear to be a 
rather simple parallelized for loop that generates the same results as 
non-parallelized code.  I've poured over both this forum and other 
resources, and nothing has really worked.

Any help would be appreciated.

Thanks!

Chris


On Thursday, August 20, 2015 at 4:52:52 AM UTC-4, Nils Gudat wrote:
>
> Sebastian, I'm not sure I understand you correctly, but point (1) in your 
> list can usually be taken care of by wrapping all the necessary 
> usings/requires/includes and definitions in a @everywhere begin ... end 
> block.
>
> Julio, as for your original problem, I think Tim's advice about 
> SharedArrays was perfectly reasonable. Without having looked at your 
> problem in detail, I think you should be able to do something like this 
> (and I also think this gets close enough to what Sebastian was talking 
> about, and to Matlab's parfor, unless I'm completely misunderstanding your 
> problem):
>
> nprocs()==CPU_CORES || addprocs(CPU_CORES-1)
> results = SharedArray(Float64, (m,n))
>
> @sync @parallel for i = 1:n
> results[:, i] = complicatedfunction(inputs[i])
> end
>

Re: [julia-users] Embarrassingly parallel workload

[Christopher Alexander]

By "construction below", I mean this:

results = SharedArray(Float64, (m,n))

@sync @parallel for i = 1:n
results[:, i] = complicatedfunction(inputs[i])
end

On Saturday, January 30, 2016 at 2:31:40 PM UTC-5, Christopher Alexander 
wrote:
>
> I have tried the construction below with no success.  In v0.4.3, I end up 
> getting a segmentation fault.  In the latest v.0.5.0, the run time is 3-4x 
> as long as the non-parallelized version and the array constructed is vastly 
> different than the one that is constructed using the non-parallelized code. 
>  Below is the C++ code that I am essentially trying to emulate:
>
> void TreeLattice::stepback(Size i, const Array& values,
>
>  Array& newValues) const {
>
> #pragma omp parallel for
>
> for (Size j=0; jimpl().size(i); j++) {
>
> Real value = 0.0;
>
> for (Size l=0; l<n_; l++) {
>
> value += this->impl().probability(i,j,l) *
>
>  values[this->impl().descendant(i,j,l)];
>
> }
>
> value *= this->impl().discount(i,j);
>
> newValues[j] = value;
>
> }
>
> }
>
> The calls to probability, descendant, and discount all end up accessing 
> data in other objects, so I tried to prepend those function and type 
> definitions with @everywhere.  However, that started me on a long chain of 
> having to eventually wrap each file in my module in @everywhere, and there 
> were still errors complaining about things not being defined.  At this 
> point I am really confused as to how to construct what would appear to be a 
> rather simple parallelized for loop that generates the same results as 
> non-parallelized code.  I've poured over both this forum and other 
> resources, and nothing has really worked.
>
> Any help would be appreciated.
>
> Thanks!
>
> Chris
>
>
> On Thursday, August 20, 2015 at 4:52:52 AM UTC-4, Nils Gudat wrote:
>>
>> Sebastian, I'm not sure I understand you correctly, but point (1) in your 
>> list can usually be taken care of by wrapping all the necessary 
>> usings/requires/includes and definitions in a @everywhere begin ... end 
>> block.
>>
>> Julio, as for your original problem, I think Tim's advice about 
>> SharedArrays was perfectly reasonable. Without having looked at your 
>> problem in detail, I think you should be able to do something like this 
>> (and I also think this gets close enough to what Sebastian was talking 
>> about, and to Matlab's parfor, unless I'm completely misunderstanding your 
>> problem):
>>
>> nprocs()==CPU_CORES || addprocs(CPU_CORES-1)
>> results = SharedArray(Float64, (m,n))
>>
>> @sync @parallel for i = 1:n
>> results[:, i] = complicatedfunction(inputs[i])
>> end
>>
>

[julia-users] Re: SharedArray / parallel question

[Christopher Alexander]

I can confirm that I do not see the seg fault issue in 0.5 (the latest 
master), but I am getting fundamentally different results when using the 
@sync @parallel construction.  In essence, @sync @parallel is causing 
arrays of different values (compared to using a non-parallelized 
construction) to be built, which is causing an issue further along in my 
program.  It is also much slower, so I am wondering if I my syntax is 
incorrect.

Any input would be appreciated.  You can see what is supposed to be 
generated by loading this script 
(https://github.com/pazzo83/QuantJulia.jl/blob/master/swaption_test_code.jl) 
and calling main().

Thanks!

On Saturday, January 30, 2016 at 4:48:51 AM UTC-5, Lutfullah Tomak wrote:
>
> There is this issue on on github 
> https://github.com/JuliaLang/julia/issues/14764 . I am no expert about 
> parallel computing but may be related.
>
> Regards
>

[julia-users] Re: SharedArray / parallel question

[Christopher Alexander]

I tried using @sync @parallel and ended up getting a segmentation fault, so 
I'm not really sure how to parallelize this loop.  This is inside of a 
larger module, so I'm not sure if something special has to be done (e.g. 
putting @everywhere somewhere).  I've searched this forum and the 
documentation, which is where I got the idea to add @sync.  I'd appreciate 
any input, as I'm kind of stuck.  The larger code in which this 
parallelization should take place is here:
https://github.com/pazzo83/QuantJulia.jl/blob/master/src/methods/lattice.jl

Thanks!

Chris

On Friday, January 29, 2016 at 4:54:18 PM UTC-5, Christopher Alexander 
wrote:
>
> Hello all, I have a question about the proper usage of SharedArray / 
> @parallel.  I am trying to use it in a particular part of my code, but I am 
> not getting the expected results (instead I am getting an array of zeros 
> each time).
>
> Here are the two functions that are involved:
> function partial_rollback!(lattice::TreeLattice, asset::DiscretizedAsset, 
> t::Float64)
>   from = asset.common.time
>
>   if QuantJulia.Math.is_close(from, t)
> return
>   end
>
>   iFrom = findfirst(lattice.tg.times .>= from)
>   iTo = findfirst(lattice.tg.times .>= t)
>
>   @simd for i = iFrom-1:-1:iTo
> newVals = step_back(lattice, i, asset.common.values)
> @inbounds asset.common.time = lattice.tg.times[i]
> asset.common.values = sdata(newVals)
> 
> if i != iTo
>   adjust_values!(asset)
> end
>   end
>
>   return asset
> end
>
> function step_back(lattice::TreeLattice, i::Int, vals::Vector{Float64})
>
>   newVals = SharedArray(Float64, get_size(lattice.impl, i))
>   @parallel for j = 1:length(newVals)
> val = 0.0
> for l = 1:lattice.n
>   val += probability(lattice.impl, i, j, l) * 
> vals[descendant(lattice.impl, i, j, l)]
> end
> val *= discount(lattice.impl, i, j)
> newVals[j] = val
>   end
>   retArray = sdata(newVals)
>   
>   return retArray
> end
>
> Is that to much complexity in the parallel loop?  Right now the max # of 
> times I've seen over this loop is in the 9000+ range, so that's why I 
> thought it would be better than pmap.
> Any suggestions?
>
> Thanks!
>
> Chris
>

[julia-users] SharedArray / parallel question

[Christopher Alexander]

Hello all, I have a question about the proper usage of SharedArray / 
@parallel.  I am trying to use it in a particular part of my code, but I am 
not getting the expected results (instead I am getting an array of zeros 
each time).

Here are the two functions that are involved:
function partial_rollback!(lattice::TreeLattice, asset::DiscretizedAsset, 
t::Float64)
  from = asset.common.time

  if QuantJulia.Math.is_close(from, t)
return
  end

  iFrom = findfirst(lattice.tg.times .>= from)
  iTo = findfirst(lattice.tg.times .>= t)

  @simd for i = iFrom-1:-1:iTo
newVals = step_back(lattice, i, asset.common.values)
@inbounds asset.common.time = lattice.tg.times[i]
asset.common.values = sdata(newVals)

if i != iTo
  adjust_values!(asset)
end
  end

  return asset
end

function step_back(lattice::TreeLattice, i::Int, vals::Vector{Float64})

  newVals = SharedArray(Float64, get_size(lattice.impl, i))
  @parallel for j = 1:length(newVals)
val = 0.0
for l = 1:lattice.n
  val += probability(lattice.impl, i, j, l) * 
vals[descendant(lattice.impl, i, j, l)]
end
val *= discount(lattice.impl, i, j)
newVals[j] = val
  end
  retArray = sdata(newVals)
  
  return retArray
end

Is that to much complexity in the parallel loop?  Right now the max # of 
times I've seen over this loop is in the 9000+ range, so that's why I 
thought it would be better than pmap.
Any suggestions?

Thanks!

Chris

Re: [julia-users] Re: Julia Vector declare/load confusion

[Christopher Alexander]

Milan,

Thanks for this!  That is quite a difference, I might be making some 
changes to my code!

Chris

On Thursday, January 28, 2016 at 5:36:07 AM UTC-5, Milan Bouchet-Valat 
wrote:
>
> Le mercredi 27 janvier 2016 à 22:37 -0800, Christopher Alexander a 
> écrit : 
> > Try something like this: 
> > 
> > adjCloseMuVec = Vector{Float32}(nFullYears) 
> > or 
> > adjCloseMuVec = zeros(Float32, nFullYears) 
> > 
> > This will init a vector of the proper size.  I think zeros is 
> > slightly faster, but someone can correct me if that is not the case. 
> Actually that's the other way around. zeros() is slower because it 
> needs to fill the array with zeros. You can check this with some very 
> simple benchmarking: 
>
> julia> f() = for i in 1:10 adjCloseMuVec = Vector{Float32}(1) end 
> f (generic function with 1 method) 
>
> julia> g() = for i in 1:10 adjCloseMuVec = zeros(Float32, 1) end 
> g (generic function with 1 method) 
>
> julia> @time f() 
>   0.164794 seconds (202.00 k allocations: 3.731 GB, 52.40% gc time) 
>
> julia> @time f() 
>   0.135390 seconds (200.00 k allocations: 3.731 GB, 52.57% gc time) 
>
> julia> @time g() 
>   1.184917 seconds (201.75 k allocations: 3.731 GB, 10.57% gc time) 
>
> julia> @time g() 
>   1.175267 seconds (200.00 k allocations: 3.731 GB, 10.38% gc time) 
>
>
> This overhead could be reduced/eliminated by using calloc, and could 
> even become the default, see 
> https://github.com/JuliaLang/julia/issues/9147 
>
> Given how high is the overhead, it looks like that change would be a 
> good idea. 
>
>
> Regards 
>
>
> > Chris 
> > 
> > On Thursday, January 28, 2016 at 1:26:09 AM UTC-5, Michael Landis 
> > wrote: 
> > > I am trying to compute some historical means and volatilities with 
> > > Julia, but I've been having some difficulty getting the 
> > > declarations and/or assignments right... 
> > > 
> > > When I try a declaration, like either of these: 
> > >   adjCloseMuVec::Vector{Float32}; # or... 
> > >   adjCloseMuVec::Vector{Float32,nFullYears}; 
> > > I get:  UndefVarError: adjCloseMuVec not defined 
> > >   
> > > When I try: 
> > > adjCloseMuVec = Vector{Float32};   # and later try: 
> > > reshape(adjCloseMuVec,nFullYears); 
> > > I get:  MethodError: `reshape` has no method matching 
> > > reshape(::Type{Array{Float32,1}}, ::Int32) 
> > > 
> > > When I try: 
> > > adjCloseMuVec = Vector{Float32,nFullYears}; 
> > > I get: too many parameters for type typealias 
> > > 
> > > So, the only acceptable path would seem to be: 
> > > adjCloseMuVec = Vector{Float32}; 
> > > but when I later try: 
> > > adjCloseMuVec[curYr] = Float32(adjCloseMu);   # or... 
> > > setindex!(adjCloseMuVec, Float32(adjCloseMu), curYr); 
> > > I get: MethodError: `setIndex!` has no method matching 
> > > setindex!(::Type{Array{Float32,1}}, ::Float32, ::Int64) 
> > > 
> > > So, I'm mystified as to the correct syntax.  Any suggestions on an 
> > > acceptable way to declare a Vector of Int32 and load values into 
> > > it? 
> > > 
>

[julia-users] Re: DateTime business days, Wall Street days, ...

[Christopher Alexander]

I have some code (based somewhat on both Ito and BusinessDays), that is 
part of a larger Quantlib implementation that I'm working on in Julia, 
which deals with business days.  You can check it out here:

https://github.com/pazzo83/QuantJulia.jl/blob/995954bb64389c746f38a7b0c6c4b9ed1ed2963e/src/time/BusinessCalendar.jl

On Thursday, January 28, 2016 at 9:52:38 AM UTC-5, Michael Landis wrote:
>
> Maybe I'm missing something, but the one thing I want from DateTime is the 
> ability to determine whether a day has elapsed since a file modify date, 
> but not just a calendar day... at least a business day (i.e. Saturdays and 
> Sundays don't count), but even better if a calendar could skip past 
> government and/or business holidays too, so elapsed days are only the 
> meaningful ones, weekends and business holidays would not increment a 
> business days elapsed counter.
>
> For example, if you have downloaded daily closing stock prices at 8PM on 
> Friday the 29th of January, there's no point in downloading them again 
> until after the close of trading Monday, February 1st, but if you 
> originally downloaded them at 2PM on Friday the 29th of January, you will 
> get one more result by downloading them again at 8PM that same day.  It 
> gets even more interesting when you throw time zone into the mix.  The 
> markets are still actively trading at 6:30 PM Pacific Time.  Need DateTime 
> functions that will aid in making those decisions.  Is this being 
> considered for Julia and if not, should it be?
>

[julia-users] Re: DateTime business days, Wall Street days, ...

[Christopher Alexander]

I have some code (based somewhat on both Ito and BusinessDays), that is 
part of a larger Quantlib implementation I'm working on in Julia, which 
deals with business days and various financial calendars (so far just US 
and UK).  You can check it out here:

https://github.com/pazzo83/QuantJulia.jl/blob/master/src/time/BusinessCalendar.jl

On Thursday, January 28, 2016 at 9:52:38 AM UTC-5, Michael Landis wrote:
>
> Maybe I'm missing something, but the one thing I want from DateTime is the 
> ability to determine whether a day has elapsed since a file modify date, 
> but not just a calendar day... at least a business day (i.e. Saturdays and 
> Sundays don't count), but even better if a calendar could skip past 
> government and/or business holidays too, so elapsed days are only the 
> meaningful ones, weekends and business holidays would not increment a 
> business days elapsed counter.
>
> For example, if you have downloaded daily closing stock prices at 8PM on 
> Friday the 29th of January, there's no point in downloading them again 
> until after the close of trading Monday, February 1st, but if you 
> originally downloaded them at 2PM on Friday the 29th of January, you will 
> get one more result by downloading them again at 8PM that same day.  It 
> gets even more interesting when you throw time zone into the mix.  The 
> markets are still actively trading at 6:30 PM Pacific Time.  Need DateTime 
> functions that will aid in making those decisions.  Is this being 
> considered for Julia and if not, should it be?
>

[julia-users] Re: Julia Vector declare/load confusion

[Christopher Alexander]

Try something like this:

adjCloseMuVec = Vector{Float32}(nFullYears)
or
adjCloseMuVec = zeros(Float32, nFullYears)

This will init a vector of the proper size.  I think zeros is slightly 
faster, but someone can correct me if that is not the case.

Chris

On Thursday, January 28, 2016 at 1:26:09 AM UTC-5, Michael Landis wrote:
>
> I am trying to compute some historical means and volatilities with Julia, 
> but I've been having some difficulty getting the declarations and/or 
> assignments right...
>
> When I try a declaration, like either of these:
>   adjCloseMuVec::Vector{Float32}; # or...
>   adjCloseMuVec::Vector{Float32,nFullYears};
> I get:  UndefVarError: adjCloseMuVec not defined
>  
> When I try:
> adjCloseMuVec = Vector{Float32};   # and later try:
> reshape(adjCloseMuVec,nFullYears);
> I get:  MethodError: `reshape` has no method matching 
> reshape(::Type{Array{Float32,1}}, ::Int32)
>
> When I try:
> adjCloseMuVec = Vector{Float32,nFullYears};
> I get: too many parameters for type typealias
>
> So, the only acceptable path would seem to be:
> adjCloseMuVec = Vector{Float32};
> but when I later try:
> adjCloseMuVec[curYr] = Float32(adjCloseMu);   # or...
> setindex!(adjCloseMuVec, Float32(adjCloseMu), curYr);
> I get: MethodError: `setIndex!` has no method matching 
> setindex!(::Type{Array{Float32,1}}, ::Float32, ::Int64)
>
> So, I'm mystified as to the correct syntax.  Any suggestions on an 
> acceptable way to declare a Vector of Int32 and load values into it?
>

[julia-users] Re: Cannot pull with rebase when I try to use Pkg.update()

[Christopher Alexander]

This is basically identical to a very recent issue on 
here: https://groups.google.com/forum/#!topic/julia-users/3Hpll3j48Rg

That issue also involved the FixedEffectModels package, so maybe it's an 
issue with that?

Chris

On Friday, January 22, 2016 at 7:30:34 PM UTC-5, Diogo Falcão wrote:
>
> I am trying to use Julia on Windows for the first time, and when I try to 
> run Pkg.update(), I got this error:
>
> error: Cannot pull with rebase: You have unstaged changes.
>
>
> When I run "git status" in the METADATA folder, I got:
>
>
> On branch metadata-v2
> Your branch is behind 'origin/metadata-v2' by 524 commits, and can be 
> fast-forwarded.
>   (use "git pull" to update your local branch)
> Changes not staged for commit:
>   (use "git add ..." to update what will be committed)
>   (use "git checkout -- ..." to discard changes in working directory)
>
> modified:   FixedEffectModels/versions/0.1.0/requires
> modified:   FixedEffectModels/versions/0.1.1/requires
> modified:   FixedEffectModels/versions/0.2.0/requires
> modified:   FixedEffectModels/versions/0.2.1/requires
> modified:   FixedEffectModels/versions/0.2.2/requires
>
> no changes added to commit (use "git add" and/or "git commit -a")
>
>
> How can I solve this? Thanks
>
> --
> Esta mensagem pode conter informação confidencial e/ou privilegiada.Se 
> você não for o destinatário ou a pessoa autorizada a receber esta mensagem, 
> você não deve usar, copiar, divulgar, alterar e não tomar nenhuma ação em 
> relação a esta mensagem ou qualquer informação aqui contida.Se você recebeu 
> esta mensagem erroneamente, por favor entre em contato imediatamente ou 
> responsa por e-mail ao remetente e apague esta mensagem. Opiniões pessoais 
> do remetente não refletem, necessariamente, o ponto de vista da Neurotech, 
> o qual é divulgado somente por pessoas autorizadas. Antes de imprimir este 
> e-mail, veja se realmente é necessário. Ajude a preservar o meio ambiente.
>
> This message may contain confidential and/or privileged information. If 
> you are not the addressee or authorized to receive this for the 
> addressee, please, you must not use, copy, disclose, change, take any 
> action based on this message or any information herein. Personal opinions 
> of the sender do not necessarily reflect the view of Neurotech, which is 
> only divulged by authorized persons. Please consider the environment before 
> printing this email.
>

Re: [julia-users] Multiple Dispatch Question

[Christopher Alexander]

Erik and Cedric, thanks for the suggestions!  I think I will look into the 
Val{Bool} option.  Right now I'm just using a normal Bool flag in the 
function, but it's not as clean as I'd like.

Thanks!

Chris

On Monday, January 18, 2016 at 6:27:10 PM UTC-5, Erik Schnetter wrote:
>
> Chris 
>
> In this case, you could write an auxiliary third function that takes 
> an additional Bool parameter. Both your functions call the third 
> function with this Bool parameter. 
>
> An alternative solution is to make this a Val{Bool} parameter, which 
> would likely specialize the functions at build time. This might 
> improve performance if the functions are called in a 
> performance-critial region. 
>
> -erik 
>
>
> On Mon, Jan 18, 2016 at 4:36 PM, Cedric St-Jean <cedric...@gmail.com 
> > wrote: 
> > my_func(fcn1::Function, passedIn::Float64) = 
> > my_func(fcn1, (y, z, passedin)->default_fcn(0.0, y, z, passedin), 
> > passedIn) 
> > 
> > You could achieve the same effect in one definition if you put fcn2 as a 
> > keyword argument. Also check out FastAnonymous.jl if performance 
> matters. 
> > 
> > 
> > On Monday, January 18, 2016 at 4:25:20 PM UTC-5, Christopher Alexander 
> > wrote: 
> >> 
> >> Thanks for the response!  As a follow-up, what would I do in a 
> situation 
> >> where the passed-in second function (fcn2) and the default function 
> take a 
> >> different number of arguments? 
> >> 
> >> Thanks! 
> >> 
> >> Chris 
> >> 
> >> On Monday, January 18, 2016 at 4:06:41 PM UTC-5, Erik Schnetter wrote: 
> >>> 
> >>> Define the second function like this: 
> >>> ``` 
> >>> my_func(fcn1::Function, passedIn::Float64) = my_func(fcn1, 
> >>> default_fcn, passedIn) 
> >>> ``` 
> >>> 
> >>> -erik 
> >>> 
> >>> 
> >>> On Mon, Jan 18, 2016 at 4:02 PM, Christopher Alexander 
> >>> <uvap...@gmail.com> wrote: 
> >>> > Hello all, I had a question concerning a best practice in a 
> particular 
> >>> > case 
> >>> > of multiple dispatch which is as follows. 
> >>> > 
> >>> > Let's say I have a function with two different methods. 
> >>> > 
> >>> > function my_func(fcn1::Function,fcn2::Function, passedIn::Float64) 
> >>> >  x = 0.0 
> >>> >  y = 1.0 
> >>> >  z = 2.0 
> >>> >  val1 = fcn(x, y, passedIn) 
> >>> >  val2 = fcn2(y, z, passedIn) 
> >>> >  return val1, val2 
> >>> > end 
> >>> > 
> >>> > function my_func(fcn1::Function, passedIn::Float64) 
> >>> >  x = 0.0 
> >>> >  y = 1.0 
> >>> >  z = 2.0 
> >>> >  val1 = fcn(x, y, passedIn) 
> >>> >  val2 = default_fcn(x, y, z, passedIn) 
> >>> >  return val1, val2 
> >>> > end 
> >>> > 
> >>> > My question is basically, what would be the best way to do this 
> without 
> >>> > massive code duplication?  The actual situation I am working with 
> has 
> >>> > much 
> >>> > more going on in the function, so it's not like I could create some 
> >>> > init 
> >>> > function to set up x, y, & z.  But literally the only different 
> >>> > behavior 
> >>> > between the two methods is whether or not a second function is 
> passed 
> >>> > in. 
> >>> > 
> >>> > Thanks! 
> >>> > 
> >>> > Chris 
> >>> > 
> >>> 
> >>> 
> >>> 
> >>> -- 
> >>> Erik Schnetter <schn...@gmail.com> 
> >>> http://www.perimeterinstitute.ca/personal/eschnetter/ 
>
>
>
> -- 
> Erik Schnetter <schn...@gmail.com > 
> http://www.perimeterinstitute.ca/personal/eschnetter/ 
>

Re: [julia-users] Multiple Dispatch Question

[Christopher Alexander]

Thanks for the response!  As a follow-up, what would I do in a situation 
where the passed-in second function (fcn2) and the default function take a 
different number of arguments?

Thanks!

Chris

On Monday, January 18, 2016 at 4:06:41 PM UTC-5, Erik Schnetter wrote:
>
> Define the second function like this: 
> ``` 
> my_func(fcn1::Function, passedIn::Float64) = my_func(fcn1, 
> default_fcn, passedIn) 
> ``` 
>
> -erik 
>
>
> On Mon, Jan 18, 2016 at 4:02 PM, Christopher Alexander 
> <uvap...@gmail.com > wrote: 
> > Hello all, I had a question concerning a best practice in a particular 
> case 
> > of multiple dispatch which is as follows. 
> > 
> > Let's say I have a function with two different methods. 
> > 
> > function my_func(fcn1::Function,fcn2::Function, passedIn::Float64) 
> >  x = 0.0 
> >  y = 1.0 
> >  z = 2.0 
> >  val1 = fcn(x, y, passedIn) 
> >  val2 = fcn2(y, z, passedIn) 
> >  return val1, val2 
> > end 
> > 
> > function my_func(fcn1::Function, passedIn::Float64) 
> >  x = 0.0 
> >  y = 1.0 
> >  z = 2.0 
> >  val1 = fcn(x, y, passedIn) 
> >  val2 = default_fcn(x, y, z, passedIn) 
> >  return val1, val2 
> > end 
> > 
> > My question is basically, what would be the best way to do this without 
> > massive code duplication?  The actual situation I am working with has 
> much 
> > more going on in the function, so it's not like I could create some init 
> > function to set up x, y, & z.  But literally the only different behavior 
> > between the two methods is whether or not a second function is passed 
> in. 
> > 
> > Thanks! 
> > 
> > Chris 
> > 
>
>
>
> -- 
> Erik Schnetter <schn...@gmail.com > 
> http://www.perimeterinstitute.ca/personal/eschnetter/ 
>

[julia-users] Multiple Dispatch Question

[Christopher Alexander]

Hello all, I had a question concerning a best practice in a particular case 
of multiple dispatch which is as follows.

Let's say I have a function with two different methods.

function my_func(fcn1::Function,fcn2::Function, passedIn::Float64)
 x = 0.0
 y = 1.0
 z = 2.0
 val1 = fcn(x, y, passedIn)
 val2 = fcn2(y, z, passedIn)
 return val1, val2
end

function my_func(fcn1::Function, passedIn::Float64)
 x = 0.0
 y = 1.0
 z = 2.0
 val1 = fcn(x, y, passedIn)
 val2 = default_fcn(x, y, z, passedIn)
 return val1, val2
end

My question is basically, what would be the best way to do this without 
massive code duplication?  The actual situation I am working with has much 
more going on in the function, so it's not like I could create some init 
function to set up x, y, & z.  But literally the only different behavior 
between the two methods is whether or not a second function is passed in.

Thanks!

Chris

Re: [julia-users] Cannot pull with rebase...?

[Christopher Alexander]

In your user folder, you don't have a .julia folder?  It is hidden, so you 
might have to turn on hidden folders or access it via the command prompt. 
 If you are on a computer with a network drive, it might have put the 
folder in there.

On Wednesday, January 13, 2016 at 10:36:51 AM UTC-5, fab...@chalmers.se 
wrote:
>
> Thanks for the reply. Unfortunately, I cannot find any such folder. This 
> is the binary 64-bit version of Julia 0.4.2 on W10x64pro. I expected this 
> to just install and run, but apparently this is not the case, at least not 
> on W10...
>
>
> On Tuesday, January 12, 2016 at 4:48:22 PM UTC+1, Stefan Karpinski wrote:
>>
>> If you go into ~/.julia/v0.4/METADATA and do `git status` you should see 
>> what's going on there.
>>
>> On Tue, Jan 12, 2016 at 10:41 AM,  wrote:
>>
>>> Hello all 
>>> (first post)
>>>
>>> I just now downloaded version 0.4.2 of Julia, and installed it on my 
>>> W10x64pro machine. I was going to use it to run the optimization packages, 
>>> so I did the Pkg.update() on the Julia cmd line, as instructed here 
>>> http://www.juliaopt.org/.
>>>
>>> To my surprise, i get the following error message:
>>>
>>> INFO: Updating METADATA...
>>> error: Cannot pull with rebase: You have unstaged changes.
>>> ERROR: failed process: Process(`git pull --rebase -q`, ProcessExited(1)) 
>>> [1]
>>>  in pipeline_error at process.jl:555
>>>
>>> I have not done any changes to any source, just DL'ed and installed the 
>>> 64-bit binary for windows, and I have no clue what is going on... Does 
>>> anyone have any ideas?
>>>
>>> Thanks.
>>>
>>
>>

Re: [julia-users] Questions concerning circular reference / self-referencing in types, specifically regarding performance

[Christopher Alexander]

OK, I've gotten by this by doing:

*B{AbstractA}()*

... but it would be neat if I could just infer that type in the inner 
constructor.


On Friday, January 1, 2016 at 5:06:33 PM UTC-5, Christopher Alexander wrote:
>
> Thanks!  I'm having a bit of trouble with that setup when the type is 
> parameterized, as below:
>
>
>
>
> *abstract AbstractAtype A <: AbstractA endtype B{T <: AbstractA}  a::T  
> B() = new()end*
>
> I am getting this error:
>
> *ERROR: MethodError: `convert` has no method matching 
> convert(::Type{B{T<:AbstractA}})*
>
> *This may have arisen from a call to the constructor B{T<:AbstractA}(...),*
>
> *since type constructors fall back to convert methods.*
>
> Closest candidates are:
>
>   convert{T}(::Type{T}, *::T*)
>
>   call{T}(::Type{T}, *::Any*)
>
>  in call at essentials.jl:57
>
> Is that the proper way to set that up?
>
> Thanks!!
>
> Chris
>
> On Friday, January 1, 2016 at 4:45:12 PM UTC-5, Tim Holy wrote:
>>
>> If you make `ts` the last parameter, using an inner constructor you can 
>> leave 
>> that field undefined when you initially create the object, then fill it 
>> in later. 
>> You may need to sprinkle some `isdefined(b, :ts)` in various places in 
>> your 
>> code. 
>>
>> Happy New Year! 
>> --Tim 
>>
>> On Friday, January 01, 2016 11:01:02 AM Christopher Alexander wrote: 
>> > I'm actually having a slight problem with this implementation. 
>>  Basically, 
>> > in using the parametric approach above, when I initially create an 
>> instance 
>> > of the Bond type with the NullTermStructure and then set its term 
>> structure 
>> > with the new TermStructure instance that I create (creating the 
>> circular 
>> > reference), I get a convert error.  I'm assuming this is because the 
>> > initial instantiation of the Bond wants a TermStructure of type 
>> > NullTermStructure, so then when I try to re-set it with 
>> PiecewiseYieldCurve, 
>> > it complains.  Is there any way to avoid setting it with the 
>> > NullTermStructure in the first place? 
>> > 
>> > Thanks! 
>> > 
>> > Chris 
>> > 
>> > On Friday, January 1, 2016 at 1:24:21 PM UTC-5, Christopher Alexander 
>> wrote: 
>> > > Thanks Tim, this is very helpful!  Happy New Year! 
>> > > 
>> > > - Chris 
>> > > 
>> > > On Thursday, December 31, 2015 at 6:33:29 PM UTC-5, Tim Holy wrote: 
>> > >> See 
>> > >> 
>> http://docs.julialang.org/en/stable/manual/faq/#how-do-abstract-or-ambigu 
>> > >> ous-fields-in-types-interact-with-the-compiler and the section 
>> > >> afterwards. You'd be better off with 
>> > >> 
>> > >> type Bond{T<:TermStructure} 
>> > >> 
>> > >> rate::Float64 
>> > >> ts::T 
>> > >> mat_dat::Date 
>> > >> 
>> > >> end 
>> > >> 
>> > >> --Tim 
>> > >> 
>> > >> On Thursday, December 31, 2015 02:42:11 PM Christopher Alexander 
>> wrote: 
>> > >> > Hello all, 
>> > >> > 
>> > >> > I have a question about the usage of circular references in types. 
>>  In 
>> > >> 
>> > >> a 
>> > >> 
>> > >> > project I am working on, I am running into several situations 
>> where 
>> > >> 
>> > >> this 
>> > >> 
>> > >> > type of design appears to be the best issue.  For example, let's 
>> say I 
>> > >> 
>> > >> have 
>> > >> 
>> > >> > this (this is a massive simplification but illustrates my point): 
>> > >> > 
>> > >> > abstract TermStructure 
>> > >> > 
>> > >> > 
>> > >> > type Bond 
>> > >> > rate::Float64 
>> > >> > ts::TermStructure 
>> > >> > mat_date::Date 
>> > >> > end 
>> > >> > 
>> > >> > 
>> > >> > function Bond(rate::Float64, mat_date::Date) 
>> > >> > 
>> > >> >ts = NullTermStructure() 
>> > >> >return Bond(rate, ts, mat_date) 
>> > >> > 
>> > >> > end 
>> > >> > 
>> > >> > 
>> > >> > type NullTermStructure <: TermStructure end 
>> > >> > 
>> > >> > 
>> > >> > type PiecewiseYieldCurve <: TermStructure 
>> > >> > settlement::Date 
>> > >> > bonds::Vector{Bond} 
>> > >> > end 
>> > >> > 
>> > >> > 
>> > >> > function PiecewiseYieldCurve(settlement::Date, sched::Schedule, 
>> rate:: 
>> > >> > Float64) 
>> > >> > 
>> > >> >   bonds = Vector{Bond}(length(sched)) 
>> > >> >   for (i, d) in enumerate(sched) 
>> > >> >   
>> > >> >  new_bond = Bond(rate, d) 
>> > >> >  bonds[i] = new_bond 
>> > >> >   
>> > >> >   end 
>> > >> >   
>> > >> >   pyc = PiecewiseYieldCurve(settlement, bonds) 
>> > >> >   for b in bonds 
>> > >> >   
>> > >> > b.ts = pyc 
>> > >> >   
>> > >> >   end 
>> > >> >   
>> > >> >   return pyc 
>> > >> > 
>> > >> > end 
>> > >> > 
>> > >> > 
>> > >> > Firstly, I guess, is this the best implementation?  There are 
>> > >> 
>> > >> situations 
>> > >> 
>> > >> > where I need the bonds of the PiecewiseYieldCurve to be aware of 
>> the 
>> > >> > TermStructure to which they are connected.  Secondly, do I take a 
>> > >> > performance hit from this?  The PiecewiseYieldCurve instance will 
>> have 
>> > >> > parts of it updated as I run some of my pricer methods (not 
>> shown). 
>> > >> > 
>> > >> > Thanks! 
>> > >> > 
>> > >> > Chris 
>>
>>

Re: [julia-users] Questions concerning circular reference / self-referencing in types, specifically regarding performance

[Christopher Alexander]

OK, now I have it:

type DiscountingBondEngine{Y <: YieldTermStructure} <: PricingEngine{Y}
  yts::Y

  function call(::Type{DiscountingBondEngine})
new{YieldTermStructure}()
  end

  function call{Y}(::Type{DiscountingBondEngine}, yts::Y)
new{Y}(yts)
  end
end

This let's you call something like this with no issues:
pricing_engine = DiscountingBondEngine()

Then you can set the term structure later.

Julia is awesome.

Thanks!

Chris


On Friday, January 1, 2016 at 5:24:13 PM UTC-5, Christopher Alexander wrote:
>
> OK, I've gotten by this by doing:
>
> *B{AbstractA}()*
>
> ... but it would be neat if I could just infer that type in the inner 
> constructor.
>
>
> On Friday, January 1, 2016 at 5:06:33 PM UTC-5, Christopher Alexander 
> wrote:
>>
>> Thanks!  I'm having a bit of trouble with that setup when the type is 
>> parameterized, as below:
>>
>>
>>
>>
>> *abstract AbstractAtype A <: AbstractA endtype B{T <: AbstractA}  a::T  
>> B() = new()end*
>>
>> I am getting this error:
>>
>> *ERROR: MethodError: `convert` has no method matching 
>> convert(::Type{B{T<:AbstractA}})*
>>
>> *This may have arisen from a call to the constructor 
>> B{T<:AbstractA}(...),*
>>
>> *since type constructors fall back to convert methods.*
>>
>> Closest candidates are:
>>
>>   convert{T}(::Type{T}, *::T*)
>>
>>   call{T}(::Type{T}, *::Any*)
>>
>>  in call at essentials.jl:57
>>
>> Is that the proper way to set that up?
>>
>> Thanks!!
>>
>> Chris
>>
>> On Friday, January 1, 2016 at 4:45:12 PM UTC-5, Tim Holy wrote:
>>>
>>> If you make `ts` the last parameter, using an inner constructor you can 
>>> leave 
>>> that field undefined when you initially create the object, then fill it 
>>> in later. 
>>> You may need to sprinkle some `isdefined(b, :ts)` in various places in 
>>> your 
>>> code. 
>>>
>>> Happy New Year! 
>>> --Tim 
>>>
>>> On Friday, January 01, 2016 11:01:02 AM Christopher Alexander wrote: 
>>> > I'm actually having a slight problem with this implementation. 
>>>  Basically, 
>>> > in using the parametric approach above, when I initially create an 
>>> instance 
>>> > of the Bond type with the NullTermStructure and then set its term 
>>> structure 
>>> > with the new TermStructure instance that I create (creating the 
>>> circular 
>>> > reference), I get a convert error.  I'm assuming this is because the 
>>> > initial instantiation of the Bond wants a TermStructure of type 
>>> > NullTermStructure, so then when I try to re-set it with 
>>> PiecewiseYieldCurve, 
>>> > it complains.  Is there any way to avoid setting it with the 
>>> > NullTermStructure in the first place? 
>>> > 
>>> > Thanks! 
>>> > 
>>> > Chris 
>>> > 
>>> > On Friday, January 1, 2016 at 1:24:21 PM UTC-5, Christopher Alexander 
>>> wrote: 
>>> > > Thanks Tim, this is very helpful!  Happy New Year! 
>>> > > 
>>> > > - Chris 
>>> > > 
>>> > > On Thursday, December 31, 2015 at 6:33:29 PM UTC-5, Tim Holy wrote: 
>>> > >> See 
>>> > >> 
>>> http://docs.julialang.org/en/stable/manual/faq/#how-do-abstract-or-ambigu 
>>> > >> ous-fields-in-types-interact-with-the-compiler and the section 
>>> > >> afterwards. You'd be better off with 
>>> > >> 
>>> > >> type Bond{T<:TermStructure} 
>>> > >> 
>>> > >> rate::Float64 
>>> > >> ts::T 
>>> > >> mat_dat::Date 
>>> > >> 
>>> > >> end 
>>> > >> 
>>> > >> --Tim 
>>> > >> 
>>> > >> On Thursday, December 31, 2015 02:42:11 PM Christopher Alexander 
>>> wrote: 
>>> > >> > Hello all, 
>>> > >> > 
>>> > >> > I have a question about the usage of circular references in 
>>> types.  In 
>>> > >> 
>>> > >> a 
>>> > >> 
>>> > >> > project I am working on, I am running into several situations 
>>> where 
>>> > >> 
>>> > >> this 
>>> > >> 
>>> > >> > type of design appears to be the 

Re: [julia-users] Questions concerning circular reference / self-referencing in types, specifically regarding performance

[Christopher Alexander]

Thanks!  I'm having a bit of trouble with that setup when the type is 
parameterized, as below:




*abstract AbstractAtype A <: AbstractA endtype B{T <: AbstractA}  a::T  B() 
= new()end*

I am getting this error:

*ERROR: MethodError: `convert` has no method matching 
convert(::Type{B{T<:AbstractA}})*

*This may have arisen from a call to the constructor B{T<:AbstractA}(...),*

*since type constructors fall back to convert methods.*

Closest candidates are:

  convert{T}(::Type{T}, *::T*)

  call{T}(::Type{T}, *::Any*)

 in call at essentials.jl:57

Is that the proper way to set that up?

Thanks!!

Chris

On Friday, January 1, 2016 at 4:45:12 PM UTC-5, Tim Holy wrote:
>
> If you make `ts` the last parameter, using an inner constructor you can 
> leave 
> that field undefined when you initially create the object, then fill it in 
> later. 
> You may need to sprinkle some `isdefined(b, :ts)` in various places in 
> your 
> code. 
>
> Happy New Year! 
> --Tim 
>
> On Friday, January 01, 2016 11:01:02 AM Christopher Alexander wrote: 
> > I'm actually having a slight problem with this implementation. 
>  Basically, 
> > in using the parametric approach above, when I initially create an 
> instance 
> > of the Bond type with the NullTermStructure and then set its term 
> structure 
> > with the new TermStructure instance that I create (creating the circular 
> > reference), I get a convert error.  I'm assuming this is because the 
> > initial instantiation of the Bond wants a TermStructure of type 
> > NullTermStructure, so then when I try to re-set it with 
> PiecewiseYieldCurve, 
> > it complains.  Is there any way to avoid setting it with the 
> > NullTermStructure in the first place? 
> > 
> > Thanks! 
> > 
> > Chris 
> > 
> > On Friday, January 1, 2016 at 1:24:21 PM UTC-5, Christopher Alexander 
> wrote: 
> > > Thanks Tim, this is very helpful!  Happy New Year! 
> > > 
> > > - Chris 
> > > 
> > > On Thursday, December 31, 2015 at 6:33:29 PM UTC-5, Tim Holy wrote: 
> > >> See 
> > >> 
> http://docs.julialang.org/en/stable/manual/faq/#how-do-abstract-or-ambigu 
> > >> ous-fields-in-types-interact-with-the-compiler and the section 
> > >> afterwards. You'd be better off with 
> > >> 
> > >> type Bond{T<:TermStructure} 
> > >> 
> > >> rate::Float64 
> > >> ts::T 
> > >> mat_dat::Date 
> > >> 
> > >> end 
> > >> 
> > >> --Tim 
> > >> 
> > >> On Thursday, December 31, 2015 02:42:11 PM Christopher Alexander 
> wrote: 
> > >> > Hello all, 
> > >> > 
> > >> > I have a question about the usage of circular references in types. 
>  In 
> > >> 
> > >> a 
> > >> 
> > >> > project I am working on, I am running into several situations where 
> > >> 
> > >> this 
> > >> 
> > >> > type of design appears to be the best issue.  For example, let's 
> say I 
> > >> 
> > >> have 
> > >> 
> > >> > this (this is a massive simplification but illustrates my point): 
> > >> > 
> > >> > abstract TermStructure 
> > >> > 
> > >> > 
> > >> > type Bond 
> > >> > rate::Float64 
> > >> > ts::TermStructure 
> > >> > mat_date::Date 
> > >> > end 
> > >> > 
> > >> > 
> > >> > function Bond(rate::Float64, mat_date::Date) 
> > >> > 
> > >> >ts = NullTermStructure() 
> > >> >return Bond(rate, ts, mat_date) 
> > >> > 
> > >> > end 
> > >> > 
> > >> > 
> > >> > type NullTermStructure <: TermStructure end 
> > >> > 
> > >> > 
> > >> > type PiecewiseYieldCurve <: TermStructure 
> > >> > settlement::Date 
> > >> > bonds::Vector{Bond} 
> > >> > end 
> > >> > 
> > >> > 
> > >> > function PiecewiseYieldCurve(settlement::Date, sched::Schedule, 
> rate:: 
> > >> > Float64) 
> > >> > 
> > >> >   bonds = Vector{Bond}(length(sched)) 
> > >> >   for (i, d) in enumerate(sched) 
> > >> >   
> > >> >  new_bond = Bond(rate, d) 
> > >> >  bonds[i] = new_bond 
> > >> >   
> > >> >   end 
> > >> >   
> > >> >   pyc = PiecewiseYieldCurve(settlement, bonds) 
> > >> >   for b in bonds 
> > >> >   
> > >> > b.ts = pyc 
> > >> >   
> > >> >   end 
> > >> >   
> > >> >   return pyc 
> > >> > 
> > >> > end 
> > >> > 
> > >> > 
> > >> > Firstly, I guess, is this the best implementation?  There are 
> > >> 
> > >> situations 
> > >> 
> > >> > where I need the bonds of the PiecewiseYieldCurve to be aware of 
> the 
> > >> > TermStructure to which they are connected.  Secondly, do I take a 
> > >> > performance hit from this?  The PiecewiseYieldCurve instance will 
> have 
> > >> > parts of it updated as I run some of my pricer methods (not shown). 
> > >> > 
> > >> > Thanks! 
> > >> > 
> > >> > Chris 
>
>

Re: [julia-users] Questions concerning circular reference / self-referencing in types, specifically regarding performance

[Christopher Alexander]

I'm actually having a slight problem with this implementation.  Basically, 
in using the parametric approach above, when I initially create an instance 
of the Bond type with the NullTermStructure and then set its term structure 
with the new TermStructure instance that I create (creating the circular 
reference), I get a convert error.  I'm assuming this is because the 
initial instantiation of the Bond wants a TermStructure of type 
NullTermStructure, so then when I try to re-set it with TermStructure, it 
complains.  Is there any way to avoid setting it with the NullTermStructure 
in the first place?

Thanks!

Chris

On Friday, January 1, 2016 at 1:24:21 PM UTC-5, Christopher Alexander wrote:
>
> Thanks Tim, this is very helpful!  Happy New Year!
>
> - Chris
>
> On Thursday, December 31, 2015 at 6:33:29 PM UTC-5, Tim Holy wrote:
>>
>> See 
>> http://docs.julialang.org/en/stable/manual/faq/#how-do-abstract-or-ambiguous-fields-in-types-interact-with-the-compiler
>>  
>> and the section 
>> afterwards. You'd be better off with 
>>
>> type Bond{T<:TermStructure} 
>> rate::Float64 
>> ts::T 
>>     mat_dat::Date 
>> end 
>>
>> --Tim 
>>
>> On Thursday, December 31, 2015 02:42:11 PM Christopher Alexander wrote: 
>> > Hello all, 
>> > 
>> > I have a question about the usage of circular references in types.  In 
>> a 
>> > project I am working on, I am running into several situations where 
>> this 
>> > type of design appears to be the best issue.  For example, let's say I 
>> have 
>> > this (this is a massive simplification but illustrates my point): 
>> > 
>> > abstract TermStructure 
>> > 
>> > 
>> > type Bond 
>> > rate::Float64 
>> > ts::TermStructure 
>> > mat_date::Date 
>> > end 
>> > 
>> > 
>> > function Bond(rate::Float64, mat_date::Date) 
>> >ts = NullTermStructure() 
>> >return Bond(rate, ts, mat_date) 
>> > end 
>> > 
>> > 
>> > type NullTermStructure <: TermStructure end 
>> > 
>> > 
>> > type PiecewiseYieldCurve <: TermStructure 
>> > settlement::Date 
>> > bonds::Vector{Bond} 
>> > end 
>> > 
>> > 
>> > function PiecewiseYieldCurve(settlement::Date, sched::Schedule, rate:: 
>> > Float64) 
>> >   bonds = Vector{Bond}(length(sched)) 
>> >   for (i, d) in enumerate(sched) 
>> >  new_bond = Bond(rate, d) 
>> >  bonds[i] = new_bond 
>> >   end 
>> > 
>> >   pyc = PiecewiseYieldCurve(settlement, bonds) 
>> >   for b in bonds 
>> > b.ts = pyc 
>> >   end 
>> > 
>> >   return pyc 
>> > end 
>> > 
>> > 
>> > Firstly, I guess, is this the best implementation?  There are 
>> situations 
>> > where I need the bonds of the PiecewiseYieldCurve to be aware of the 
>> > TermStructure to which they are connected.  Secondly, do I take a 
>> > performance hit from this?  The PiecewiseYieldCurve instance will have 
>> > parts of it updated as I run some of my pricer methods (not shown). 
>> > 
>> > Thanks! 
>> > 
>> > Chris 
>>
>>

Re: [julia-users] Questions concerning circular reference / self-referencing in types, specifically regarding performance

[Christopher Alexander]

I'm actually having a slight problem with this implementation.  Basically, 
in using the parametric approach above, when I initially create an instance 
of the Bond type with the NullTermStructure and then set its term structure 
with the new TermStructure instance that I create (creating the circular 
reference), I get a convert error.  I'm assuming this is because the 
initial instantiation of the Bond wants a TermStructure of type 
NullTermStructure, so then when I try to re-set it with PiecewiseYieldCurve, 
it complains.  Is there any way to avoid setting it with the 
NullTermStructure in the first place?

Thanks!

Chris

On Friday, January 1, 2016 at 1:24:21 PM UTC-5, Christopher Alexander wrote:
>
> Thanks Tim, this is very helpful!  Happy New Year!
>
> - Chris
>
> On Thursday, December 31, 2015 at 6:33:29 PM UTC-5, Tim Holy wrote:
>>
>> See 
>> http://docs.julialang.org/en/stable/manual/faq/#how-do-abstract-or-ambiguous-fields-in-types-interact-with-the-compiler
>>  
>> and the section 
>> afterwards. You'd be better off with 
>>
>> type Bond{T<:TermStructure} 
>> rate::Float64 
>> ts::T 
>>     mat_dat::Date 
>> end 
>>
>> --Tim 
>>
>> On Thursday, December 31, 2015 02:42:11 PM Christopher Alexander wrote: 
>> > Hello all, 
>> > 
>> > I have a question about the usage of circular references in types.  In 
>> a 
>> > project I am working on, I am running into several situations where 
>> this 
>> > type of design appears to be the best issue.  For example, let's say I 
>> have 
>> > this (this is a massive simplification but illustrates my point): 
>> > 
>> > abstract TermStructure 
>> > 
>> > 
>> > type Bond 
>> > rate::Float64 
>> > ts::TermStructure 
>> > mat_date::Date 
>> > end 
>> > 
>> > 
>> > function Bond(rate::Float64, mat_date::Date) 
>> >ts = NullTermStructure() 
>> >return Bond(rate, ts, mat_date) 
>> > end 
>> > 
>> > 
>> > type NullTermStructure <: TermStructure end 
>> > 
>> > 
>> > type PiecewiseYieldCurve <: TermStructure 
>> > settlement::Date 
>> > bonds::Vector{Bond} 
>> > end 
>> > 
>> > 
>> > function PiecewiseYieldCurve(settlement::Date, sched::Schedule, rate:: 
>> > Float64) 
>> >   bonds = Vector{Bond}(length(sched)) 
>> >   for (i, d) in enumerate(sched) 
>> >  new_bond = Bond(rate, d) 
>> >  bonds[i] = new_bond 
>> >   end 
>> > 
>> >   pyc = PiecewiseYieldCurve(settlement, bonds) 
>> >   for b in bonds 
>> > b.ts = pyc 
>> >   end 
>> > 
>> >   return pyc 
>> > end 
>> > 
>> > 
>> > Firstly, I guess, is this the best implementation?  There are 
>> situations 
>> > where I need the bonds of the PiecewiseYieldCurve to be aware of the 
>> > TermStructure to which they are connected.  Secondly, do I take a 
>> > performance hit from this?  The PiecewiseYieldCurve instance will have 
>> > parts of it updated as I run some of my pricer methods (not shown). 
>> > 
>> > Thanks! 
>> > 
>> > Chris 
>>
>>

Re: [julia-users] Questions concerning circular reference / self-referencing in types, specifically regarding performance

[Christopher Alexander]

Thanks Tim, this is very helpful!  Happy New Year!

- Chris

On Thursday, December 31, 2015 at 6:33:29 PM UTC-5, Tim Holy wrote:
>
> See 
> http://docs.julialang.org/en/stable/manual/faq/#how-do-abstract-or-ambiguous-fields-in-types-interact-with-the-compiler
>  
> and the section 
> afterwards. You'd be better off with 
>
> type Bond{T<:TermStructure} 
> rate::Float64 
> ts::T 
> mat_dat::Date 
> end 
>
> --Tim 
>
> On Thursday, December 31, 2015 02:42:11 PM Christopher Alexander wrote: 
> > Hello all, 
> > 
> > I have a question about the usage of circular references in types.  In a 
> > project I am working on, I am running into several situations where this 
> > type of design appears to be the best issue.  For example, let's say I 
> have 
> > this (this is a massive simplification but illustrates my point): 
> > 
> > abstract TermStructure 
> > 
> > 
> > type Bond 
> > rate::Float64 
> > ts::TermStructure 
> > mat_date::Date 
> > end 
> > 
> > 
> > function Bond(rate::Float64, mat_date::Date) 
> >ts = NullTermStructure() 
> >return Bond(rate, ts, mat_date) 
> > end 
> > 
> > 
> > type NullTermStructure <: TermStructure end 
> > 
> > 
> > type PiecewiseYieldCurve <: TermStructure 
> > settlement::Date 
> > bonds::Vector{Bond} 
> > end 
> > 
> > 
> > function PiecewiseYieldCurve(settlement::Date, sched::Schedule, rate:: 
> > Float64) 
> >   bonds = Vector{Bond}(length(sched)) 
> >   for (i, d) in enumerate(sched) 
> >  new_bond = Bond(rate, d) 
> >  bonds[i] = new_bond 
> >   end 
> > 
> >   pyc = PiecewiseYieldCurve(settlement, bonds) 
> >   for b in bonds 
> > b.ts = pyc 
> >   end 
> > 
> >   return pyc 
> > end 
> > 
> > 
> > Firstly, I guess, is this the best implementation?  There are situations 
> > where I need the bonds of the PiecewiseYieldCurve to be aware of the 
> > TermStructure to which they are connected.  Secondly, do I take a 
> > performance hit from this?  The PiecewiseYieldCurve instance will have 
> > parts of it updated as I run some of my pricer methods (not shown). 
> > 
> > Thanks! 
> > 
> > Chris 
>
>

[julia-users] Question about circular-references / self-referencing in types, in terms of performance

[Christopher Alexander]

Hello all, 

I have a question about the usage of circular references in types.  In a 
project I am working on, I am running into several situations where this 
type of design appears to be the best issue.  For example, let's say I have 
this (this is a massive simplification but illustrates my point):

```
abstract TermStructure

type Bond
rate::Float64
ts::TermStructure
mat_date::Date
end

function Bond(rate::Float64, mat_date::Date)
   ts = NullTermStructure()
   return Bond(rate, ts, mat_date)
end

type NullTermStructure <: TermStructure end

type PiecewiseYieldCurve <: TermStructure
settlement::Date
bonds::Vector{Bond}
end

function PiecewiseYieldCurve(settlement::Date, sched::Schedule, 
rate::Float64)
  bonds = Vector{Bond}(length(sched))
  for (i, d) in enumerate(sched)
 new_bond = Bond(rate, d)
 bonds[i] = new_bond
  end
  
  pyc = PiecewiseYieldCurve(settlement, bonds)
  for b in bonds
b.ts = pyc
  end
  
  return pyc
end
```

Firstly, I guess, is this the best implementation?  There are situations 
where I need the bonds of the PiecewiseYieldCurve to be aware of the 
TermStructure to which they are connected.  Secondly, do I take a 
performance hit from this?  The PiecewiseYieldCurve instance will have 
parts of it updated as I run some of my pricer methods (not shown).

Thanks!

Chris

[julia-users] Questions concerning circular reference / self-referencing in types, specifically regarding performance

[Christopher Alexander]

Hello all, 

I have a question about the usage of circular references in types.  In a 
project I am working on, I am running into several situations where this 
type of design appears to be the best issue.  For example, let's say I have 
this (this is a massive simplification but illustrates my point):

abstract TermStructure


type Bond
rate::Float64
ts::TermStructure
mat_date::Date
end


function Bond(rate::Float64, mat_date::Date)
   ts = NullTermStructure()
   return Bond(rate, ts, mat_date)
end


type NullTermStructure <: TermStructure end


type PiecewiseYieldCurve <: TermStructure
settlement::Date
bonds::Vector{Bond}
end


function PiecewiseYieldCurve(settlement::Date, sched::Schedule, rate::
Float64)
  bonds = Vector{Bond}(length(sched))
  for (i, d) in enumerate(sched)
 new_bond = Bond(rate, d)
 bonds[i] = new_bond
  end
  
  pyc = PiecewiseYieldCurve(settlement, bonds)
  for b in bonds
b.ts = pyc
  end
  
  return pyc
end


Firstly, I guess, is this the best implementation?  There are situations 
where I need the bonds of the PiecewiseYieldCurve to be aware of the 
TermStructure to which they are connected.  Secondly, do I take a 
performance hit from this?  The PiecewiseYieldCurve instance will have 
parts of it updated as I run some of my pricer methods (not shown).

Thanks!

Chris

Re: [julia-users] Re: Strange behavior using "^" (power function)

[Christopher Alexander]

I looked into using BigFloat, but the overhead majorly slowed everything 
down.  I saw there was a package DoubleDouble that was supposed to do that 
level of precision but without the overhead, but it doesn't seem to have 
been updated and I couldn't get it to work with 0.4.2.  Maybe I could try 
to get it up to speed.

Chris

On Thursday, December 17, 2015 at 5:05:23 PM UTC-5, Stephan Buchert wrote:
>
> In Julia there would be also BigFloat:
>
> julia> x=parse(BigFloat, "1.0525004")
>
> 1.0525003994
>
> julia> x^6.0-x^6
>
> 0.00
>

Re: [julia-users] Re: Strange behavior using "^" (power function)

[Christopher Alexander]

Thanks for explaining!  I can see where the differences are in math.jl.  I 
am trying to build an exponential splines fitting model (based off 
QuantLib's implementation), and my discount function is generating massive 
numbers at the beginning (as I try to minimize the function I am using), 
like on the order of 1e285 and then obviously very small numbers at further 
iterations (which is why even the small differences end up creating an 
issue).

Chris

On Thursday, December 17, 2015 at 12:03:12 PM UTC-5, Stefan Karpinski wrote:
>
> There are several different ways to compute floating-point powers:
>
>1. libm pow functions
>2. LLVM pow intrinsics
>3. power by squaring
>
> Since these use potentially different algorithms, they can give slightly 
> different answers. When you do Float64^Float64, the libm pow function is 
> called. When you do Float64^Int the LLVM intrinsic for integer 
> exponentiation of floating-point values is used. In your example, we have 
> the following results:
>
> julia> 1.0525004^6.0
> 1.3593541801778923
>
> julia> 1.0525004^6
> 1.3593541801778926
>
> julia> Base.power_by_squaring(1.0525004, 6)
> 1.3593541801778926
>
>
> So libm gives one answer while LLVM powi and power_by_squaring give 
> another. But there are other examples where there is disagreement in 
> different ways:
>
> julia> 1.0525004^7.0
> 1.4307202746372374
>
> julia> 1.0525004^7
> 1.4307202746372372
>
> julia> Base.power_by_squaring(1.0525004, 7)
> 1.4307202746372374
>
>
> julia> 1.0525004^33.0
> 5.411646860374188
>
> julia> 1.0525004^33
> 5.411646860374188
>
> julia> Base.power_by_squaring(1.0525004, 33)
> 5.411646860374187
>
>
> You can even find cases where they all disagree:
>
> julia> 1.0525004^89.0
> 95.0095587653903
>
> julia> 1.0525004^89
> 95.00955876539031
>
> julia> Base.power_by_squaring(1.0525004, 89)
> 95.00955876539028
>
>
> Although that's fairly rare.
>
> On Thu, Dec 17, 2015 at 6:37 AM, Paulo Jabardo <pjab...@gmail.com 
> > wrote:
>
>> Checkout base/math.jl
>>
>> When the exponent is a float, the c library function is used. When the 
>> exponent is an integer, it uses a llvm function. The implementation for 
>> integer exponent used to use an intelligent algorithm that does what your 
>> second example does but in a smart way, reducing the number of operations.
>>
>> This kind of "error" is unavoidable when using floating point arithmetic
>>
>>
>>
>> On Tuesday, December 15, 2015 at 6:38:03 PM UTC-2, Christopher Alexander 
>> wrote:
>>>
>>> Just as a follow up, I just tested with the exponent being an Integer vs 
>>> a Float (i.e. 6 vs 6.0), and I now see the same result as I do with Python 
>>> and C++ using both.
>>>
>>> Chris
>>>
>>> On Tuesday, December 15, 2015 at 3:35:35 PM UTC-5, Christopher Alexander 
>>> wrote:
>>>>
>>>> Hello all,
>>>>
>>>> I have noted an inaccuracy when using the "^" symbol.  Please see below:
>>>>
>>>> *julia> **1.0525004 ^ 6.0*
>>>>
>>>>
>>>> *1.3593541801778923*
>>>> *julia> *
>>>> *1.0525004 * 1.0525004 * 1.0525004 * 
>>>> 1.0525004 * 1.0525004 * 1.0525004*
>>>> *1.3593541801778926*
>>>>
>>>> This yields a difference of:  
>>>>
>>>> *2.220446049250313e-16*
>>>>
>>>>
>>>>
>>>> This might not seem like much of a difference, but it is having an 
>>>> adverse effect on a project I am working on.  To compare, in Python, I 
>>>> don't see any difference:
>>>>
>>>> In[8]: 1.0525004 ** 6.0
>>>> Out[8]: 1.3593541801778926
>>>>
>>>> In[9]: 1.0525004 * 1.0525004 * 1.0525004 * 
>>>> 1.0525004 * 1.0525004 * 1.0525004
>>>> Out[9]: 1.3593541801778926
>>>>
>>>> I also see no difference in C++
>>>>
>>>>
>>>> Any idea why this might be?  Just an issue with floating point math?  
>>>> Is Julia actually being more accurate here?
>>>>
>>>> Thanks!
>>>>
>>>> Chris
>>>>
>>>
>

Re: [julia-users] Re: Strange behavior using "^" (power function)

[Christopher Alexander]

Jeffrey,

Absolutely!  I think I am seeing my C++ QuantLib code reach a minimum that 
is much smaller (roughly 1e-6) vs the Julia implementation (1e-4) because 
of some precision issues.

Thanks!

Chris

On Thursday, December 17, 2015 at 7:34:54 PM UTC-5, Jeffrey Sarnoff wrote:
>
> Chris,
>
> That package is no longer supported and it is missing division, sqrt ..
>
> Would a double-double type supporting (+),(-),(*),(sqrt) suffice for your 
> work?  
> I have written that as part of something else, and am willing to separate 
> it out for others to use.
>
> Jeffrey
>
>
> On Thursday, December 17, 2015 at 5:15:33 PM UTC-5, Christopher Alexander 
> wrote:
>>
>> I looked into using BigFloat, but the overhead majorly slowed everything 
>> down.  I saw there was a package DoubleDouble that was supposed to do that 
>> level of precision but without the overhead, but it doesn't seem to have 
>> been updated and I couldn't get it to work with 0.4.2.  Maybe I could try 
>> to get it up to speed.
>>
>> Chris
>>
>> On Thursday, December 17, 2015 at 5:05:23 PM UTC-5, Stephan Buchert wrote:
>>>
>>> In Julia there would be also BigFloat:
>>>
>>> julia> x=parse(BigFloat, "1.0525004")
>>>
>>> 1.0525003994
>>>
>>> julia> x^6.0-x^6
>>>
>>> 0.00
>>>
>>

[julia-users] Strange behavior using "^" (power function)

[Christopher Alexander]

Hello all,

I have noted an inaccuracy when using the "^" symbol.  Please see below:

*julia> **1.0525004 ^ 6.0*


*1.3593541801778923*
*julia> *
*1.0525004 * 1.0525004 * 1.0525004 * 
1.0525004 * 1.0525004 * 1.0525004*
*1.3593541801778926*

This yields a difference of:  

*2.220446049250313e-16*



This might not seem like much of a difference, but it is having an adverse 
effect on a project I am working on.  To compare, in Python, I don't see 
any difference:

In[8]: 1.0525004 ** 6.0
Out[8]: 1.3593541801778926

In[9]: 1.0525004 * 1.0525004 * 1.0525004 * 
1.0525004 * 1.0525004 * 1.0525004
Out[9]: 1.3593541801778926

I also see no difference in C++


Any idea why this might be?  Just an issue with floating point math?  Is 
Julia actually being more accurate here?

Thanks!

Chris

[julia-users] Re: Strange behavior using "^" (power function)

[Christopher Alexander]

Just as a follow up, I just tested with the exponent being an Integer vs a 
Float (i.e. 6 vs 6.0), and I now see the same result as I do with Python 
and C++ using both.

Chris

On Tuesday, December 15, 2015 at 3:35:35 PM UTC-5, Christopher Alexander 
wrote:
>
> Hello all,
>
> I have noted an inaccuracy when using the "^" symbol.  Please see below:
>
> *julia> **1.0525004 ^ 6.0*
>
>
> *1.3593541801778923*
> *julia> *
> *1.0525004 * 1.0525004 * 1.0525004 * 
> 1.0525004 * 1.0525004 * 1.0525004*
> *1.3593541801778926*
>
> This yields a difference of:  
>
> *2.220446049250313e-16*
>
>
>
> This might not seem like much of a difference, but it is having an adverse 
> effect on a project I am working on.  To compare, in Python, I don't see 
> any difference:
>
> In[8]: 1.0525004 ** 6.0
> Out[8]: 1.3593541801778926
>
> In[9]: 1.0525004 * 1.0525004 * 1.0525004 * 
> 1.0525004 * 1.0525004 * 1.0525004
> Out[9]: 1.3593541801778926
>
> I also see no difference in C++
>
>
> Any idea why this might be?  Just an issue with floating point math?  Is 
> Julia actually being more accurate here?
>
> Thanks!
>
> Chris
>

[julia-users] Re: ANN: DSGE.jl

[Christopher Alexander]

This is great, great stuff.  It is awesome to see more Julia in the 
finance/econ world.

On Thursday, December 3, 2015 at 9:05:57 AM UTC-5, Spencer Lyon wrote:
>
> The Federal Reserve bank of New York has finished moving their fairly 
> large DSGE model from Matlab to Julia. This model is used inside the Fed 
> for forecasting and policy analysis. 
>
> As part of the move to Julia, the code base has been open sourced.
>
> A blog post announcing the release is here: 
> http://libertystreeteconomics.newyorkfed.org/2015/12/the-frbny-dsge-model-meets-julia.html
>
> And the repository can be found here: 
> https://github.com/FRBNY-DSGE/DSGE.jl
>
>
>

[julia-users] Re: WinRPM Download failure

[Christopher Alexander]

I'm not sure if they've tagged their latest version of master, but the 
change is in there:

https://github.com/JuliaLang/WinRPM.jl/commit/cb12a4136e9afb2a158ff888bc8ea81d3e72e619

Basically the openSUSE_13.1 needs to be openSUSE_13.2 in the url.  I had 
this problem like last week and I just changed it manually for now.  I 
guess you could checkout master as well.

Chris

On Monday, October 26, 2015 at 3:26:07 PM UTC-4, Achu wrote:
>
> I got this when I ran Pkg.update() and also on WinRPM.update()
>
> INFO: Building WinRPM
> INFO: Downloading 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270086
> WARNING: Retry 1/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270086
> WARNING: Retry 2/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270086
> WARNING: Retry 3/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270086
> WARNING: Retry 4/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270086
> WARNING: Retry 5/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
> WARNING: received error 0 while downloading 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.1/repodata/repomd.xml
> INFO: Downloading 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.1/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270086
> WARNING: Retry 1/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.1/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270086
> WARNING: Retry 2/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.1/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270086
> WARNING: Retry 3/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.1/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270086
> WARNING: Retry 4/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.1/repodata/repomd.xml
> WARNING: Unknown download failure, error code: 2148270086
> WARNING: Retry 5/5 downloading: 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.1/repodata/repomd.xml
> WARNING: received error 0 while downloading 
> https://cache.e.ip.saba.us/http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_13.1/repodata/repomd.xml
>
> Heading to the link gives me a 404 error.
>

[julia-users] Re: Building a Binomial Tree

[Christopher Alexander]

Eric, thanks for the response and pointers!  In terms of constructing a 
Matrix, are you talking about something like this?

*3x3 Array{Float64,2}:*

* 50.0  40.0  32.0*

*  0.0  60.0  48.0*

*  0.0   0.0  72.0*


The graph option is interesting too, I hadn't thought about that.  Thanks 
for the link to the paper, this is extremely helpful!

Thanks!

Chris


On Friday, October 23, 2015 at 8:35:53 PM UTC-4, Eric Forgy wrote:
>
> Hi Christopher,
>
> I am just learning then Julian way myself, but one thing that "might" be 
> better than an array of growing arrays is to note that a binary tree can be 
> laid into a matrix, i.e. Array{Float64,2}, by rotating it. This is nice in 
> case you ever need a ternary tree, which could be represented by 
> Array{Float64,3}, etc.
>
> Another thing you might consider is to treat the tree as a directed graph 
> and look at incorporating one of the Julia graph theory packages.
>
> On the topic, I have a paper (shameless plug alert!) you might be 
> interested in:
>
>- *Financial Modelling Using Discrete Stochastic Calculus* 
><http://phorgyphynance.files.wordpress.com/2008/06/discretesc.pdf>
>
> More papers here <https://phorgyphynance.wordpress.com/my-papers/>.
>
>
> On Saturday, October 24, 2015 at 7:50:59 AM UTC+8, Christopher Alexander 
> wrote:
>>
>> Hello all,
>>
>> I am trying to write a method that builds a binomial tree for option 
>> pricing.  I am trying to set up my tree like this:
>>
>> function build_tree(s_opt::StockOption)
>>   u = 1 + s_opt.pu
>>   d = 1 - s_opt.pd
>>   # qu = (exp((s_opt.r - s_opt.div) * s_opt.dt) - d) / (u - d)
>>   # qd = 1 - qu
>>
>>   # init array
>>stockTree = Vector{Float64}[ zeros(m) for m = 1:s_opt.N + 1]
>>
>>   for i = 1:s_opt.N + 1
>> for j = 1:i
>>   stockTree[i][j] = s_opt.S0 * u ^ (j-1) * d ^ (i - j)
>> end
>>   end
>>
>>   return stockTree
>> end
>>
>> Is this the most "Julian" way to do this (I didn't find really any 
>> modules that would suit this purpose)?
>>
>> Here is what prints out:
>>
>> *3-element Array{Array{Float64,1},1}:*
>>
>> * [50.0]   *
>>
>> * [40.0,60.0]  *
>>
>> * [32.01,48.0,72.0]*
>>
>> I suppose also I could default the [1][1] state to the spot price (S0), 
>> so then I don't need to alter the looping range and instead start the range 
>> at 2.
>>
>> Thanks!
>>
>> Chris
>>
>

[julia-users] Building a Bionmial Tree

[Christopher Alexander]

Hello all,

I am trying to write a method that builds a binomial tree for option 
pricing.  I am trying to set up my tree like this:

function build_tree(s_opt::StockOption)
  u = 1 + s_opt.pu
  d = 1 - s_opt.pd
  # qu = (exp((s_opt.r - s_opt.div) * s_opt.dt) - d) / (u - d)
  # qd = 1 - qu

  # init array
   stockTree = Vector{Float64}[ zeros(m) for m = 1:s_opt.N + 1]

  for i = 1:s_opt.N + 1
for j = 1:i
  stockTree[i][j] = s_opt.S0 * u ^ (j-1) * d ^ (i - j)
end
  end

  return stockTree
end

Is this the most "Julian" way to do this (I didn't find really any modules 
that would suit this purpose)?

Here is what prints out:

*3-element Array{Array{Float64,1},1}:*

* [50.0]   *

* [40.0,60.0]  *

* [32.01,48.0,72.0]*

I suppose also I could default the [1][1] state to the spot price (S0), so 
then I don't need to alter the looping range and instead start the range at 
2.

Thanks!

Chris

[julia-users] Building a Binomial Tree

[Christopher Alexander]

Hello all,

I am trying to write a method that builds a binomial tree for option 
pricing.  I am trying to set up my tree like this:

function build_tree(s_opt::StockOption)
  u = 1 + s_opt.pu
  d = 1 - s_opt.pd
  # qu = (exp((s_opt.r - s_opt.div) * s_opt.dt) - d) / (u - d)
  # qd = 1 - qu

  # init array
   stockTree = Vector{Float64}[ zeros(m) for m = 1:s_opt.N + 1]

  for i = 1:s_opt.N + 1
for j = 1:i
  stockTree[i][j] = s_opt.S0 * u ^ (j-1) * d ^ (i - j)
end
  end

  return stockTree
end

Is this the most "Julian" way to do this (I didn't find really any modules 
that would suit this purpose)?

Here is what prints out:

*3-element Array{Array{Float64,1},1}:*

* [50.0]   *

* [40.0,60.0]  *

* [32.01,48.0,72.0]*

I suppose also I could default the [1][1] state to the spot price (S0), so 
then I don't need to alter the looping range and instead start the range at 
2.

Thanks!

Chris

[julia-users] Re: ANN: A potential new Discourse-based Julia forum

[Christopher Alexander]

Hmm, the site appears to be blocked by my company's web filter.

On Saturday, September 19, 2015 at 8:16:36 PM UTC-4, Jonathan Malmaud wrote:
>
> Hi all,
> There's been some chatter about maybe switching to a new, more modern 
> forum platform for Julia that could potentially subsume julia-users, 
> julia-dev, julia-stats, julia-gpu, and julia-jobs.   I created 
> http://julia.malmaud.com for us to try one out and see if we like it. 
> Please check it out and leave feedback. All the old posts from julia-users 
> have already been imported to it.
>
> It is using Discourse , the same forum 
> software used for the forums of Rust , 
> BoingBoing, and some other big sites. Benefits over Google Groups include 
> better support for topic tagging, community moderation features,  Markdown 
> (and hence syntax highlighting) in messages, inline previews of linked-to 
> Github issues, better mobile support, and more options for controlling when 
> and what you get emailed. The Discourse website 
>  does a better job of summarizing the 
> advantages than I could.
>
> To get things started, MIke Innes suggested having a topic on what we 
> plan on working on this coming wee 
> k.
>  
> I think that's a great idea.
>
> Just to be clear, this isn't "official" in any sense - it's just to 
> kickstart the discussion. 
>
> -Jon
>
>
>

[julia-users] Problem with Abstract Types in Type definition

[Christopher Alexander]

Hello all,

I am trying to figure out what I'm doing wrong with the creation of a 
composite type, as below:

abstract MyType

type MySpecificType <: MyType

type TestTypes
type_test::MyType
end

testing = MySpecificType

x = TestTypes(testing)


After running the above, I get a MethodError: 

ERROR: MethodError: `convert` has no method matching 
convert(::Type{MyType}, ::Type{MySpecificType})
This may have arisen from a call to the constructor MyType(...),
since type constructors fall back to convert methods.
Closest candidates are:
  call{T}(::Type{T}, ::Any)
  convert{T}(::Type{T}, ::T)
 in call at none:2

Any ideas?

Thanks!

Chris

[julia-users] Re: Problem with Abstract Types in Type definition

[Christopher Alexander]

Ahh, this is very helpful, thanks!!

Just another question, given that syntax (as a parametric type), how is one 
able to define a type like this:

type MyType
my_num::Real
end

... and then these work without issue:
x = MyType(3.4)
y = MyType(4)

I also ran into this issue when I defined a type where one of the params 
was defined to accept a Vector of any AbstractString, and then when I 
passed it a Vector of ASCIIStrings, it complained as in my initial message.

Thanks!

Chris

On Friday, October 2, 2015 at 8:11:54 PM UTC-4, Christopher Alexander wrote:
>
> Hello all,
>
> I am trying to figure out what I'm doing wrong with the creation of a 
> composite type, as below:
>
> abstract MyType
>
> type MySpecificType <: MyType
>
> type TestTypes
> type_test::MyType
> end
>
> testing = MySpecificType
>
> x = TestTypes(testing)
>
>
> After running the above, I get a MethodError: 
>
> ERROR: MethodError: `convert` has no method matching 
> convert(::Type{MyType}, ::Type{MySpecificType})
> This may have arisen from a call to the constructor MyType(...),
> since type constructors fall back to convert methods.
> Closest candidates are:
>   call{T}(::Type{T}, ::Any)
>   convert{T}(::Type{T}, ::T)
>  in call at none:2
>
> Any ideas?
>
> Thanks!
>
> Chris
>

Re: [julia-users] Problem with Abstract Types in Type definition

[Christopher Alexander]

Ahh, this is very helpful, thanks!!

Just another question, given that syntax (as a parametric type), how is one 
able to define a type like this:

type MyType
my_num::Real
end

... and then these work without issue:
x = MyType(3.4)
y = MyType(4)

I also ran into this issue when I defined a type where one of the params 
was defined to accept a Vector of any AbstractString, and then when I 
passed it a Vector of ASCIIStrings, it complained as in my initial message.

Thanks!

Chris

On Friday, October 2, 2015 at 9:12:35 PM UTC-4, Isaiah wrote:
>
> See 
> http://docs.julialang.org/en/release-0.3/manual/faq/#how-should-i-declare-abstract-container-type-fields
>
> On Fri, Oct 2, 2015 at 6:06 PM, Christopher Alexander <uvap...@gmail.com 
> > wrote:
>
>> Hello all,
>>
>> I am trying to figure out what I'm doing wrong with the creation of a 
>> composite type, as below:
>>
>> abstract MyType
>>
>> type MySpecificType <: MyType
>>
>> type TestTypes
>> type_test::MyType
>> end
>>
>> testing = MySpecificType
>>
>> x = TestTypes(testing)
>>
>>
>> After running the above, I get a MethodError: 
>>
>> ERROR: MethodError: `convert` has no method matching 
>> convert(::Type{MyType}, ::Type{MySpecificType})
>> This may have arisen from a call to the constructor MyType(...),
>> since type constructors fall back to convert methods.
>> Closest candidates are:
>>   call{T}(::Type{T}, ::Any)
>>   convert{T}(::Type{T}, ::T)
>>  in call at none:2
>>
>> Any ideas?
>>
>> Thanks!
>>
>> Chris
>>
>
>

[julia-users] Re: Any serious quant finance package for Julia?

[Christopher Alexander]

I think the Ito package is a great start, and I've forked it to work on 
adding to it other features of Quantlib (as best as I can!).  I'm glad 
someone mentioned the InterestRates package too as I hadn't seen that.  I 
work at major bank in risk, and my goal is to at some point sell them on 
the power of Julia (we are currently a Python/C++ shop).

- Chris

On Friday, September 11, 2015 at 2:05:39 AM UTC-4, Ferenc Szalma wrote:
>
> Are there any quant finance packages for Julia? I see some rudimentary 
> calendar and day-counting in Ito.js for example but not much for even a 
> simple yield2price or price2yield or any bond objects in Julia packages on 
> GitHub. What is the best approach, using C++ function/object from Quantlib, 
> to finance in Julia?
>