Stop Limit orders

Questions about MultiCharts and user contributed studies.
SUPER
Posts: 622
Joined: 03 Mar 2007
Has thanked: 99 times
Been thanked: 80 times

Stop Limit orders

Postby SUPER » 12 Mar 2009

Hi Andrew Kirillov,

Are Stop Limit orders being planned for MC and if so which version can we expect them please.


Regards
Super

ppan
Posts: 106
Joined: 31 Jan 2007
Has thanked: 2 times

Postby ppan » 06 May 2009

The stop limit order is very useful for auto trading.

oakshadows
Posts: 33
Joined: 01 May 2007

Postby oakshadows » 12 May 2009

I, too, would llike to see Stop Limit orders added to MC for Sync autotrading.

Interactive Brokers supports Stop Limit orders.

brendanh
Posts: 154
Joined: 07 Apr 2007

Postby brendanh » 12 May 2009

+1. Stop-limit orders would give MC a big competitive advantage over TS.

Being able to put a limit on how much slippage you are prepared to accept on stop orders can significantly reduce trading costs.

From Investopedia: "let's assume that ABC Inc is trading at $40 and an investor wants to buy the stock once it begins to show some serious upward momentum. The investor has put in a stop-limit order to buy with the stop price at $45 and the limit price at $46. If the price of ABC Inc. moves above $45 stop price, the order is activated and turns into a limit order. As long as the order can be filled under $46 (the limit price), then the trade will be filled."

User avatar
TJ
Posts: 6553
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 966 times
Been thanked: 1893 times

Postby TJ » 16 May 2009

stop-limit is a bit more complicated than other order.

not all the exchanges accept stop-limit orders.

some brokers only selectively support stop-limit orders...
(as a broker side service)

so you want MC to support it as a client side service?

Guest

Postby Guest » 17 May 2009

Stop Limit is really important

I would llike to see Stop Limit orders added to MC for Sync autotrading. as well
Interactive Brokers does supports Stop Limit orders.

Emmanuel

SUPER
Posts: 622
Joined: 03 Mar 2007
Has thanked: 99 times
Been thanked: 80 times

Postby SUPER » 18 May 2009

stop-limit is a bit more complicated than other order.

not all the exchanges accept stop-limit orders.

some brokers only selectively support stop-limit orders...
(as a broker side service)

so you want MC to support it as a client side service?


TJ,

NT trader supports it so I don't think it would be difficult thing for MC to incorporate, I guess you would describe it as client side service?

Sometime back Andrew did indicate that they were looking to support Stop-Limit order.

We are considering of adding stop limit orders too.
We don't want to add a low level function. We want to integrate it to our engine which will mean
1. You can use plain English statements as you do with current stop, limit and open/close orders
2. Stop limit functions will work as they should in backtesting and you will be able to simulate real trading.
Considering that we are adding precise backtesting it is really important.

User avatar
Andrew Kirillov
Posts: 1589
Joined: 28 Jul 2005
Has thanked: 2 times
Been thanked: 31 times
Contact:

Postby Andrew Kirillov » 18 May 2009

We definitely add the stop limit orders. We will make them native for exchanges that support it and will have emulate on our end if it is not possible.
As I mentioned before the main issue is that we want to simulate stop-limit orders in backtesting mode too. It is quite complicated and this is why we need to work on it.
Does NT do it?

SUPER
Posts: 622
Joined: 03 Mar 2007
Has thanked: 99 times
Been thanked: 80 times

Postby SUPER » 18 May 2009

Andrew,

Thanks for re-confirming that Stop-Limit orders will be available soon.

NT has it and you you can find more about it at:

http://www.NT.com/Help ... tStopLimit

Regards
Super

User avatar
Andrew Kirillov
Posts: 1589
Joined: 28 Jul 2005
Has thanked: 2 times
Been thanked: 31 times
Contact:

Postby Andrew Kirillov » 18 May 2009

I do understand it. I asked if NT support stop-limit simulation in backtesting? It seems the most complex feature for us, but we are sure it is necessary to support it.

