Gomcd for NT

Questions about MultiCharts and user contributed studies.
scalp2000
Posts: 13
Joined: 16 Jan 2010

Gomcd for NT

Postby scalp2000 » 19 Apr 2010

You know the indicator gomcd for NT?
Is there a version for multicharts?

http://www.tinyurl.com/y327cjj

http://www.NT-support2.com/vb/ ... ostcount=3

GomCD (Cumulative Delta)

This indicator is used to plot Delta (volume signed +/- depending if is considered buying volume(+) or selling volume(-).

The data is plotted in the same format than the main price data : Candlesticks, OHLC and HiLo are supported.

Calculation Mode

* BidAsk : if (tick >= ask) the volume is buying ; if (tick <= bid) the volume is selling
* UpDownTick : if (tick > previous tick) volume is buying ; if (tick < previous) tick volume is selling
* UpDownTickWithConinuation : if (tick > previous tick) volume is buying and any further volume@tick is buying ; if (tick < previous)tick volume is selling and any further volume@tick is selling

User avatar
RobotMan
Posts: 375
Joined: 12 Jul 2006
Location: Los Altos, California, USA
Has thanked: 31 times
Been thanked: 13 times
Contact:

Postby RobotMan » 19 Apr 2010

Hi scalp2000,

Indicators like this do exist and are easy to code up for MC. However, at the moment, the reserved word "intrabarpersist" needed to calculate it, does not work properly on every tick at the present. (Do a search on this forum for "intrabarpersist" for the full story and many examples of code) From what I understand, it is a well known and, hopefully, understood bug by TSS and is currently being addressed in a future release of version 6.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 19 Apr 2010

Another concern is that keywords like currentbid and currentask at present work only in real-time, and so back-testing of this type of thing on MultiCharts is not as straight forward.

And, another concern is that few of the retail data feeds pass through every bid/ask update, so in some cases, we get into situations where the bid/ask we have available aren't the latest that would be available if we looked at it historically, and this can result in the miscategorization of trades, or for instance, of different users getting slightly different calculated "deltas" while using the same software, indicators and datafeed - just because they're connected to different data feed servers via dns round robin.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 104 times

Postby janus » 19 Apr 2010

- just because they're connected to different data feed servers via dns round robin.
I hope they are using something better than the standard DNS round robin approach. They should be using dual load balancing hardware to provide both more accurate load balancing and redundancy. Also, the DNS round robin approach is problematical if one of the servers stops working, unless they are using a modified form of DNS that is more aware of the status of the servers. In any case, load balancing hardware is better especially for high availability clusters.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 19 Apr 2010

...the DNS round robin approach is problematical if one of the servers stops working, unless they are using a modified form of DNS that is more aware of the status of the servers...
Indeed, this very thing has been observed to be a problem with eSignal in the past. We would get "stuck" on a server that wasn't working for whatever reason - as an example, the server might have real-time but no historical data because of some temporary malfunction, or no historical data for only certain instrument classes. It would be necessary to reboot or flush the DNS cache, then reconnect to get assigned a new cm*.esignal.com server to correct this when it happened, which is an inconvenience, and hard to explain to those who don't have a technical background.


Return to “MultiCharts”