Please change...
to
There's no need to make this a breaking change for my optimizer. Make it an optional parameter. I don't plan to ever implement "Resume Previous."
CODE:
public abstract void Optimize(ParameterList pl, bool resumePrevious)
to
CODE:
public abstract void Optimize(ParameterList pl, bool resumePrevious = false)
There's no need to make this a breaking change for my optimizer. Make it an optional parameter. I don't plan to ever implement "Resume Previous."
Rename
Very sorry about interrupting your workflow, but in this case it would not make a difference.
Even if we made the parameter optional, since you're overriding the method, the compiled optimizer would still fail to load, because the method signature is different.
In fact, this is the very reason for the original forum topic issue you responded to. We added an OPTIONAL parameter to UserStrategyBase.WriteToDebugLog and compiled strategies need to be rebuilt because of it.
We'll try and keep breaking changes to an absolute minimum but they will be required from time to time so we can implement the various feature requests.
Even if we made the parameter optional, since you're overriding the method, the compiled optimizer would still fail to load, because the method signature is different.
In fact, this is the very reason for the original forum topic issue you responded to. We added an OPTIONAL parameter to UserStrategyBase.WriteToDebugLog and compiled strategies need to be rebuilt because of it.
We'll try and keep breaking changes to an absolute minimum but they will be required from time to time so we can implement the various feature requests.
I have to ask myself... How many people are going to restart an optimization? What would be the reason? What if there's an intervening optimization? Can I restart a second-to-last optimization? The next request will undoubtedly be to present a choice of available optimizations so the user can choose. Any change to the strategy (or the timeframe, or the portfolio) makes all prior optimization work invalid. What happens when the user saves interim optimization data, switches strategies, then restarts the optimization?
Here's the overarching problem. You have decided to crowd-source the design of Wealth-Lab. You're implementing every request, pretty much regardless of its value and even if only a small number of users benefit. Remember that every new function point you implement has downsides. 1. It's a function point to maintain. 2. It may have side effects on other functionality. 3. It's a function point to test with each subsequent release. 4. Every use case becomes a constraint on future development. 5. Breaking changes force users to adopt the latest release, at some risk, even when they won't benefit from it. So... Slow down. Reject requests where cost outweighs benefit.
Here's the overarching problem. You have decided to crowd-source the design of Wealth-Lab. You're implementing every request, pretty much regardless of its value and even if only a small number of users benefit. Remember that every new function point you implement has downsides. 1. It's a function point to maintain. 2. It may have side effects on other functionality. 3. It's a function point to test with each subsequent release. 4. Every use case becomes a constraint on future development. 5. Breaking changes force users to adopt the latest release, at some risk, even when they won't benefit from it. So... Slow down. Reject requests where cost outweighs benefit.
Thanks Len, we do decline requests believe it or not, check the bottom of the Wish List for declined requests. Every request we implement we believe has a benefit that outweighs the cost.
Your Response
Post
Edit Post
Login is required