ppan
Posts: 106
Joined: 31 Jan 2007
Has thanked: 2 times

Postby ppan » 18 May 2009

Andrew,

I think the backtesting for stop-limit is quite complicated but not very useful. I only need MC to convert the stop order to stop-limit order in auto trading.

For example,
1. MC can add a AUTO-LIMIT value and AUTO-TIME value in auto trading option.
2. If the AUTO-LIMIT value is present, the MC will use stop-limit order instead of stop order in auto trading. The limit value of the stop-limit order is the stop value +/- the AUTO-LIMIT value.
3. If the stop is hit but the limit order is not hit for AUTO-TIME second, MC will convert the limit order to a market order.

I think it is not complicated to add this feature.

SUPER
Posts: 622
Joined: 03 Mar 2007
Has thanked: 99 times
Been thanked: 80 times

Postby SUPER » 19 May 2009

I do understand it. I asked if NT support stop-limit simulation in backtesting? It seems the most complex feature for us, but we are sure it is necessary to support it.


Andrew,

Since it is a low level function similar to what you are proposing it seems to work on backtesting. I checked it out last night on a simple cross over strategy.

p.s. please be aware this is my first use of NT.....it is free so anyone can test this out for confirmation.

Regards
Super

SUPER
Posts: 622
Joined: 03 Mar 2007
Has thanked: 99 times
Been thanked: 80 times

Postby SUPER » 19 May 2009

Andrew,

I think the backtesting for stop-limit is quite complicated but not very useful. I only need MC to convert the stop order to stop-limit order in auto trading.

For example,
1. MC can add a AUTO-LIMIT value and AUTO-TIME value in auto trading option.
2. If the AUTO-LIMIT value is present, the MC will use stop-limit order instead of stop order in auto trading. The limit value of the stop-limit order is the stop value +/- the AUTO-LIMIT value.
3. If the stop is hit but the limit order is not hit for AUTO-TIME second, MC will convert the limit order to a market order.

I think it is not complicated to add this feature.


ppan,

I don't think half solution will work as you need to have synchronisation with the chart also, in your item (3) conversions only comes into play when order is filled at chart level and not at the broker to get complete sync, I don't think in manually trading one will convert StopLimit orders to market after lapse of certain time and in auto trading we are merely trying to emulate same thing. The conversion mechanism is to do more with chart-broker synchronisation.


Regards
Super

User avatar
Andrew Kirillov
Posts: 1589
Joined: 28 Jul 2005
Has thanked: 2 times
Been thanked: 31 times
Contact:

Postby Andrew Kirillov » 19 May 2009

I must disagree and I have several rationales:
1. The low level functions don't work good in our experience, because they conflict with backtesting and execution logic. Our internal execution logic on the chart must know what you do. Otherwise you will not get on charts what you have ob the broker and vise versa. If you simply call low level functions the engine has not clue what you do.

2. Low level functions force traders to control the execution logic on their end and it is harder work and not appropriate for beginners. We like user-friendly programs.

3. I believe you should have possibility to backtest your stop limit amounts first before you decide what will be your limit value. Otherwise you will guess.

This is why we want to make this feature high level.

SUPER
Posts: 622
Joined: 03 Mar 2007
Has thanked: 99 times
Been thanked: 80 times

Postby SUPER » 19 May 2009

Andrew,

Thanks for clarification.

You have much better understanding of the subject so I leave it with you to provide us with a practical and workable solution.

Please can you tell us when we can expect this new feature.

Regards
Super

User avatar
Andrew Kirillov
Posts: 1589
Joined: 28 Jul 2005
Has thanked: 2 times
Been thanked: 31 times
Contact:

Postby Andrew Kirillov » 22 May 2009

I think we will implement stop-limit orders in MultiCharts 6.

Kingjelly
Posts: 25
Joined: 23 Jan 2008

Postby Kingjelly » 17 Jan 2010

Is this still planned for MC 6, or is it in there and I just don't know it?

janus
Posts: 747
Joined: 25 May 2009
Has thanked: 41 times
Been thanked: 83 times

Postby janus » 19 Jan 2010

I think we will implement stop-limit orders in MultiCharts 6.


Excellent! I wouldn't be too concerned if you can't get it to work in back testing mode, at least for now. If it is only made available in real-time mode it will be fine. There are other order types that would also be very useful in real-time only mode. Just because it's too complex or not applicable to implement a specific order type in back testing mode doesn't automatically mean it shouldn't ever be implemented in real-time mode. On the contrary. I feel all order types that are available by the broker's API should be implemented in real-time mode regardless. After all, why would the broker offer them via their API's for developers in the first place?

janus
Posts: 747
Joined: 25 May 2009
Has thanked: 41 times
Been thanked: 83 times

Postby janus » 19 Jan 2010

3. I believe you should have possibility to backtest your stop limit amounts first before you decide what will be your limit value. Otherwise you will guess.


I disagree. I for example do not use MC's back testing at all. I use MC simply to automate my rules for disciplined trading. I continually fine tune them over time by performing my own back testing using my own programs that I've developed in FreeBasic. Also, some order types do not need to be back tested. One may decide to use say a stop limit order to reduce risk of an entry after a simpler order type has been back tested. The results may be somewhat different but that's really of little consequence in the overall scheme of things. In other words, perfection is not a high priority for developing trading rules that provide consistent profits overall. Slippages also will cause difference between back testing and real-time results but that doesn't prevent us from using back testing even within MC.

Having said all that, if you can make any order type work in back testing mode as well as real-time mode then all the better.

ppan
Posts: 106
Joined: 31 Jan 2007
Has thanked: 2 times

Postby ppan » 19 Jan 2010

I agree with Janus. There is no need to put the stop limit order in back testing. The stop limit order is used for real time trading. MC should have this feature as fast as possible because it is very useful in real time trading.

SUPER
Posts: 622
Joined: 03 Mar 2007
Has thanked: 99 times
Been thanked: 80 times

Postby SUPER » 20 Jan 2010

I agree with janus's suggestion to implement all types orders for "Live" trading as soon as possible and when time & resources permit develop the back testing capabilities.

Kingjelly
Posts: 25
Joined: 23 Jan 2008

Postby Kingjelly » 03 Feb 2010

Agree with SUPER, we really need this functionality.

janus
Posts: 747
Joined: 25 May 2009
Has thanked: 41 times
Been thanked: 83 times

Postby janus » 03 Feb 2010

The whole process can be simplified. All we need is a simple buy and sell order type. I like to write my studies the same way I would trade manually. For example, I sell 10 contracts then buy 5 later to take profits and be net short 5. So, rather than saying sellshort 10 (assuming I was flat) then buytocover 5, it should be just sell 10 then buy 5. At another day I might sell 10 contracts then buy 20 to be net long 10. Currently I would have to say sellshort 10 then buy 10. So one has to determine which order type to use on entry and exit depending on the existing position and target net postion. It's unecessarily complex. When I use other trading tools like IGMarkets and CMC to trade CFDs, all they provide is a buy and sell order ticket. They know that if you go short say 5 contracts and then send an order to buy 5 contracts that the system automatically recognises it's to close out the previous 5 shorts. There's no need to work out whether the order should be an open or a close type order. It's the way I've traded for over 25 years with other tools. Back in the early days of phoning a broker I just say buy or sell - no needs to tell them it's an open or close order. In the end their systems tally things up and use the first in, first out logic to come up with a net position. I'm now considering writing my own functions to simulate simple buy and sell orders to keep the various entry/exit methods transparent and focus on the business of trading. I shouldn't have to do this.

Then there is the added complication of trying to cover existing contracts over several periods. For example, I go short 10 then decide to cover 2 contracts, 5 times to end up flat. I can't re-use the same statement to cover partial contracts. I have to use code like the following to get cover most cases. It's ridiculous to think one has to resort to such convoluted code to perform simple tasks.

