Support Board
Date/Time: Sun, 22 Dec 2024 05:07:15 +0000
[Locked] - Trades Executed at Bid/Ask
View Count: 6904
[2013-08-08 04:17:35] |
Sierra Chart Engineering - Posts: 104368 |
This is done through Global Settings >> Graphics Settings. Text colors are currently using the Chart/Trade DOM Profit Loss Up/Down colors. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
[2013-08-08 05:20:23] |
joshtrader - Posts: 492 |
Thank you, that works. A question to clarify after observing the behavior: so, a number at a price in the bid column means that the last time this price traded at the bid, this was the number of contracts that traded there. When volume trades at the bid at that price again, and only then, will the number reset--correct? In other words, if the bid number at 1692.50 is 13, with the current bid/offer being 92.25/92.50, then only when 92.50 becomes the best bid and actually has volume transact there will the 13 be reset to the newly traded volume, which will then accumulate as long as no other price trades at the bid--correct? |
[2013-08-08 07:24:43] |
eagle - Posts: 92 |
Great addition! Thank you! Outstanding! These two values are used on a comparative basis. So, when either one of them at any particular price level is reset; then, both of them at that price level need to be reset. In other words, both values at a particular price level need to be reset simultaneously. With pre-release 1006, is this what's happening? (I'm not sure, but it doesn't seem to be. The values seem to be resetting separately.) As long as you do not create a separate field for these values in Global Settings >> Graphics Settings, would you please change the colors from Profit Loss Up/Down to "TradeDOM Ask Depth Volumes" for "Recent Ask Volume" and to "TradeDOM Bid Depth Volumes" for "Recent Bid Volume". (This will effectively reverse the current Red/Green color scheme.) Or, if you do create a separate field for these values, please use the same default colors as the Depth Volumes of the same type. Thanks. |
[2013-08-08 10:22:46] |
joshtrader - Posts: 492 |
In other words, both values at a particular price level need to be reset simultaneously.
Why? I disagree. What would the bid be reset to at X if only the offer trades at X? Zero? That would serve no purpose. Let's say 1500 just traded at the bid at X, and now X goes offer and starts trading. Don't you want to know that 1500 just traded at the bid at X? The whole point of this is that it shows you "last time X traded bid/offer, this was how much" and unnecessarily resetting both at a price when only one trades misses a valuable piece of information. |
[2013-08-08 12:25:13] |
eagle - Posts: 92 |
Why? I disagree.
I see both values at a particular price level only resetting once, when price first trades at that level, regardless of whether it trades at bid or at offer. What I had in mind was: Let's say 1500 just traded at the bid at X. The value "1500" prints as recent bid volume and the recent ask volume value goes blank. Now X goes offer and starts trading. Trading is still at the same price level, X. The number of contracts traded at offer print as recent ask volume, while the value "1500" remains as the recent bid volume value. The "1500" value would never reset until the contract trades away from price X and then returns once again and trades at price X. The information lost from a reset is valuable, but I can deduce that information from the Volume At Price values, which continue to accumulate. What I had in mind preventing and not seeing was: Let's say 1500 just traded at the bid at X. The value "1500" prints as most recent bid volume and the recent ask volume value does not reset but remains as it is, which just happens to be a value of "4500" from 15 minutes prior, when the contract last traded at price X. The next trade after the 1500 print is at a different price than price X, leaving "1500" at price X for most recent bid volume and "4500" at price X for most recent ask volume. That's a misleading picture, because the actual most recent ask volume at price X is "0". I'm not sure, but I think this is what is currently happening. Date Time Of Last Edit: 2013-08-08 12:28:06
|
[2013-08-08 18:28:35] |
skoosht - Posts: 13 |
When I add those columns to my ES trade DOM it adds the columns but the numbers don't show up. Just blank, no numbers or colors. Am I missing a step? thanks, |
[2013-08-08 18:51:02] |
N!co - Posts: 140 |
i have the same problem User26917, symbols like ES , ZB, ZN , DAX, BUND, BOBL don't work for me Date Time Of Last Edit: 2013-08-08 18:51:20
|
[2013-08-08 19:57:38] |
eagle - Posts: 92 |
Sierra Chart Engineering wrote: When the market goes back to a prior price level, the Bid Volume and Ask Volume are reset. That makes sense. But that is not how it is currently programmed.For clarification, my interpretation of the above quote is, "When the market trades at a new price level, if there are existing Bid Volume and/or Ask Volume values at the new price level, both the Bid Volume and the Ask Volume values at the new price level are reset." Currently, when the market trades at a new price level, if any value is reset, only one of the two values at the new price level are reset. And sometimes, neither of the two values are reset when price trades at a new price level. Apparently, the market trading at a new price level is not the only criteria that the program is using to determine whether or not to reset any value(s). The current resetting mechanism appears to be haphazard. It may even be that different criteria are being used to reset a bid volume value than what's being used to reset an ask volume value. Without further clarification from SC Engineering, I have no idea how to attach any meaning to this new data. |
[2013-08-08 21:48:22] |
Sierra Chart Engineering - Posts: 104368 |
We will be reviewing the recent comments here and the code and making the appropriate changes and commenting.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
[2013-08-08 22:23:26] |
Al SC Developer - Posts: 434 |
The bid/ask volume levels accumulate when the level is traded at without changing. So, if you trade at the same bid value multiple times, the bid volume is accumulated at that level. Levels are currently reset on the bid/ask sides independently. The number is reset when a bid or ask level is traded at, that is different than the prior bid/ask trade. So for example, if the best ask moves and trades, any ask volume at that new level is reset and then the new trade volume is added (it never really goes to zero). This matches the behavior in the referenced Jigsaw DOM. Date Time Of Last Edit: 2013-08-08 22:23:55
|
[2013-08-08 23:36:51] |
joshtrader - Posts: 492 |
The current resetting mechanism appears to be haphazard. It may even be that different criteria are being used to reset a bid volume value than what's being used to reset an ask volume value.
It is very simple. Bid volume at price "X" will reset only when the following two conditions occur (assuming X is currently bid and is accumulating): 1) A price other than X trades at the bid (not only becomes bid) 2) X becomes bid and trades at the bid Substitute "ask" for "bid" in the above and the rules are identical. I watched this all day today, and it works just as described. It's that simple, far from haphazard. Date Time Of Last Edit: 2013-08-08 23:37:12
|
[2013-08-08 23:42:50] |
eagle - Posts: 92 |
I'm gaining new information and changing my perspective on resets. I'm reviewing everything I can find on the Jigsaw DOM. Thanks c734xu for the YouTube link. This matches the behavior in the referenced Jigsaw DOM.
If that's true, I'll be delighted and I'll learn to use this new tool. I'm excited about all this!From the Jigsaw Product Manual: Current Trades
The Centre columns shows the number of contracts traded against the inside bid and ask "This time around". In this example we can see 90 contracts have traded at 1317.75 and 0 contracts have traded at 1318.00. When this 1317.75/1318 became this inside bid/offer, we reset the number of trades here and started to accumulate them. So, if we leave a price and come back to it, the qty of contracts in these columns is reset. There is an exception to this. If we leave a price for a short period of time and come back to it, then we do not clear the traded quantities. By default that "short period of time" is set to 2500 milliseconds (2.5 seconds). The idea is that we show the number of contracts to push through the level but it often leaves a level for just a short amount of time and comes back to it. In that case, we don't consider it to have really left. Clear Trades Timer When we leave a price and return to it later, the Current Trades value is reset. If we just move out of the area for a very short period – for example we tick up and it immediately ticks down, we will not clear the Current Trades. This setting defines how much time we can spend outside an area before clearing it when we return. This is an advanced setting. Our recommendation is to leave this at 2500 milliseconds (2.5 seconds). So, instead of using a change in the last traded price as a trigger for resetting, Jigsaw instead uses a change in the last traded price with a change in the last "inside bid/inside ask pair" (best bid/best offer pair). (Which implies a change in trading from bid to ask, or vice-versa.) And there's this thing about that "short period of time" exception. Personally, I don't think that necessarily needs to be configurable, but it does need to be incorporated into the program. Date Time Of Last Edit: 2013-08-08 23:53:07
|
[2013-08-09 00:08:26] |
joshtrader - Posts: 492 |
So, instead of using a change in the last traded price as a trigger for resetting, Jigsaw instead uses a change in the last traded price with a change in the last "inside bid/inside ask pair" (best bid/best offer pair). (Which implies a change in trading from bid to ask, or vice-versa.)
SC does not use a change in the last, it is also using a change in the inside bid/offer to reset, with the exception that SC does not simply reset on a change of the bid/offer, but requires that a different bid or offer actually trade. For example, 1691.50 is bid and trades 50, then it goes offer and trades 100, and then goes back to bid, where it trades 25. The SC values will be 75 and 100 for 1691.50, as it did not reset because 1691.25 did not trade at the bid. So even though the inside BBO changed, a different bid did not actually trade, so it does not reset. I do like a time/distance threshold setting as a possibility as well. For example, do not reset until 3 seconds have passed, or until a price 3 ticks or more away trades. Date Time Of Last Edit: 2013-08-09 00:09:40
|
[2013-08-09 00:26:25] |
N!co - Posts: 140 |
+1 I do like a time/distance threshold setting as a possibility as well. For example, do not reset until 3 seconds have passed, or until a price 3 ticks or more away trades.
|
[2013-08-09 13:33:42] |
eagle - Posts: 92 |
joshtrader wrote: SC does not simply reset on a change of the bid/offer, but requires that a different bid or offer actually trade.
Sorry, that's what I attempted to describe. However, I was wrong about Jigsaw. You are correct, Jigsaw does not require a trade for the reset.I like that SC does require a trade to take place before doing a reset. |
[2013-08-09 13:36:53] |
ganz - Posts: 1048 |
I like that SC does require a trade to take place before doing a reset.
+1yes, this make sense |
[2013-08-09 13:53:49] |
eagle - Posts: 92 |
Al SC Developer wrote: Levels are currently reset on the bid/ask sides independently. [...] This matches the behavior in the referenced Jigsaw DOM.
Actually, Jigsaw resets (blanks out or prints a non-accumulated value) both the best bid and the best offer simultaneously, even if the spread widens. I'd like for SC to work the same way.This action can be clearly seen in the first few minutes of the demonstration video on this page: http://www.jigsawtrading.com/products/depthsales/ If you stop the video at 03:40, you'll see where both the best bid value and the best offer value were blanked out when the best bid/best offer changed. This reset did not require a trade. As I stated in a previous post, I like that you are requiring a trade to take place before resetting. Although, I'm not firm on this. I would gladly defer to anyone experienced in using order flow or in using Jigsaw who would like to see SC work the same as Jigsaw regarding resets not requiring a trade. There's plenty of evidence in neuroscience that better decisions are made on less information--part of the K.I.S.S. principle. Also, it stands to reason that the fact a trade did not occur is indeed relevant information, and is not necessarily a loss of information, but is a gain of more current, and therefore more relevant, information. Also, I think it's a reasonable assumption that a lot of thought has gone into the design of the Jigsaw interface. The reset exception/threshold, that we all seem to like, is also evident in those first few minutes of the video. Date Time Of Last Edit: 2013-08-09 14:17:37
|
[2013-08-09 14:12:07] |
Al SC Developer - Posts: 434 |
The SC implementation is based on trades, so will not do any resetting based solely on changed best bid/ask. We can look into the timer/threshold option. Date Time Of Last Edit: 2013-08-09 14:13:01
|
[2013-08-09 14:21:41] |
eagle - Posts: 92 |
The SC implementation is based on trades, so will not do any resetting based solely on changed best bid/ask. OK. Can you reset both the best bid and the best offer when the trade hits? When you reset one the value in the other is stale.We can look into the timer/threshold option. Thank you!
Date Time Of Last Edit: 2013-08-09 14:27:49
|
[2013-08-09 15:10:09] |
Al SC Developer - Posts: 434 |
Can you reset both the best bid and the best offer when the trade hits?
We will look at this. |
[2013-08-09 23:23:41] |
joshtrader - Posts: 492 |
I would like to ask if others who have used the feature would comment. Personally, I do not want a top of the book change to reset. A scenario is this: ES is trading at the LOD, at 1685.00. 85 is bid, 85.25 is offer. 2000 orders hit the bid, moving the bid to 84.75, while 85 goes offer, where it is lifted with 1000 contracts. Anyone who watches ES knows this kind of behavior happens all the time, every day. What I would see is 2000 at the 85 bid, and 1000 at the 85 offer, with the BBO now being 85.00/85.25. If the 85 bid were to be reset when 84.75 went bid, I would never know that 2000 hit the bid at 85. This is just one example. I just don't see the practical benefit of resetting the accumulator on a BBO change. Also, it stands to reason that the fact a trade did not occur is indeed relevant information, and is not necessarily a loss of information, but is a gain of more current, and therefore more relevant, information. Also, I think it's a reasonable assumption that a lot of thought has gone into the design of the Jigsaw interface.
A trade not occurring is relevant, but you have the lack of a print on the next price that confirms that. I just don't quite follow your logic here. It's a very good assumption that Peter put a lot of thought into his program, I know him and can vouch for his attention to detail. However, that is his program, and this is not a replica, so there is no reason to duplicate something exactly, just because it's done a certain way somewhere. Perhaps there could be several options: 1) Reset on B/O change 2) Reset on new trade at new B/O and 1) Reset only after whichever above is selected and ___ seconds 2) Reset only after whichever above is selected and ___ ticks minimum change in last price 3) Reset only after whichever above is selected and ___ volume traded Just some ideas. I think it should be kept as is for the next week or two, and give people a chance to use it, and see which improvements and changes they might like to see. |
[2013-08-10 11:32:25] |
eagle - Posts: 92 |
I apologize if any of my previous posts have been confusing. My current suggestion is that 1) the most recent bid trade volume at the best bid, and 2) the most recent ask trade volume at the best offer, and 3) any intermediate values, if the spread is more than one tick, will be reset when a trade occurs 1) at a new price level since the last trade, and 2) the best bid price has changed since the last trade, and 3) the best offer price has changed since the last trade. joshtrader wrote: ES is trading at the LOD, at 1685.00. 85 is bid, 85.25 is offer. 2000 orders hit the bid, moving the bid to 84.75, while 85 goes offer, where it is lifted with 1000 contracts. Anyone who watches ES knows this kind of behavior happens all the time, every day. What I would see is 2000 at the 85 bid, and 1000 at the 85 offer, with the BBO now being 85.00/85.25. If the 85 bid were to be reset when 84.75 went bid, I would never know that 2000 hit the bid at 85.
Based on my current suggestion, after 84.75 goes bid, when the 85 offer is lifted with 1000 contracts, the 85 offer is reset, printing 1000. The 85 most recent bid volume is not reset. But the 84.75 most recent bid volume is reset with a blank.The 85 bid would only be reset if an 85 bid was hit or an 85.25 offer was lifted. The only way one could not know that 2000 hit the bid at 85 would be if a subsequent trade hit the bid at 85 after the 2000 hit, or if an offer was lifted at 85.25 after 2000 hit the 85 bid. And if SC implements the reset exception, neither of those two events would prevent one from knowing about the 2000 at 85. joshtrader wrote: I just don't quite follow your logic here.
I just don't see any value in comparing, for example, the current hits on the bid with the lifting of offers twenty minutes ago. For a relevant comparison, it seems to me that if the current hits on the current best bid are reset, then the current hits on the current best offer should be reset as well.joshtrader wrote: 1) Reset on B/O change
SC has ruled out number 1.
2) Reset on new trade at new B/O Date Time Of Last Edit: 2013-08-11 09:06:11
|
[2013-08-10 16:25:55] |
crazybears - Posts: 314 |
Hi thanks SC teams , this is great tool :) would be great to have the snapshot columns that show the changing of the quantity at bid and ask thanks |
[2013-08-10 22:51:03] |
eagle - Posts: 92 |
joshtrader wrote: However, that is his program, and this is not a replica, so there is no reason to duplicate something exactly
An alternative suggestion for the SC Recent Bid/Ask Volume function:Have no automatic resetting of any values whatsoever. Have all values automatically accumulate. Thus, no need for any reset exception mechanism. Only have a manual reset option to clear all accumulated values. This reset option could be added to an existing context, shortcut, or scale menu. Then, I could manually reset all accumulated values as price approaches a level of interest in order to watch the order book develop if and when price reaches my level of interest. Or, I could manually reset all accumulated values during a period of accumulation/distribution in order to watch the current development of the order book. Examples of ideas for other possible manual reset options are provided by existing Jigsaw functions: a) Clear All: Clears current trades and total trades. Does not clear volume profile. b) Clear Current: Clears current trades only. c) Clear Up: Clears current trades above inside ask/offer price. d) Clear Down: Clears current trades below inside bid price. Jigsaw "Current Trades" is SC Recent Bid/Ask Volume. I think Jigsaw "Total Trades" is accumulated Current Trades with no automatic resets, which Jigsaw displays in a separate set of columns from the Current Trades columns. I encourage others to participate in this thread . . . Date Time Of Last Edit: 2013-08-11 08:54:55
|
[2013-08-11 08:33:07] |
ganz - Posts: 1048 |
Al SC Developer Hello. We can look into the timer/threshold option.
Can you reset both the best bid and the best offer when the trade hits? - We will look at this.
It would be very impressive to get all of these new options for the columns to make SC even better than Jigsaw does the job. Also new ACSIL members for these new columns in order to use custom DLL will make them perfect, imho. TY Date Time Of Last Edit: 2013-08-11 08:38:30
|
[2013-08-15 02:06:32] |
Sierra Chart Engineering - Posts: 104368 |
What started out as seemingly a somewhat simple implementation to perform a basic function has now become feature with many enhancement requests. We do thank you all for all of these additional postings, but we cannot spend further time on this. We have many other higher priorities. This will have to be reviewed probably sometime later in the year. At this time there will not be further review. We will put together clear documentation on how the functionality currently works. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2013-08-15 02:06:57
|
To post a message in this thread, you need to log in with your Sierra Chart account: