Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
But even 50,000 or 500,000 trades is nothing for instruments as ES (a few minutes, one day, ...)
And it would be always far less than the data definitively embedded in a 1-tick chart.
I have the feeling the purpose of GetTimeAndSales is to have access to the more recent T&S, and then forget it when the newer arrive.
Or do you manage to use SC T&S information in a more historical way?
Nicolas
Can you help answer these questions from other members on NexusFi?
Actually, it was because there were other things in the .cpp not relevant for this thread. So I have copy/pasted the relevant parts in the .txt
Next time, I will make a clean .cpp: will be better!
At this stage, I would like to clarify something because I have perhaps mixed too much your initial question and my own needs. And it could be time to wrap things up.
We both want to access to the T&S information within a bar.
For me, the crucial question is: only in real-time or also historically?
If only real-time...GetTimeAndSales() is the solution. It gives access the most recent 2,000 trades (or more as defined by the user).
It shall not be too difficult to emulate SC's pullback column by finding the most recent High or Low within the T&S and examining all the trades that took place between this High/Low and now.
If historical... GetTimeAndSales() cannot be used.
I see no other way than using a secondary 1-tick chart (and this is also what is suggested by SC documentation).
The challenge is to make the correspondence tick by tick between the main chart (for instance: 2-min) and the 1-tick chart.
At least 2 solutions:
1) the one I proposed above which "synchronizes" the main chart and the 1-tick chart based on the progress of volume
2) overlay-based solution, which is not precise to the tick.
After 1-night sleep, I think that my solution 1), even it seems to work very well and to the tick, is too "heavy". Even for me, it could be too dangerous to use this code for my research. In 2 months, I will have forgotten the logic behind.
So, I am going to explore a solution with overlay. It would not be precise to the tick, but it would be more robust (since based on SC built-in feature) and the differences will only occur at the limit between two bars when trades took place in the same second. Should be OK. More on this later.
Once more, @yonatan, I am aware that this is not your current working subject. Do not feel forced to answer. This message was more for the record, and to clarify things.
I am grateful for all the stuff that you brought here even some of it doesn't directly relate to my need. I learned and will learn a lot from the codes that you attached.
Like you said, the GetTimeAndSales() will probably be good enough for me because at this point I am mostly interested in the recent TnS entries.
Once the market opens I will run the attached very simple code just to make sure that the values that I get from:
are really identical to the very last enteries of the Time and Sales window. (The GetTimeAndSales() will be useless on a replay mode so I wll have to wait for the market to open). If this code works I will go on from there.
Again, this was very helpful for me and I really enjoyed following your progress
I am mentioning them because their code is accessible within studies.cpp
These codes use GetTimeAndSales, and could be considered as a good practice (since written by SC developers).
It could give you ideas for your own codes.
In the above spirit, I have tried to make simple correspondence between a main chart (here: 15-second chart) and a 1-tick chart.
I have renounced to make a correspondence "to the tick" and I'm OK to use timestamp as SC does with its overlay mechanism.
In this example, I focus on 21:46:30 bar. Next bar is at 21:46:45.
I have used 3 methods. Each of the 3 methods gives a different correspondence between main chart and 1-tick chart. To avoid any misunderstanding... I do not say that it is a "bug" of SC. Not at all. Everything is explained by the overlay mechanism.
Method 1: Overlay of 15s chart on 1-tick chart.
On the 15s chart, I have plotted the Bar Number with a very simple study ( sc.Subgraph[0][sc.Index] = (float) sc.Index; ).
And I have overlaid this 15s Bar Number on the 1-tick chart.
It allows seeing all the ticks associated with 21:46:30:
- the first is the last tick before 21:46:30
- the last is the tick before the last tick with 21:46:45 timestamp
Method 2: overlay of 1-tick chart on 15s chart
On the 1-tick chart, I have plotted the Bar Number with a very simple study ( sc.Subgraph[0][sc.Index] = (float) sc.Index; ).
And I have overlaid this 1-tick Bar Number on the 15-s chart.
The unique tick associated with 21:46:30 is the last tick before 21:46:45
Method 3: use of SC built-in functions
On the 15s chart, I have used the functions sc.GetNearestMatchForDateTimeIndex and sc.GetContainingIndexForDateTimeIndex to know the corresponding bar on the 1-tick chart.
The tick associated with 21:46:30 is the first tick with 21:46:30 timestamp
I will probably use one of three methods to have access historically to T&S within any bar. More on this later...
Don't worry... this message and the 3 following ones are probably the last of the series!
Reminder: we want to access to the T&S information within a bar.
- GetTimeAndSales() cannot be used historically;
- I have proposed above a code which "synchronizes" the main chart and a secondary 1-tick chart based on the progress of volume; if no mistake, this allows an access to all ticks within the bar to the tick but the code is rather complicated.
I am now exploring the last idea: make an easy correspondence between the main chart and a secondary 1-tick chart using timestamps.
It could be done with (i) overlays or (ii) SC built-in function as "sc.GetNearestMatchForDateTimeIndex".
Both are very similar (use of timestamp). The exact differences have been illustrated in the previous message. I have chosen to use the SC built-in function since it is the easiest way (no overlay to perform).
In the two following messages, I will use this method to:
1) emulate the volume of each bar by adding the volume of all ticks identified as belonging to the bar;
2) emulate SC's footprint (Numbers Bars)
As we know (and in consistency with SC documentation), overlays and sc.GetNearestMatchForDateTimeIndex are not precise to the tick, since there could be several ticks with the same timestamp (= several trades in the same second).
To evaluate whether this is a problem or not, we will compare emulated and built-in results in the 2 above-mentioned emulations.
At each bar, by using sc.GetNearestMatchForDateTimeIndex, the study identifies the ticks of the secondary 1-tick chart which belong to the bar (not taking into account the well-known timestamp issue).
Then the study adds the volume of all these ticks.
And compares it to the "normal" volume of the bar.
Quite close!
(Just tested on historical data. No test on replay or real-time.)
We are not going to emulate the whole footprint, but only the ask volume of the highest price of the bar. The code can very easily be adapted for any other information of the footprint.
At each bar, by using sc.GetNearestMatchForDateTimeIndex, the study identifies the ticks of the secondary 1-tick chart which belong to the bar (not taking into account the well-known timestamp issue).
Then the study adds the volume of these ticks... but only if the trade was at the ask and the trade took place at the highest price of the bar.
And compares it to the "normal" information given by the footprint.
Quite close, even if there are some discrepancies (due to the timestamp effect).
(Just tested on historical data. No test on replay or real-time.)