// buy qty contracts
if marketposition >= 0 then begin // currently flat or long
buy ("M:Buy") qty contracts next bar at market;
end else begin // currently short
num = currentcontracts; // current # open shorts
if qty < num then begin // cover some current shorts
if currentcontracts <= 20 then toggle.b1[currentcontracts] = 1 - toggle.b1[currentcontracts];
if currentcontracts = 0 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 0 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 1 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 1 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 2 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 2 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 3 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 3 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 4 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 4 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 5 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 5 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 6 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 6 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 7 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 7 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 8 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 8 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 9 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 9 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 10 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 10 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 11 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 11 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 12 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 12 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 13 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 13 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 14 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 14 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 15 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 15 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 16 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 16 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 17 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 17 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 18 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 18 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 19 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 19 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts = 20 and toggle.b1[currentcontracts] = 0 then buytocover qty contracts total next bar at market;
if currentcontracts = 20 and toggle.b1[currentcontracts] = 1 then buytocover qty contracts total next bar at market;
if currentcontracts > 20 then spawn_message("Too many open short positions to cover manually","System1 Signal Error",
"ERROR"); // pop-up windows message
end else if qty = num then begin // cover all current shorts
buytocover ("M:BuyAll ") all contracts next bar at market;
end else begin // buying all current shorts plus more
num = qty - num;
buy ("M:Long") num contracts next bar at market;
end;
end;

Kingjelly
Posts: 25
Joined: 23 Jan 2008

Postby Kingjelly » 18 Feb 2010

Andrew,

Is this functionality still going to be in the final version of 6?

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

Postby Bruce DeVault » 19 Feb 2010

...When I use other trading tools like IGMarkets and CMC to trade CFDs, all they provide is a buy and sell order ticket. They know that if you go short say 5 contracts and then send an order to buy 5 contracts that the system automatically recognises it's to close out the previous 5 shorts. There's no need to work out whether the order should be an open or a close type order. It's the way I've traded for over 25 years with other tools. Back in the early days of phoning a broker I just say buy or sell - no needs to tell them it's an open or close order. In the end their systems tally things up and use the first in, first out logic to come up with a net position. I'm now considering writing my own functions to simulate simple buy and sell orders to keep the various entry/exit methods transparent and focus on the business of trading. I shouldn't have to do this....


Interestingly enough, this is the opposite of the reason EasyLanguage was made this way in the first place. Most people in fact have the opposite problem, in that they want to do things like put on a long position and have various exit orders out there e.g. a stop AND a target AND a trailing stop AND a technical exit (some of which they may intend to reside at the broker and not on their PC), and they don't want to worry about the possibility that if more than one of them happens to be filled it may cause an opposite direction entry because they do not intend to reverse, only to specify more than one possible way to get out - it's for this reason that explicitly entry or exit orders were introduced.

In the best of all worlds, there would be both - explicit buy and sell commands, plus explicit entry (long/short) and exit (long/short) commands. But, programming with the former set of tools is giving you lower-level access than with the latter, and requires a different mind set than you normally would with EasyLanguage.

One reason more platforms don't support stop limit orders than already do is that not every broker implements them, so they often end up having to be emulated in the platform software in order to preserve maximum broker independence (and that's probably what would have to be done here in at least some cases.)

I'm definitely supportive of having both sets of methods available, and also of allowing stop limit orders to be explicitly specified. I just wanted to try to provide that bit of perspective, that it's the way it is for a reason which is that it saves a great number of people time and makes it possible for them to focus on bigger picture tasks without worrying about possible unintended reversals.

janus
Posts: 747
Joined: 25 May 2009
Has thanked: 41 times
Been thanked: 83 times

Postby janus » 22 Feb 2010

Interestingly enough, this is the opposite of the reason EasyLanguage was made this way in the first place. Most people in fact have the opposite problem, in that they want to do things like put on a long position and have various exit orders out there e.g. a stop AND a target AND a trailing stop AND a technical exit (some of which they may intend to reside at the broker and not on their PC), and they don't want to worry about the possibility that if more than one of them happens to be filled it may cause an opposite direction entry because they do not intend to reverse, only to specify more than one possible way to get out - it's for this reason that explicitly entry or exit orders were introduced.


