According to the documentation, the "Volume" keyword returns the volume of the current bar as follows.
For tick and volume-based charts, and time-based charts with resolutions of 24 hours or less:
- the volume traded on Up ticks will be returned if Build Volume On is set to Trade Volume
- the number of Up ticks in the current bar will be returned if Build Volume On is set to Tick Count
For time-based charts with resolutions of 1 day or more:
- the total volume traded will be returned if Build Volume On is set to Trade Volume
- the total number of ticks in the current bar will be returned if Build Volume On is set to Tick Count
When I compare the raw 1 minute trade data using QuoteManager with what I see on a 1 minute chart, I can see that the "Volume" keyword in a study returns the values stored in the "UpVol" column, which agrees with the above. I can tell this is so because sometimes the UpVol is not the total volume and the DownVol has the remaining volume. At other times it has the UpVol equal to all the volume and DownVol is 0. Why this happens I don't know - perhaps IB is doing something odd. In any case, it makes the Volume keyword useless. So, I have to resort to writing a function that makes sure the real volume is returned. I also note that the built-in Volume study plots the correct total volume always. So, I checked the code and sure enough it uses Volume for daily and longer, and Ticks for everything else. So, Ticks is equal to the sum of UpVol and DownVol (not UpTicks and DownTicks, which adds more to the confusion but no matter).
So I wonder how many people are using the Volume keyword in their studies when they should be checking the BarType and using "Volume" or "Ticks" accordingly? Wouldn't it be common sense to make the Volume keyword return the real volume always regardless of the BarType, as the name implies?
Volume saga
- TJ
- Posts: 7743
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2222 times
hahaha... I was caught early on... I learned my lesson, so all my codes are clean.
this volume thing is an EasyLanguage legacy issue that goes back years in history.
but nobody can do anything about it now...
otherwise many legacy codes will not work.
like the old IBM main frame that could be replaced by a Q6600, but can't, because of the legacy software.
this volume thing is an EasyLanguage legacy issue that goes back years in history.
but nobody can do anything about it now...
otherwise many legacy codes will not work.
like the old IBM main frame that could be replaced by a Q6600, but can't, because of the legacy software.
Last edited by TJ on 19 Jun 2009, edited 2 times in total.
- TJ
- Posts: 7743
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2222 times
just a side note...
be careful with the upticks and downticks keywords...
depending on your data provider,
they might not exactly produce uptick volumes and downtick volumes.
That's because most of the data providers stream aggregated quotes.
if there are 2 trades happened between the sending of quote packets,
the 2 trades will be aggregated as ONE tick.
if the first trade is an uptick, the 2nd trade is a downtick, the aggregated trades might be reported as a downtick.
I say "might", because there is an algorithm to "determine" the uptick/downtick interpretation... it is not a clear cut as most people would assume.
be careful with the upticks and downticks keywords...
depending on your data provider,
they might not exactly produce uptick volumes and downtick volumes.
That's because most of the data providers stream aggregated quotes.
if there are 2 trades happened between the sending of quote packets,
the 2 trades will be aggregated as ONE tick.
if the first trade is an uptick, the 2nd trade is a downtick, the aggregated trades might be reported as a downtick.
I say "might", because there is an algorithm to "determine" the uptick/downtick interpretation... it is not a clear cut as most people would assume.