Disable Automatic Run After Change of Position Size, DataSet
Author: gbullr
Creation Date: 10/30/2015 3:47 PM
profile picture

gbullr

#1
Whenever one changes position size or leverage or period or dataset the program runs automatically. Is it posible to dissable this feature. If not could you make it so. I find myself hitting cancel all the time.

Thanks for your consideration.
profile picture

Eugene

#2
This proposition arises from time to time and presents a suboptimal idea to say the least. There are several contra:

1. If you change position size, you do expect immediate reaction from the program - otherwise you would not be doing it.
2. Not honoring the event would also make the program cheat on you as the changed state of the dropdown boxes would no longer represent the backtest results.
3. Different behavior when executing in single symbol (immediate execution) vs multi-symbol mode (delayed execution) would be confusing.
4. Unnecessary option = unnecessary support. You don't know how many support calls a seemingly innocuous option (like "Show status bars...") generate.
5. Hypothetical addons relying on the state of these dropdown boxes.
6. Now think of this from a different perspective. If the option is disabled by default, there will come those who got used to it and who find the feature very convenient and can't imagine living without it, asking to bring it back.
7. There exist workarounds if you don't like it. For existing discussions and workarounds please see below:

How to avoid Strategy execution every time I change settings like timeframe, data range, position size?
What are the ways I can limit a script from automatically starting after changing a setting?

If your script's execution is slow, for example, it's not necessarily the program's fault and the feature is 'bad'. Disable on demand data update, optimize your code, load adequate amount of data etc. - and you'll find that auto-execution is a blessing.
profile picture

LenMoz

#3
Auto-execution is not a blessing unless doing very basic testing. It's much more of a curse. The fact that threads keep recurring about changing this behavior makes my point. Users don't like it.
profile picture

Eugene

#4
As most testing is basic and even Rule-based, the "1%-ers" with sky-high I.Q. scripts executing slowly are the minority. If they don't like it, there are instant workarounds.

Although they not necessarily are, users may be wrong for reasons outlined in my previous reply (last paragraph). So "Users don't like" here is a rare case of deceptive argument. Sorry but different flavors of "I'm not ready yet" still do not sound like a good argument to me. If that hurts, as the proverbial doctor said, don't touch it.
profile picture

gbullr

#5
Thanks.

Just think that it is better to not run auto. Just an opinion. Thanks again.

Best.
profile picture

Carova

#6
I can't believe after all of this time it hasn't been included in Preferences. It would be so simple.

Vince
profile picture

Eugene

#7
Vince,
It's not simple. Nothing can happen if there's no sound business case.

Gaston,
"Just an opinion", not backed by any argument, is not sufficient. I can think of 7 counter-arguments right off the bat.

It looks like you guys are not following my post #2 which is worth to read to get my point.
profile picture

LenMoz

#8
I had already examined your post #2 and pretty much don't agree with your arguments...
QUOTE:
1. If you change position size, you do expect immediate reaction from the program - otherwise you would not be doing it.

Most often not true. I may intend to change multiple aspects, date range and PosSizer attributes, for instance. This is why autorun does not occur if I change a parameter or point to a different portfolio. There is no way for the program to know when everything is set and I am ready to run the backtest.
QUOTE:
2. Not honoring the event would also make the program cheat on you as the changed state of the dropdown boxes would no longer represent the backtest results.
This occurs now when I change a parameter or point to a new Dataset. It is not "cheating" and not an issue.
QUOTE:
3. Different behavior when executing in single symbol (immediate execution) vs multi-symbol mode (delayed execution) would be confusing.

This is already true when clicking on symbols vs. clicking on a Dataset. Wealthlab behavior is somewhat arbitrary and in this case doesn't meet my and some others needs.
QUOTE:
4. Unnecessary option = unnecessary support. You don't know how many support calls a seemingly innocuous option (like "Show status bars...") generate.
It's a worthwhile option that can save me and other users time, adding value to WealthLab.
QUOTE:
5. Hypothetical addons relying on the state of these dropdown boxes.
If the strategy isn't running, neither should the addons be running. I don't think we're asking to change anything about the state of the dropdown boxes. The request is for the event handler(s) to check a user preference before launching.
QUOTE:
6. Now think of this from a different perspective. If the option is disabled by default, there will come those who got used to it and who find the feature very convenient and can't imagine living without it, asking to bring it back.
Make it a user preference checkbox. Couldn't be simpler. Both sets of users are accommodated.
QUOTE:
7. There exist workarounds if you don't like it. For existing discussions and workarounds please see below:
The workarounds are big inconvenience to frequent users. I know. I've been living with these "workarounds" for years.

QUOTE:
If your script's execution is slow, for example, it's not necessarily the program's fault and the feature is 'bad'. Disable on demand data update, optimize your code, load adequate amount of data etc. - and you'll find that auto-execution is a blessing.
Agreed that my slow execution is not the program's fault, but neither is it from on demand data or the code. It is most often because I am running a ten year backtest against 200 or more symbols. The goal is to create a robust strategy that has not merely memorized a small amount of data due to short duration or few symbols. Many of my strategies have an adaptive component and learn as the backtest proceeds. A short backtest precludes time to learn. Bottom line. For me a long-running backtest is an unavoidable fact, so I don't want to launch a backtest unnecessarily.