Yes, I understand all that but you miss the point many users prefer the simpler approach. Besides, one can't use the current methods in MC to trade shares in certain ways that are very common in practice. For example, I buy 100,000 shares in a company then buy another 50,000 later. Then I want to sell several smaller parcels later on. I can't do this generically without writing code like I posted earlier. Even then it's impossible to take care of all possible parcel sizes on exit as I would have to write 100's of 1000's of lines in the study - and that will probably slow it down considerably, if not crash MC. In my mind there is no question about it. We need a simple buy and sell order type with no restrictions. The dangers you illustrated in doing this are easy and simple to control (ie, exit quantities exceeding the original quantity opened). All one has to do is have code in the study to verify unwanted transactions don't happen. I would recommend doing it anyway even with the current system to be ultra safe. The code is very simple to implement - probably one of the simplest things to do in any study.

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

Postby Bruce DeVault » 22 Feb 2010

Let's say MC uses buy/sell type statements rather than entry/exit specific statements. I want to have a stop and a target in place for the following 60 minute bar, without using IOG. They're spaced closely enough together that one or both of them could be hit in the next 60 minutes, but they're far enough apart that they won't be hit on the same second. How can I do that using only buy/sell statements unless they're exit-specific, without a possibility of an unintended reversal? I can't - no combination of EL lines or 1000s of lines can do it, because I can't know which will be hit first and thus I must keep them both in place for the next bar. It's for this reason that the platform has features that allow orders to be specifically exit orders, so that it can manage this aspect of the position even before my strategy is next calculated in 60 minutes.

I'm not opposed to there being additional keywords that allow bypassing these protections - I'm simply explaining why it's the more common need to have it be the way it is.

janus
Posts: 747
Joined: 25 May 2009
Has thanked: 41 times
Been thanked: 83 times

Postby janus » 22 Feb 2010

Let's say MC uses buy/sell type statements rather than entry/exit specific statements. I want to have a stop and a target in place for the following 60 minute bar, without using IOG. They're spaced closely enough together that one or both of them could be hit in the next 60 minutes, but they're far enough apart that they won't be hit on the same second. How can I do that using only buy/sell statements unless they're exit-specific, without a possibility of an unintended reversal?


Very simple. I do it now and have my own dll functions to simulate simple buy and sell order types. Conflicts are impossible as the dll uses a combination of multi-threading, critical sections and position checking. I ran some tests whereby I bombarded the dll with orders from multiple studies. This is for the more complex studies. For the simple ones where I will only ever have one study for a particular symbol, I use only EL code and check the current position to make sure I submit the correct order type and quantity.

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

Postby Bruce DeVault » 22 Feb 2010

You didn't answer the question. Using only EasyLanguage buy and sell statements that aren't exit specific, how can I have a "sell next bar at x stop" and a "sell next bar at x limit" in place for the following 60 second bar, yet not use IOG, and be assured there will be no unintended reversal? You can't. That's why there are exit order types like "sell" and "buytocover" - so that you can specify several exits without a reversal, and so that you can't be assured you won't close out more than you opened.

janus
Posts: 747
Joined: 25 May 2009
Has thanked: 41 times
Been thanked: 83 times

Postby janus » 22 Feb 2010

You didn't answer the question. Using only EasyLanguage buy and sell statements that aren't exit specific, how can I have a "sell next bar at x stop" and a "sell next bar at x limit" in place for the following 60 second bar, yet not use IOG, and be assured there will be no unintended reversal? You can't. That's why there are exit order types like "sell" and "buytocover" - so that you can specify several exits without a reversal, and so that you can't be assured you won't close out more than you opened.


I would never have an order to sell at stop and limit the way you described. I would do it all in EL code to decide in real-time what to do by checking the last trade. It avoids such complications that you describe. For example, if the price action passes my pre-determined stop on long positions I "sell".

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

Postby Bruce DeVault » 22 Feb 2010

That's fine - I understand you are saying you may not do this. But many people trade daily bars or other long time frames like 60 minute bars etc., and they have absolutely no desire to use IOG or to manage the orders at the low level you are talking about - it doesn't always make sense to do what you're describing and wait until the next calc to put one order or the other in the market, and certainly not from an "ease-of-use" standpoint or from the standpoint of what makes the shortest, easiest to understand code. That's one of the things that makes EasyLanguage "easy" is that it takes care of these details for you.

