Hi all,Curious what kind of performace can be expected using q or k tocalculate an every-single-tick synthetic fx future from spot and thefullforward curve. Current estimates doing this using existingtechnologies(i.e. non-kx) is 5 hour per year for a high volume currency.One way to simulate this using only equity data would be to use:dia (pretend it’s spot) + spy (pretend it’s 3 month) + aapl (pretendits 6 month)+ goog (pretend it’s 12 month).Then for every-single-tick from these, produce quarterly style immfutures.So for every-single-tick for any of these markets the verb shouldproducea tick for the 4 quarterly futures and use interpolation to get pricesthat don’t match any of the forwards dates perfectly (i.e. spot + interpolated between 6 month and 12 month % #days to get the 3 quarter expiration)I’m using the personal edition to actual test how long it would take.But, it will take a while to reshape my thinking to doing it the kxway.My hope is that i could get the processing time down to an hour peryear…Anyone know if this is realistic or a pipe-dream? What would be arealistic estimate of processing time needed.Much thanks -Joe
Joe,It’s probably easier to generate tables of random ticks than worryaboutconverting equity data over for the simulation.What do your calculations look like (i.e., in C/Java/whatever)? A keyquestionis whether the algorithm when expressed in q is compute or I/O bound.If theq implementation is compute bound and consists of vector operations,it’s unlikelythat anything else is going to be much faster.On Nov 22, 7:27?pm, lowlyworm <jboh…> wrote:> Hi all,>> Curious what kind of performace can be expected using q or k to> calculate an every-single-tick synthetic fx future from spot and the> full> forward curve. Current estimates doing this using existing> technologies> (i.e. non-kx) is 5 hour per year for a high volume currency.>> One way to simulate this using only equity data would be to use:> dia (pretend it’s spot) + spy (pretend it’s 3 month) + aapl (pretend> its 6 month)> + goog (pretend it’s 12 month).> Then for every-single-tick from these, produce quarterly style imm> futures.> So for every-single-tick for any of these markets the verb should> produce> a tick for the 4 quarterly futures and use interpolation to get prices> that don’t match any of the forwards dates> ?perfectly (i.e. spot + interpolated between 6 month and 12 month % #> days to get the 3 quarter expiration)>> I’m using the personal edition to actual test how long it would take.> But, it will take a while to reshape my thinking to doing it the kx> way.> My hope is that i could get the processing time down to an hour per> year…> Anyone know if this is realistic or a pipe-dream? What would be a> realistic estimate of processing time needed.>> Much thanks -Joe</jboh…>
Andy,Thanks for your insight!The calculations look something like (for every tick):imm1 = spot + 3-month/daysTil-imm1imm2 = imm1 + 6-month/daysTil-imm2imm3 = imm2 + 9-month/daysTil-imm3where: daysTil-imm? changes depending on spot date being processedIf I understand you…your saying the I/O bound problemshave a lower performance cost in q than the computation cost.And that I should structure the q code to avoid vector operations.Perhaps, I could use parametrized queries (thinking of them as I/O)and use atomic calculations (i.e. non-vector operations).It would be great if the final code could be as simplistic andminimalistic as the pseudo code written above.Much thanks - JoeOn Nov 29, 2:46?am, andyturk <andyt…> wrote:> Joe,>> It’s probably easier to generate tables of random ticks than worry> about> converting equity data over for the simulation.>> What do your calculations look like (i.e., in C/Java/whatever)? A key> question> is whether the algorithm when expressed in q is compute or I/O bound.> If the> q implementation is compute bound and consists of vector operations,> it’s unlikely> that anything else is going to be much faster.>> On Nov 22, 7:27?pm, lowlyworm <jboh…> wrote:>>>> > Hi all,>> > Curious what kind of performace can be expected using q or k to> > calculate an every-single-tick synthetic fx future from spot and the> > full> > forward curve. Current estimates doing this using existing> > technologies> > (i.e. non-kx) is 5 hour per year for a high volume currency.>> > One way to simulate this using only equity data would be to use:> > dia (pretend it’s spot) + spy (pretend it’s 3 month) + aapl (pretend> > its 6 month)> > + goog (pretend it’s 12 month).> > Then for every-single-tick from these, produce quarterly style imm> > futures.> > So for every-single-tick for any of these markets the verb should> > produce> > a tick for the 4 quarterly futures and use interpolation to get prices> > that don’t match any of the forwards dates> > ?perfectly (i.e. spot + interpolated between 6 month and 12 month % #> > days to get the 3 quarter expiration)>> > I’m using the personal edition to actual test how long it would take.> > But, it will take a while to reshape my thinking to doing it the kx> > way.> > My hope is that i could get the processing time down to an hour per> > year…> > Anyone know if this is realistic or a pipe-dream? What would be a> > realistic estimate of processing time needed.>> > Much thanks -Joe</jboh…></andyt…>
Actually no that’s exactly backwards–IO-bound problems don’t perform
much better in q than in any other language, and vector operations are
where q is at its best.