For some reason, Eugene, you have decided to dig your heels in on this repeated request, and it is you who are not listening. Finally, I remind you of the description of the "WealthLab Pro/Developer" category... "Let us know what you want to make this your ultimate trading system development tool!"
profile picture

Eugene

#9
If you don't like autorun and would like to change multiple aspects all at once, just strike Escape key to effectively stop it. That's all it takes.

It's a more rare, even hypothetic or perfectionist case rather than the real use case of changing just one parameter at a time and analyzing the impact, step by step. It should not dominate over the default behavior, good or bad, but now traditional after 8 years of existence. Immediate execution is what most users expect because their scripts run within seconds.

You may call this a tradeoff but when software can not please everyone, we've got workarounds. And yes, I'm not afraid to appear reluctant to proposing to make it even an option. The more options there are, and this one would look truly confusing to the average trader, the more error prone the resulting user experience becomes. For one happy tech-savvy user there will stand five who'd set it, forget it, and then call support because the program appears 'broken' to them. Just like that innocuous "Show status bar" option that "breaks Optimization".

With your experience, Len, I admit that you may have a reason to do what you're doing but it's not the case with the other users who very well may be overlooking the on-demand update enabled, or having less efficient code, or not caring about data loading depth, or even not having learnt the Escape key behavior.

If you don't like my line of thought, please feel free to call Fidelity and make the feature request.

profile picture

LenMoz

#10
What I hear you saying is that, at MS123 at least, WealthLab is not intended for the serious user and improvement requests from serious users may not be implemented because we are relatively few in number. I further hear that WealthLab's 8-year history has so set things in concrete that meaningful improvements are unlikely. (For those who may be curious, my experience with Wealth-Lab is two and a half years)

I will call Fidelity on Monday.
profile picture

Eugene

#11
My years have taught me to swallow the pill of many rejected improvements (I probably was a pest in my early years of WL) but I'd prefer to be heard differently. I'm open to improvements, whether they're coming from power users or rookies, yet am conservative enough to approach them carefully because we're dealing with the mature application and a user base of various experience.
profile picture

Eugene

#12
How about this?

1. Close your strategy window.
2. Configure the three dropdown boxes as you please.
3. Reopen the strategy. The new settings are picked up.

Provided that no options under the group Preferences > Advanced Options > "Save the following items..." are active, it should work out.
profile picture

LenMoz

#13
Thank you for trying, but I can't meet the last condition. I save 4 out of 5 of the "following items" because specific configurations of these options are needed for specific strategies.
profile picture

Eugene

#14
Same here: my strategies also require specific configurations. Having kept those boxes unchecked, my preference is to organize the strategies in saved Workspaces.
profile picture

gbullr

#15
Glad to have started WWIII.

It seems like the post has hit a nerve w/ "serious" users. Maybe that is a valid enough argument.


ESC
Update on demand
ETC is known by me .

My code writing skills still suck after a number of years. It is not codeacademy that is going to fix that.

Best.
profile picture

Eugene

#16
@gbullr
You might find the workaround in post #12 worth a try.
profile picture

Panache

#17
I, too, find the auto-run annoying. A related problem is that Wealth-Lab auto-runs the last compiled program, not what is currently in the Editor. I think that is a pretty clear violation of Eugene's Rule #1.

Here's how this situation arises for me. I find a bug in my code or something I want to change in my Strategy. I switch to the Editor and make the change. I then switch to a DataSet with fewer symbols (or just one) to test my code, and the Strategy auto-runs. I see the same thing I originally had. I then have to click Run the Strategy to see the effect of the changes I made in the Editor.

Here's an example:

CODE:
Please log in to see this code.


I guess I'm a 1%er, because I know this problem exists. However I doubt most Wealth-Lab users would expect to have to re-run their Strategy to see the results of their change.
profile picture

Eugene

#18
This "problem" is actually documented behavior. After making an intended change to the code you either click Compile (+Go) or "Run the Strategy". Until that these changes aren't considered committed yet and exist only in RAM buffer as temporary. Otherwise Wealth-Lab runs "last known" copy. On a related note, Strategy Monitor also works with its own compiled in-memory copy (which, however, completely ignores changes to the original Strategy until the SM is restarted).

Similar behavior is found in Visual Studio (for example, in the suggestion to run "last known good" code when debugging after a compilation error).
profile picture

Panache

#19
I was playing with this a bit this morning, and I take back my criticism. For most Strategies, auto-run lets you instantly see the effect of changing Strategy Parameters (and Position Sizes), which outweighs the problems it creates for me.

The reason for my initial bias is that I've had issues in the past where simply changing the Parameter Values didn't give the same results as when I hit Run the Strategy. I use signals for all of my Buys, so the problem isn't that Wealth-Lab is picking random trades. I can't reproduce the problem right now, but the next time I do some back testing, I'll try to remember to see when it is happening, isolate the issue and update this thread.