EasyLanguage isn't all things to all people - but it's designed to make a particular class of commonly needed things easy, and it does that very well.

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

Postby Bruce DeVault » 22 Feb 2010

Essentially, what you are saying is, you don't want it to be like EasyLanguage anymore - you want it to be like a more basic platform where there's no position management and everyone is on their own to manage orders. I'm not opposed to adding that as an option, but to suggest that the way it is is somehow inferior is I think missing the big picture, which is that for most people, the current design works very well indeed.

janus
Posts: 747
Joined: 25 May 2009
Has thanked: 41 times
Been thanked: 83 times

Postby janus » 22 Feb 2010

That's why there are exit order types like "sell" and "buytocover" - so that you can specify several exits without a reversal, and so that you can't be assured you won't close out more than you opened.


That's the other point. I can't re-use the same sell or buytocover command on multiple exits after doing a single entry. I have to resort to code I posted before to do this. Is there another way? For example, if I buy 100,000 shares and then want to sell 10,000 to 20,000 shares at a time, is there a way I can do this without using different sell commands?

janus
Posts: 747
Joined: 25 May 2009
Has thanked: 41 times
Been thanked: 83 times

Postby janus » 22 Feb 2010

Essentially, what you are saying is, you don't want it to be like EasyLanguage anymore - you want it to be like a more basic platform where there's no position management and everyone is on their own to manage orders. I'm not opposed to adding that as an option, but to suggest that the way it is is somehow inferior is I think missing the big picture, which is that for most people, the current design works very well indeed.


Yes. There are different types of traders out there. I've been a trader for over 25 years and I've met most of the different trader types. So to have a platform tied to just one type is limiting the market exposure of the product.

janus
Posts: 747
Joined: 25 May 2009
Has thanked: 41 times
Been thanked: 83 times

Postby janus » 22 Feb 2010

t doesn't always make sense to do what you're describing and wait until the next calc to put one order or the other in the market


You imply that MC has a real 'at market" order type for all kinds of entries and exits. It doesn't. That's something else I like to see put in. If my study decides to enter a long position at any given bar or tick, it should be able to place the order "at market" immediately.

miltonc4
Posts: 150
Joined: 14 Apr 2006
Has thanked: 1 time
Been thanked: 3 times

Postby miltonc4 » 22 Feb 2010

Hi Support
I am with Janus on this,meaning why not allow this flexibility for those that wish to use it as Janus explained,For those like Bruce is suggesting can still do as done now,but at least allow MC with some other options.
This applies to many features in MC,excellent,but sometimes lacks flexibility,which over time I am sure will be added.
Thanks
Milton

janus
Posts: 747
Joined: 25 May 2009
Has thanked: 41 times
Been thanked: 83 times

Postby janus » 22 Feb 2010

I am with Janus on this,meaning why not allow this flexibility for those that wish to use it as Janus explained,For those like Bruce is suggesting can still do as done now,but at least allow MC with some other options.
This applies to many features in MC,excellent,but sometimes lacks flexibility,which over time I am sure will be added.
Milton


I'm a great believer in giving as much flexibility as possible, especially for advanced programmers like myself. I understand how less flexibility makes it easier to foolproof a development environment, but places too many restrictions to advanced users. That's why I actually prefer trading tools like NT and AB because they use advanced languages natively, but I've stayed with MC because of it's advanced charting features and easier to use language supplemented by my dll's for more advanced work ending up with the best of all worlds.

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

Postby Bruce DeVault » 23 Feb 2010

As I've said several times above, I support adding new optional features to place orders that are unmanaged. That's how I handle orders on any number of other platforms where I've been building autotrading systems for years. I was simply explaining why it isn't the case that the way things are in EasyLanguage is bad - it's what most people find the most helpful. What I reject is the notion that the current design is somehow defective - it's actually quite good at doing what it does - it simply wasn't designed to solve every possible problem and there are some things it doesn't cleanly express - it isn't and can't be all things to all people.

