In WL4, the math Round argument used banker's rounding and was easy to code, like thus:

CODE:
Please log in to see this code.

It seems to be much more complicated in WL5:

CODE:
Please log in to see this code.

Is there a simpler, shorter way?
====================================

Secondly, I am having a hard time finding the various string conventions used in WL5 in any of the help guides. Is there a list of the common formats as a trader would use? [The info on the web is scattered and most is not applicable to trading.]

A simpler, shorter way:

CODE:
Please log in to see this code.

Or create a function 'Round'.

QUOTE:
the various string conventions

What's that - which formats? what for?

String formats would be for information a trader may need, such as:
- date (in long or short format)
- values (of a price or indicator, up to s specified decimal place; if you use ToString argument then the entire double value gets printed)
- format as %
- formatting codes (e.g. #9 or #9#9 used in WL4)
- etc.

That's what you should be looking for in your C# book or in MSDN. I'll only give a few pointers -

String Formatting in C#
String Format for DateTime

Thanks, Eugene, thats along the lines of what I was looking for. I had checked the formats on msdn and found them to be fairly dense.

One more question (and this is about equities slippage, not about ticks for futures): In WL4 one could put this in a script

CODE:
Please log in to see this code.

if one wanted to overrule the default settings; is there an equivalent function in WL5?

For equities, I guess, overriding the default slippage percentage should be performed in a Commission library in V5 (i.e. not an easy way).

.. that wouldn't work for Limit Order slippage, but it's a good thought for Stop and Market orders - you can penalize yourself as much as you want through commissions. But you gotta keep in mind that slippage in real trading works both ways - positive and negative - but simulated slippage is negative only, on every trade.

Anyway, no equivalent exists. Some functions were deprecated for the purpose of simplification of the code base.

Please see what you can do. When it comes to slippage, one size clearly does not fit all. Slippage can vary among various global markets, and even within segments of any given market e.g. slippage is different when trading large caps vs small caps even in the US market which many folks consider 'efficient'.
The best thing would be have it like it was in WL4, giving the user full control.


BTW, the argument

CODE:
Please log in to see this code.

causes WL5 to give an error - something like: the call is ambiguous between double and decimal, same as you get as if you hadn't put in the MidPointRounding.ToEven in the first place.

QUOTE:
Slippage can vary among various global markets

Although that's true, such detalization won't mean too much (Robert has a good argument on positive/negative slippage). So if I was asked to see what could I do, I'd do nothing for the simplification's sake.

QUOTE:
causes WL5 to give an error - something like: the call is ambiguous between double and decimal, same as you get as if you hadn't put in the MidPointRounding.ToEven in the first place.

That happens if the result of a division is an integer, which can be converted to both double and decimal. In this case, create a "Round" function and pack it in a compiled library or (more simple) to the default strategy template.

I am all for simplification myself but not when it leads to loss of functionality.

I will point out that under Preferences you can choose to set/hide pane lines, and you can also do that inside a script by using HidePaneLines to override the default settings. Now that's just a cosmetic function, and it has been retained on migration from WL4 to WL5. I find the SetSlippage function to be far more useful to my style of trading.

I am not being argumentative, just putting forth a different point of view.

Slippage deals with how trades are executed, HidePanes does not. Something it took me a little while to understand was that "simplification" has two targets. One is the user, but the other is the code base for a more stable product. They're not necessarily compatible on the surface, but if it results in fewer bugs, then in the long run it's simpler on you too. Anyway, as time goes on, if many users request the same thing, those features have a way of finding their way back in.

>>Slippage deals with how trades are executed, HidePanes does not.<<
The point I was trying to make is that a trading-related function was discarded in favor of a cosmetic one.
*/

I am trying my best to migrate from WL4 to WL5 but keep hitting roadblocks due to lack of equivalent functionality in the latter.

Here's the thing. Say I have multiple scripts, some of which use SetSlippage to override the 'generic' setting in Prefs. Backtesting is not an issue as I can adjust the setting before the test. The issue is executing all the scripts together in Strategy Monitor as that will apply the 'generic' slippage settings to all scripts. For Limit orders, this may result in either missed trades or trades taken inadvertently because of the miscalculated price excursion beyond the limit price as a result of the (wrong) slippage. This, in turn, would result in wrong alerts e.g. the script may generate exit (instead of entry) alerts when in reality a trade would not have materialized; conversely, it would generate new entry alerts for mistakenly omitted trades that would ordinarily have generated exit signals.

The only workaround that I can think of is to run those scripts that use the generic slippage setting, change the setting under Prefs, and then run the ones that use a different setting. Manually, of course. Very inconvenient.
*/

The Strategy Monitor has a Change Settings item, which primarily is for Data Range, Pos size & Scale. I wonder if there is a way to work slippage settings into this module that would override the default settings? [Of course, having SetSlippage restored would be the best option of all.]

In other words, your argument is that you need SetSlippage -- purely a backtesting function that simulates less-than-perfect fills -- to make your real trade fills worse by running it in a strategy destined for Strategy Monitor? :P

The argument of using limit order slippage to ensure that your script remains in synch for live fills doesn't work. For the same reason a script would get out of synch when not using slippage also applies to using slippage as well... slippage doesn't fill your order, but you actually do get hit on the bid or offer...

There's no magic bullet and the only solution is to closely monitor limit order trading and take action when and if necessary.

Maybe I didn't explain it properly. Let me try again.

Say at the end of the day I am running my scripts whose Limit orders are all going to be influenced by the Slippage setting under Prefs; lets say that setting is 0.2%. By way of illustration, say one of these scripts is a dip buyer in which I use a custom SetSlippage setting of 0.5%; it triggers an alert to Buy 100 shares symbol 'ABC' at a limit price of 100 the next day. The next day, the stocks trades down to 99.7. When I run this script at the end of the day along with other scripts, under the influence of the slippage setting under Prefs (0.2%), the script assumes a trade was taken (price excursion was beyond 100 - 0.2% = 99.8) and generate exit alerts for next bar. However, had the custom slippage setting (0.5%) been in effect, the trade would *not* have been taken as the price didn't reach low enough (100 - 0.5% = 99.5). Obviously, the reverse is also true i.e. when the custom setting is lower than one under Prefs.

So its a case of wrong alerts in WL5 Strategy Monitor. However, the alerts are all correct in WL4 b/c the SetSlippage function overrides the value under Prefs.

[Note: Any use of symbols or percentages used above is strictly for illustration and is not a recommendation to buy or sell a security or use those settings.]

I understand, but it seems like you're trying to predict how much slippage actually occurs, but you cannot. The point is that slippage is for backtesting to generally give you a pessimistic result (even though slippage actually works both ways). In real trading with limit orders, it's guessing game of 1 tick if you get filled or not. Unless you're trading the pink sheets or something truly illiquid, if price crosses your limit price even by 1 tick, you can pretty much be assured of a fully-filled order.

Another factor is order entry delay in which the data say that price crossed, but your order wasn't marketable at the time. But using slippage would only serve to exacerbate that problem.

My advice: Don't use slippage for live trading. The chance of live Positions to be out-of-synch with a script is greater with slippage enabled, no matter what percent you use.

I agree with most of your points above. But I do believe that there isn't, and shouldn't be, a big divide between backtesting and live trading as long as your scripts are soundly constructed. I believe my slippage settings are sound and have served me well using WL4 over the years. I just want to get the 'correct' alerts each day, much like I get in WL4's Watchlist scans using slippage.

It will be nice have the SetSlippage function restored down the road. Alternately, perhaps it may be implemented through the Strategy Monitor's Change Settings.

Along with the simplification, there's another buzzword: Wealth-Lab's trademark extensibility. My advice for you would be to get a copy of Visual Studio Express or SharpDevelop, and implement a SetSlippage through a custom commission library. Given that Community.Commissions project code is disclosed, it shouldn't be too hard and the product will not suffer from overloading with rarely requested functions and options.

Attacking it from the Commissions angle won't help simulate limit order slippage.

However, you could program limit order slippage by peeking. Here's the solution in a script, though it does not include logic for the gap "exception" described in the User Guide, but you get the idea.

CODE:
Please log in to see this code.

Thank you for the code, Cone, and to both of you for the interaction.

I don't believe my query was wrong, it was just slightly ahead of its time. With cross-border trading increasingly common, it will eventually dawn on traders they need to have different slippage settings, and the best way to accomplish that is SetSlippage.

Another thought before you get too far with the code above... if used for Pairs or similar, you'll need to either pass the Bars object for the symbol being traded or make sure to SetContext prior to both entries and exits so that the check for the High/Low[tradeBar] occurs for the intended symbol.

I always try to keep things in context (pun intended). But thanks for the tip.
*/

An idea occurred to me: Instead of waiting for users to request features, can't you periodically put up features for users to vote on? That way features get in quicker, WLab gets better, and trounces its competition.

Highlighting Wealth-Lab's trademark extensibility again, an idea also occurred to me: as there's a dozen of APIs (for strategies, commissions, visualizers, providers, methods, chart drawing objects and chartstyles, PosSizers, optimizers, scorecards), users can extend Wealth-Lab on their own w/o even having to put up a vote.

If you're talking more about the core features of the application, then unfortunately, software development process in a corporation can't really be driven by web wishlists. Core features only can get as quick as the Fidelity development team implements them according to their release schedule.