Time Profile

[TheNegotiator 13]

Hi,

 

I have a question for any coders out there. How difficult might it be to code an indicator to display a profile of time at price? That is to say the amount of time a price is either the bid or the offer. For clarification I am currently on ninja but if any other platform is more suitable I am interested in any suggestions.

 

Thanks,

 

TheNegotiator.

[Tams 20]

Hi,

 

I have a question for any coders out there. How difficult might it be to code an indicator to display a profile of time at price? That is to say the amount of time a price is either the bid or the offer. For clarification I am currently on ninja but if any other platform is more suitable I am interested in any suggestions.

 

Thanks,

 

TheNegotiator.

 

When we talk about TP anaylsis, most people's expectation is at the sub-seconds level. ie. in microseconds terms.

 

TradeStation (EasyLanguage) were designed to do analysis down to the minutes level. It can do analysis at the tick level, but without the time component.

 

MultiCharts, with its extended-EasyLanguage keywords, can do sub-minute analysis. (ie at the seconds level). But it is still far from the microsecond level.

 

 

So, if your expectation is at or above the seconds level... it can easily be done.

At the sub-second level, it can be done, but will require a bit more work.

[TheNegotiator 13]

How about in Ninjascript?

[TheNegotiator 13]

If you have all the LAST data, surely it could be calculated from this. Then it depends on how accurate your timestamp is no?

 

I know that this is then an approximation for some markets.

[Tams 20]

How about in Ninjascript?

 

i haven't used ninja in a long time... don't know.

[Tams 20]

If you have all the LAST data, surely it could be calculated from this. Then it depends on how accurate your timestamp is no?

 

I know that this is then an approximation for some markets.

 

yes, if your expectation is at or above the seconds level,

pretty well any advanced level programmable charting software can do the trick.

The timestamp is of minor consequence, as long as the difference is static.

 

 

do you have a mock up on how the analysis would look like?

[uexkuell 10]

That is to say the amount of time a price is either the bid or the offer.

 

Please specify what the task should be:

 

 

Assume you have a hypothetical sequence of trades:

 

Columns contain:

- Time

- Price

- B for Bid, A for Ask

- Volume

 

1000 12230 B 1

1500 12230 B 2

2700 12230 B 2

4300 12231 A 1

5400 12231 A 2

5600 12230 B 1

 

Time arbitrarily set as milliseconds from e.g. 9:30 am.

 

So here the program should return 3300 which means: 3300 milliseconds trading at bid until a trade at ask happens.

Then return 2300 (millisec trades at ask).

 

Or are you looking for something else?

[TheNegotiator 13]

Okay. The idea is for a day/composite profile of time spent at each price. It could end up looking very much like a volume profile (which could I'm guessing also be easily incorporated). So whenever a price is a market price bid or offer, it accumulates time by this price on the profile.

[uexkuell 10]

The idea is for a day/composite profile of time spent at each price. It could end up looking very much like a volume profile (which could I'm guessing also be easily incorporated). So whenever a price is a market price bid or offer, it accumulates time by this price on the profile.

 

Time between trades is quite often during the day ranging in very small sizes (few milliseconds).

 

AFAIK the usual trading platforms / their built-in languages are not capable of accurately following such fast transitions.

 

Many projects in Ninja got into trouble trying to use small time spans in computations.

[TheNegotiator 13]

Time between trades is quite often during the day ranging in very small sizes (few milliseconds).

 

AFAIK the usual trading platforms / their built-in languages are not capable of accurately following such fast transitions.

 

Many projects in Ninja got into trouble trying to use small time spans in computations.

 

If you were using it out of hours as an analysis tool, would it still be a problem or is it an intrinsic language issue?

[uexkuell 10]

If you were using it out of hours as an analysis tool, would it still be a problem or is it an intrinsic language issue?

 

Aside from the main trading hours still regularily trade bursts can be observed which would probably have the potential to confuse anything that is written in an interpreted language.

[uexkuell 10]

If you were using it out of hours as an analysis tool, would it still be a problem or is it an intrinsic language issue?

 

Aside from the main trading hours still regularily trade bursts can be observed which would probably have the potential to confuse anything that is written in an interpreted (=relatively slow) language.

[TheNegotiator 13]

Okay then, thanks anyway.

[Tams 20]

TS uses p-code.

MC is compiled.

[danjurgens 10]

You are probably limited by the time stamp of the data provided. Anything that goes sub second can only be determined on the live data feed, and must assume constant quote dissemination and local thread scheduling latency on your PC).

 

However I would guess that using second data you could get a very reasonable approximation, that would unlikely differ much if at all visually from a milli or microsecond resolution, by distributing the second evenly over all prices touched during that second.

 

I would also venture a guess that it wouldn't differ much visually from a volume profile.

 

If you are interesting in attempting sub second analysis in NT search for the Gom indicators. There is a version of his GomRecorder that records millisecond timestamps so that'd probably ease your workload considerably, and allow you to retain the data after refreshing your charts. Assuming dissemination and scheduling latency are constant-ish it's probably an improvement over the second approximation, but may be a distinction without a difference.