Right now, EasyLanguage doesn't have a clean solution for scaling both in/out in arbitrary pieces (no looping orders), and the code to do this tends to be awkward (e.g. a large number of different lines of code to allow placing 100 orders, etc.), for the simple reason that this isn't the problem EasyLanguage was designed to solve. On the other hand, for system trading ideas that are of the right sort e.g. a few setup conditions, then entry, a stop, a target, a trailing stop... EasyLanguage tends to have a solution that's about 5-10 lines long instead of hundreds of lines long, because it's extremely expressive and powerful for these types of ideas, and provides a way to handle many common needs with practically no code and in an English-like language, which is quite a time saver and very helpful.

The solution clearly is to leave in place everything that's here, and simply add separate, unmanaged order entry capabilities for those who want to be "on their own" in managing their own orders, so that for instance orders can be used in loops and are handled more like a "print" statement is, rather than being matched by comment, price and size, etc. and I agree that this suggestion can be helpful for those specific situations such as arbitrary scaling in/out where the current architecture doesn't really take the necessary things into account in its desire to make position management "easy" for most people testing and building out system trading ideas.

This new unmanaged capability will have to operate in a radically different way (more like unmanaged platforms do), returning unique order identifiers when an order is placed, and allowing order status, fill size/price, etc. to be checked by identifier, and orders to be canceled by identifier - it won't be able to match on price/size/comment like EasyLanguage does now and thus you would need to explicitly cancel orders rather than simply not restating them, but will allow programmers who want to take low-level control to do so.

I don't begrudge the addition of these kinds of capabilities and think they should be added to round out the capabilities - I simply reject that the current solution is somehow a bad one because it doesn't let you to loop and place orders etc. - that's a compromise that was thought out and clearly understood by the designers, and was considered to be the best compromise in terms of helping the most people the most. It's actually quite a good design considering, and that's why only a few users out of a great many find they need low level order control despite following many different kinds of approaches.

ppan
Posts: 106
Joined: 31 Jan 2007
Has thanked: 2 times

Postby ppan » 15 Jun 2010

Will the Stop Limit order be added in the MC 6 release?

janus
Posts: 747
Joined: 25 May 2009
Has thanked: 41 times
Been thanked: 83 times

Postby janus » 17 Jun 2010

The solution clearly is to leave in place everything that's here, and simply add separate, unmanaged order entry capabilities for those who want to be "on their own" in managing their own orders, so that for instance orders can be used in loops and are handled more like a "print" statement is, rather than being matched by comment, price and size, etc. and I agree that this suggestion can be helpful for those specific situations such as arbitrary scaling in/out where the current architecture doesn't really take the necessary things into account in its desire to make position management "easy" for most people testing and building out system trading ideas.


100% agree. However, i won't hold my breath seeing it implemented. Pity really as it would attract many more subscribers if this was done. :(

User avatar
Dave Masalov
Posts: 1712
Joined: 16 Apr 2010
Has thanked: 51 times
Been thanked: 485 times

Postby Dave Masalov » 30 Jun 2010

Dear Sirs,

The Stop Limit orders will be implemented in the version 7.

We are currently working on MultiCharts 7.0. Actually this feature has been developped already in the separate brunch of version 7.0.

MultiCharts 7.0 should be released in the end of summer. So it will not take too long to have Stop Limit orders implemented.

We will not delay the release of 7.0 as we did with version 6. We had special reasons for that which cannot be publicized.

ppan
Posts: 106
Joined: 31 Jan 2007
Has thanked: 2 times

Re: Stop Limit orders

Postby ppan » 01 Dec 2010

Will the Stop Limit orders be implemented in the Multicharts 7.0?

User avatar
Dave Masalov
Posts: 1712
Joined: 16 Apr 2010
Has thanked: 51 times
Been thanked: 485 times

Re: Stop Limit orders

Postby Dave Masalov » 01 Dec 2010

Dear ppan,

Yes, Stop Limit orders will be implemented in MC 7.0


Return to “MultiCharts”